ogle

Frage beantwortet! Vielen Dank für die Background-Infos :-)

Ah ok, jetzt ist es klar - vielen Dank! :)

Warum muss man das auf Domänenebene definieren? Und filtern sollte doch funktionieren indem man die Clients in verschiedene OUs aufteilt und die Richtlinie nur auf gewünschte OUs anwendet? So lässt sich zwar nicht nach Benutzer aber nach Clients filtern auf die die Richtlinie angewendet werden soll. Und genau da kommt dann meine Frage ins Spiel: Was passiert wenn sich ein Benutzer mit einem abgelaufen Kennwort an einem Client anmeldet auf den keine Richtlinie wirkt dass Kennworter ablaufen können. Oder habe ich bei der Sache irgendwo einen Denkfehler drin?

Weil man damit automatisch eine Gruppe hätte in der alle eingeschränkten Benutzer enthalten sind und man somit entsprechende Richtlinien darauf anwenden könnte. Natürlich nur wenn man die Administratoren aus der Gruppe entfernen kann ohne dass das systemweite Auswirkungen hat.

Ok, das beantwortet Frage eins - danke! :) Und Frage zwei?

Ja, aber wozu? Dadurch dass die Richtlinie ja sowieso bei jedem Login angewendet wird ist das ja nichts anderes als "/persistent:yes"?

Na ja, z. B. habe ich aktuell bei Netzlaufwerke die über Gruppenrichtlinien gemappt werden das Problem, dass diese eben NUR dann gemappt werden wenn bei der Sicherheitsfilterung auch die Clients aufgelistet sind bei denen sich die Benutzer anmelden und die Netzlaufwerke aus der Richtlinien gemappt werden sollen. Und in dem Fall handelt es sich ausschließlich um Benutzerkonfigurationen. Wie muss man sich dann das erklären?

Moin, wozu dient die Option "Verbindung wiederherstellen" bei Netzlaufwerke die über Gruppenrichtlinien gemappt werden? Die konfigurierten Netzlaufwerke werden ja sowieso bei jedem Login erneut verbunden wenn die Richtlinie ausgeführt wird?

Moin, wird beim AppLocker bis auf die zugelassenen bzw. verweigerten Regeln alles andere automatisch erlaubt oder verweigert? Kann man diese Arbeitsweise umstellen?

Na ja, z. B. habe ich aktuell bei Netzlaufwerke die über Gruppenrichtlinien gemappt werden das Problem, dass diese eben NUR dann gemappt werden wenn bei der Sicherheitsfilterung auch die Clients aufgelistet sind bei denen sich die Benutzer anmelden und die Netzlaufwerke aus der Richtlinien gemappt werden sollen. Und in dem Fall handelt es sich ausschließlich um Benutzerkonfigurationen. Wie muss man sich dann das erklären?

Ok, das heißt dann also, dass in einer Gruppenrichtlinie in welcher ausschließlich Computerkonfigurationen definiert sind bei der Sicherheitsfilterung auch nur die Computer und KEINE Benutzer ausgewählt werden müssen auf welche die Richtlinie angewendet werden soll?

Ok, angenommen man hat nun eine einzige Richtlinie mit der Einstellung "Maximales Kennwortalter" definiert und diese ausschließlich mit der OU-1 verknüpft. Wenn sich nun ein Benutzer an einem Rechner aus der OU-1 anmeldet und sein Kennwort bereits abgelaufen ist dann muss er sein Kennwort logischerweise ändern bevor er sich anmelden kann. Was passiert nun aber wenn er sich an einem Rechner aus der OU-2 anmeldet und sein Kennwort bereits ebenfalls abgelaufen ist?

Moin, welche Einstellung hat Vorrang, die Option "Kennwort läuft nie ab" im Benutzerkonto, oder eine aktivierte Gruppenrichtlinie mit der Einstellung "Maximales Kennwortalter"? Kann man die Priorität irgendwie beeinflussen? LG

Da habe ich andere Erfahrungen gemacht, denn mit aktivierter UAC können die Benutzer z. B. nicht auf den Server Manager zugreifen ohne dass ein Authentifizierungs-Prompt erscheint. Bei deaktivierter UAC öffnet sich der Server Manager problemlos. Klar können die Benutzer dann trotzdem nichts konfigurieren, aber ich möchte trotzdem nicht, dass er sich ohne Authentifizierungs-Prompt öffnet. Berechtigungen worauf? Auf den Profilpfad haben sie ja bereits die entsprechenden NTFS-Berechtigungen.

Moin, warum greift eine definierte Richtlinie in der Computerkonfiguration für Admins obwohl bei Sicherheitsfilterung nur bestimmte Benutzer ausgewählt sind und bei Delegierung sogar die Berechtigung "Gruppenrichtlinie übernehmen" für Admins auf verweigern steht? GRuß

Moin, hat jemand eine Idee, warum auf einem Windows Server 2012 R2 die Benutzerkontensteuerung komplett deaktiviert wird, wenn man die Richtlinie "Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen" deaktiviert? Laut Text bezieht sich das ja nur auf Administratoren und nicht auf alle Benutzer... Hintergrund ist der, dass alle Admin Konten z. B. auf den Profilpfad der Benutzer "C:\Users\*" zugreifen können sollen, ohne dass die Meldung "Sie verfügen momentan nicht über die Berechtigung des Zugriffs auf diesen Ordner" mit "Fortsetzen" bestätigt werden muss, da ja die Admin Konten aus NTFS-Sicht Zugriff haben. Beim integrierten Administratorkonto funktioniert das ja bereits standardmäßig. PS: Beim Bestätigen mit "Fortsetzen" wird übrigens jedes Mal der Benutzer in die NTFS-Berechtigungen mit aufgenommen was ich zum einen unnötig finde und es das Ganze bei zehn Admin Konten irgendwann unübersichtlich macht.

Würde wahrscheinlich auch funktionieren, hat aber bereits mit dem Pfad von MurdocX super funktioniert... Vielen Dank :)

Habe die Option "Verknüpfung aktiviert" an der entsprechenden Stelle für die beiden GPOs abgehakt - testweise - warum sollte man das nicht tun? Was hat das fü Auswirkungen bis auf dass die Richtlinien nicht mehr aktiv sind? Die config files unter "C:\Windows\System32\AppLocker" zu löschen war die Lösung. Vielen Dank MurdocX! :)

Nein, hier gibt es bei mir keine Richtlinien. Die Richtlinien sind bei mir unter "\\server\SYSVOL\domain.local\Policies" da DC. Hier gibt es aber aktuell nur die "Default Domain Policy" und die "Default Domain Controllers Policy" welche aber momentan deaktiviert und nicht verknüpft sind. Daher ist meine Vermutung dass sich der Server die Policies aus der Registry zieht...?

Nein, dann greifen keine Policies mehr. Nur wenn der Dienst "Anwendungsidentität" gestartet ist. Ich möchte aber den AppLocker einsetzen, nur eben nicht mit diesen nicht mehr vorhandenen Policies die trotzdem greifen sobald der Dienst "Anwendungsidentität" gestartet ist. PS: Nach beenden des Dienstes muss auch der Server neu gestartet werden ansonsten ist das wirkungslos.

Dass keine Gruppenrichtlinienobjekte angewendet wurden. Weder für Computer noch für Benutzer und trotzdem greifen nach start des Service "Anwendungsidentität" die ursprünglichen Policies. Sind die Policies vielleicht noch irgendwo in der Registry hinterlegt und wurden beim Löschen der GPOs nicht mitgelöscht?

Hallo, ist es für ein Windows System erforderlich, dass Domänen-Admins in der Gruppe "Domänen-Benutzer" sind, oder kann ich die Domänen-Admins ohne Bedenken aus der Gruppe entfernen? Gruß

Hallo, hat jemand eine Erklärung dafür, warum nicht mehr vorhandene Policies - da inkl. Gruppenrichtlinien gelöscht - für AppLocker auf einem Windows Server 2012 R2 greifen? Um das auch zu 100 % ausschließen zu können sind nun alle vorhandenen GPOs deaktiviert. Sobald man jedoch den Service "Anwendungsidentität" startet, dann greifen sofort die Policies die es mal gab. Allein dadurch dass alle vorhandenen GPOs deaktiviert sind dürfte nach meinem Verständnis in der Richtung nichts greifen. Um die Policies wieder außer Kraft zu setzen hat bis jetzt nur ein deaktivieren des Dienstes und ein anschließender Reboot geholfen. Gruß

Funktioniert leider nicht. Der Eintrag passt bei mir. Hm, dann muss es wohl nochmal irgendwo was geben... Fehler gefunden - ich weiß zwar nicht warum, aber der Eintrag in "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]" wurde nach meiner Änderung nochmals überschrieben. Vielen Dank euch beiden :)

An der Stelle stand in der Registry tatsächlich der Pfad "C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Administrative Tools" drin, aber auch nach Änderung nach "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools" können die Benutzer weiterhin nicht darauf zugreifen, weil die Verlinkung immer noch auf den Profilpfad des Administrators zeigt. Noch eine Idee? Reboot wurde bereits durchgeführt.