Jump to content

AlbertMinrich

Members
  • Gesamte Inhalte

    26
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

10 Neutral

Über AlbertMinrich

  • Rang
    Newbie
  1. Um die UAC wirklich komplett zu deaktivieren, mach ich immer folgendes: 1. Systemsteuerung > Benutzenkontensteuerung > Schieberegler ganz nach unten 2. gpedit.msc > Computer Konfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen Und hier alphabetisch sortieren und die obersten beiden Punkte: - "Benutzerkontensteuerung: Administratorbestätigungsmodus für das integrierte Administratorkonto" - "Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen" deaktivieren 3. Reboot Um zu prüfen, ob die UAC wirklich deaktiviert ist: Taste [Windows] + [R] > cmd "whoami /groups" Wenn hier in der letzten Zeile in der Spalte SID die SID mit 12288 endet, ist UAC deaktiviert. Endet sie mit einer vierstelligen Zahl, beginnend mit 8 (den Rest weiß ich jetzt Grad nicht), ist UAC aktiv. Gruß Martin
  2. Fragen zu NTFS-Berechtigungen (List-Gruppen)?

    Danke für die Antworten. Natürlich wollen wir von der IT-Abteilung es auch möglichst einfach halten. Aber die Anforderungen aus den Fachabteilungen sind damit nicht immer vereinbar. Und manchmal sticht Ober Unter. Danke und Gruß Martin
  3. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    Ja, DFS ist auch eine gute Idee. Danke für alle Infos/Kommentare/Anregungen Gruß Martin
  4. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    OK, danke für die Aufklärung. Vielleicht fällt ja noch jemanden was ein, der etwas mitteilungsfreudiger ist. ;)
  5. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    Ich glaub, wir meinen schon das gleiche. Die geerbten Berechtigungen kann man nur entfernen, wenn man die Vererbung deaktiviert. Ich denke, da sind wir uns einig. Beim Deaktivieren der Vererbung kann man die bisher geerbten Berechtigungen übernehmen. Die effektiven Berechtigungen auf den Ordner sind dann erstmal genauso, wie vor der Deaktivierung. Nur, dass sie nicht mehr geerbt, sondern explizit gesetzt sind. Falls du was anderes meinst, klär mich doch bitte auf.
  6. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    Um die vererbbaren Berechtigungen entfernen zu können, muss ich die Vererbung unterbrechen, das ist also das gleiche. Und wieso man das nicht soll, hab ich schon geschrieben: "Man ändert oben die Berechtigungen und geht davon aus, dass das für alles darunter durchvererbt wird. Das irgendwo unten in der Ordnerstruktur die Vererbung ausgeschaltet wurde, sieht man ja auf den ersten Blick nicht." Und man liest es immer wieder. Z.B. hier http://www.fileserver-tools.com/2012/08/windows-berechtigungen-optimal-setzen-2/ unter Punkt 6: " Die Vererbung zu unterbrechen ist ganz schlechter Stil, weswegen man das nur in ganz seltenen Ausnahmefällen machen sollte" Aber es gibt wohl auch andere Meinungen. Ich möchte hier gar keine Grundsatzdiskussion entfachen. Vielen Dank für alle Antworten Gruß Martin
  7. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    So haben wir es ja bisher gemacht. Aber, wie man immer wieder liest, soll man das ja nicht. Versteh ich ja auch. Man ändert oben die Berechtigungen und geht davon aus, dass das für alles darunter durchvererbt wird. Das irgendwo unten in der Ordnerstruktur die Vererbung ausgeschaltet wurde, sieht man ja auf den ersten Blick nicht. Außer man hat eine gute Doku oder entsprechende Tools. Ja, hab ich ja auch in meiner zweiten Antwort schon so geschrieben, dass das eine mögliche (und vielleicht auch die beste) Lösung ist. Zwei andere mögliche Lösungen hab ich auch schon geschrieben, - Vererbung deaktivieren - "meine" Pseudo-Ordner Lösung die aber nicht empfohlen bzw. nicht "schön" sind. Deshalb nochmal die Frage: Gibt´s eine schöne technische Lösung, bei der der Ordner bleiben kann, wo er ist? Gruß Martin
  8. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    Die Berechtigungen werden auf jeden Fall von der IT-Abteilung gepflegt. Wenn man das die User machen lässt, das gibt nur Chaos. Und ich geb dir ja recht, man sollte die Struktur von vornherein so aufbauen, dass danach keine Änderungen mehr notwendig sind. Bloss in der Praxis wird das nicht immer möglich sein. Auf mein Beispiel bezogen, könnte ich natürlich auch den Ordner ObersteLeitung eine Ebene nach oben holen, dann gäbe es \\Server01\Einkauf\Leitung und \\Server01\Einkauf\ObersteLeitung Ist vielleicht die beste Lösung, aber vielleicht hat ja trotzdem noch jemand eine "schöne" technische Lösung, bei der der Ordner dort bleiben kann, wo er ist. Es handelt sich übrigens nicht um eine Schulaufgabe, sondern um ein Problem aus der Praxis, vor dem wir immer wieder mal stehen. Bisher haben wir in diesen Fällen an dieser Stelle die Vererbung deaktiviert, aber das soll man ja nicht machen. Gruß Martin
  9. Fragen zu NTFS-Berechtigungen (Vererbung deaktivieren)?

    Na ja, das bedeutet, ich (der Admin) muss die Berechtigungen für jeden Ordner unterhalb von \\Server01\Einkauf pflegen. Eigentlich stelle ich ja der Gruppe Einkauf den Ordner Einkauf zur Verfügung, damit sie sich darunter ihre eigene Ordnerstruktur einrichten kann. Wenn ich dann für jeden Ordner, der direkt unterhalb von Einkauf liegt, erst die Berechtigungen anpassen muss, ist das ja auch nicht Sinn der Sache. Ausserdem bleibt das Problem letztendlich das gleiche. Mal angenommen, ich mach es so wie du sagst, also auf \\Server01\Einkauf\Leitung hat nur die Gruppe EinkaufLeitung Zugriff. Jetzt kommt nächste Woche die Anforderung, dass auf den Ordner \\Server01\Einkauf\Leitung\ObersteLeitung die Gruppe EinkaufObersteLeitung Modify-Berechtigung haben soll, die Gruppe EinkaufLeitung keinen Zugriff. Damit stehe ich wieder vor dem gleichen Problem. Zugegeben, ein recht konstruiertes Problem, aber kann man es lösen, rein technisch gesehen? Danke Martin
  10. Hallo, in diversen NTFS-BestPractises liest man immer wieder, dass man die Vererbung möglichst nicht unterbrechen soll. Solange man in tieferliegenden Ordnern nur zusätzliche Berechtigungen vergibt, kein Problem, aber wie soll man Berechtigungen wegnehmen, ohne die Vererbung zu deaktivieren? Beispiel: Es gibt die Freigabe \\Server1\Einkauf Freigabeberechtigung: Jeder:Modify NTFS-Berechtigung: Gruppe Einkauf:Modify Unterhalb gibt es u.a. den Unterordner: \Leitung Die Gruppe EinkaufLeitung soll auf den Ordner Leitung Modify-Berechtigung haben, die Gruppe Einkauf keine Berechtigung. Wie soll das gehen, ohne die Vererbung zu deaktivieren? Mir fällt dazu nur folgendes ein: - ich erstelle einen Pseudo-Ordner \\Server01\Einkauf\Pseudo, auf diesen verweigere ich der Gruppe Einkauf den Zugriff - in diesen Pseudo-Ordner kommt der Ordner Leitung, also \\Server01\Einkauf\Pseudo\Leitung - auf den Ordner \\Server01\Einkauf\Pseudo\Leitung bekommt die Gruppe EinkaufLeitung Modify-Berechtigung Ich hab´s jetzt zwar nicht ausprobiert, aber da ein explizites Allow Vorrang hat vor einem geerbten Deny, sollte es funktionieren. Aber schön finde ich das nicht. Hat jemand eine andere Idee? Danke und Gruß Martin
  11. Hallo, ich hätte mal eine Frage zu richtigen Vorgehenseweise, wenn eine Gruppe Zugriff auf einen Ordner bekommen soll, der weiter unten in einer Ordnerstruktur liegt. Das wird jetzt etwas länger. Sorry, aber vielleicht mag es sich jemand antun. Beispiel: Es gibt die Freigabe \\Server1\Europa Freigabeberechtigung: Jeder:Modify NTFS-Berechtigung: Gruppe Europa:Modify Unterhalb gibt es u.a. diese Unterordner: \Deutschland\Bayern\Oberbayern\Muenchen Jetzt bekommt die Gruppe Muenchen_M (deren Mitglieder nicht bereits in der Gruppe Europa enthalten sind) Modify-Rechte auf den Ordner Muenchen. Das bringt den Mitgliedern der Gruppe erstmal noch nichts, weil sie mangels fehlender Rechte auf die übergeordneten Ordner nicht an den Ordner Muenchen rankommen. Dafür gibts mehrere Lösungen: - die User bekommen eine Verknüpfung, die direkt nach Muenchen zeigt - man hängt Muenchen in eine DFS-Struktur ein - man arbeitet mit List-Berechtigungen bzw. List-Gruppen Mir gehts jetzt mal um die Lösung mit List-Gruppen. Wenn man nach NTFS BestPractises sucht, stößt man sehr schnell auf die Firma aikux mit den Produkten 8Man und Migraven. Dazu gibts einige Videos. In diesem hier http://www.migraven.com/videos/webinarvideos/best-practice-ntfs-berechtigungen/ ist ab 29:40 die Sache mit den List-Gruppen beschrieben. Auf mein Beispiel bezogen würde das folgende Gruppen und Berechtigungen bedeuten: - auf Ebene \\Server01\Europa bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied - auf Ebene \\Server01\Europa\Deutschland bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied - auf Ebene \\Server01\Europa\Deutschland\Bayern bekommt die Gruppe Muenchen_M List-Berechtigung - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern bekommt die Gruppe Muenchen_M List-Berechtigung D.h., es wird nicht durchgängig mit List-Gruppen gearbeitet, sondern nur bis zur Hälfte der Ordnerstruktur. Begründet wird das mit einer gesunden Mischung aus der Anzahl der benötigten Gruppen und der notwendigen ACL-Änderungen, also eine Mischung aus diesen beiden Extremen: Extrem 1 (viele Gruppen): - auf Ebene \\Server01\Europa bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied - auf Ebene \\Server01\Europa\Deutschland bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied - auf Ebene \\Server01\Europa\Deutschland\Bayern bekommt eine Gruppe Bayern_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern bekommt eine Gruppe Oberbayern_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied Extrem 2 (viele ACL-Änderungen): - auf Ebene \\Server01\Europa bekommt die Gruppe Muenchen_M List-Berechtigung - auf Ebene \\Server01\Europa\Deutschland bekommt die Gruppe Muenchen_M List-Berechtigung - auf Ebene \\Server01\Europa\Deutschland\Bayern bekommt die Gruppe Muenchen_M List-Berechtigung - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern bekommt die Gruppe Muenchen_M List-Berechtigung Ich hab irgendwann noch von einer anderen Variante gelesen (die nicht in dem Video vorkommt). Für jede Ebene wird eine List-Gruppe erstellt. Jede List-Gruppe wird in der direkt darüber liegenden List-Gruppe Mitglied, in der List-Gruppe der untersten Ebene schliesslich wird die eigentliche Berechtigungsgruppe Mitglied. Auf mein Beispiel bezogen: - auf Ebene \\Server01\Europa bekommt eine Gruppe Europa_L List-Berechtigung, in dieser wird die Gruppe Deutschland_L Mitglied - auf Ebene \\Server01\Europa\Deutschland bekommt eine Gruppe Deutschland_L List-Berechtigung, in dieser wird die Gruppe Bayern_L Mitglied - auf Ebene \\Server01\Europa\Deutschland\Bayern bekommt eine Gruppe Bayern_L List-Berechtigung, in dieser wird die Gruppe Oberbayern_L Mitglied - auf Ebene \\Server01\Europa\Deutschland\Bayern\Oberbayern bekommt eine Gruppe Oberbayern_L List-Berechtigung, in dieser wird die Gruppe Muenchen_M Mitglied Wie macht ihr es? Danke und Gruß Martin
  12. Hab´s gefunden. Die Stichwörter sind Pass-Through Session und NativeDriveMapping http://support.citrix.com/article/CTX127872
  13. Hallo, wir haben eine 2008R2 Terminalserverfarm mit Citrix XenApp 6.5. Jetzt wirds ein bissl verwirrend. Vorab: Es geht nicht darum, dass in der (ersten) Citrix-Terminalserversession die lokalen Laufwerke des Clients zur Verfügung stehen, sondern in der Terminalserversession wird eine zweite Citrix-Terminalserversession auf einen anderen Terminalserver (keiner aus der Farm, steht extern, nicht in unserem Verwaltungsbereich) aufgebaut und in dieser (zweiten) Session sollen die lokalen Laufwerke der ersten Session zur Verfügung stehen. Der Farm-Terminalserver ist in diesem Fall also der Client. Also so: Client >>> startet Session (ica) >>> Farm-TS >>> daraus eine zweite Session (ica) >>> externer TS (hier sollen die Laufwerke des Farm-TS zur Verfügung stehen). Mein erster Gedanke war, dass am externen TS das Durchschleifen von Laufwerken verboten ist. Das ist aber nicht der Fall, denn wenn die erste Session per rdp aufgebaut wird, funktioniert es wie gewünscht, wird die erste per ica aufgebaut, funktionierts nicht. Client > ica > Farm-TS > ica > ext. TS: keine Laufwerke von Farm-TS Client > rdp > Farm-TS > ica > ext. TS: Laufwerke von Farm-TS vorhanden Muß also an einer Citrix-GPO liegen, die bei der ersten Session greift. Bevor ich die jetzt mühsam zerpflücke, vielleicht weiß jemand, welche das sein könnte. Ach ja. In der Citrix-GPO für die erste Session sind Clientlaufwerke verboten, aber nach meinem Verständnis ist das völlig unabhängig von der zweiten Session. Danke und Gruß Martin
  14. Hurra. Den Button (Berichterstellung und Protokollierung) hab ich wohl bisher übersehen. :nene: Und dort find ich auch mein Verzeichnis. Danke für die Unterstüzung :jau: Gruß Martin
  15. Also, heute liegt, wie vermutet, eine logdatei des Wartungsplanes im genannten Verzeichnis. Die Fehlermeldung kam nicht mehr. Aber wo das eingestellt sein soll, kann ich leider nach wie vor nicht finden. Ich denke schon, dass ich genau an der von dir genannten Stelle nachschaue. Im Screenshot1 sind alle Tasks des Datenbanksicherungs-Wartungsplans zu sehen, im Screenshot2 die Einstellungen des Tasks "Datenbank sichern". Und auch wenn ich mir den SQL-Befehl des Tasks "Datenbank sichern" anzeige (Button T-SQL anzeigen), kommt darin das ominöse Verzeichnis nicht vor.
×