ogle

Frage beantwortet!

Vielen Dank für die Background-Infos :-)

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

Dann interessiert das sowieso maximal lokale Benutzerkonten. Für domänenkonten musst du das auf domänenebene definieren. Und kannst es auch nicht filtern.

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?

Neugierige Frage, wozu soll es gut sein, was ist das Ziel?

es ist möglich, aber wozu?

"Ohne Bedenken" wäre ich dabei nicht.

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.

[understanding AppLocker Rules]

https://technet.microsoft.com/en-us/library/dd759068(v=ws.11).aspx

Ok, das beantwortet Frage eins - danke! :)

Und Frage zwei?

Das ist das /persistent:yes von net use.

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

Irgendwie logisch, oder?

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?

Irgendwie logisch, oder?

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?

Weil der Computerkonfiguration die Benutzer egal sind... Die interessiert sich nur für Computerberechtigungen.

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?

Die Einstellung im nutzerkonto hat Vorrang. Nein das kann man nicht konfigurieren.

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

Weil UAC nur für Admins relevant ist...

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.

Oder Du legst Dir eine eigene Admin-Gruppe an, der Du entsprechende Berechtigungen erteilst, das wäre die beste Lösung.

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.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2

Löschen...

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

Vielen Dank :)

Deaktiviert weil die Vererbung unterbrochen wurde, oder die Verknüpfung der Beiden komplett entfernt? Letzteres solltest du nicht tun!

 

Probiere es bitte mal mit einer leeren AppLocker Richtlinie. Der AppLocker speichert seine Konfiguration unter "C:\Windows\System32\AppLocker". Es könnte sich lohnen diese testweise zu verschieben. 

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! :)

Sind noch Richtlinien unter "C:\Windows\System32\GroupPolicy" vorhanden? Wenn ja, entferne diese und starte den Server neu. Greifen nun noch Richtlinien?

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...?

Der AppLocker läuft über den Dienst "Anwendungsidentität" (AppIDSvc). Beende den Dienst  und setze diesen auf "Deaktiviert". Tritt der Fehler dann noch auf?

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.

Was spuckt denn "gpresult /r" aus?

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ß

Probier doch mal ein neues Benutzerprofil für einen Benutzer aus. Das alte brauchst Du nicht zu löschen, alternativ einfach mit einem User anmelden, der auf dieser Maschine noch nie angemeldet war.

Funktioniert leider nicht.

Unter "WOW6432Node" ist der Eintrag auch nochmal vorhanden. Vielleicht fehlt dieser hier auch noch.

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Der Vorschlag von Sunny klingt auch nicht verkehrt. 

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 :)

Ich habe folgenden Eintrag bei mir exportiert. Dies in einer "reg"-Datei abspeichern und ausführen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"Common Administrative Tools"="C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Administrative Tools"

Es sei dazu gesagt, dass alle Änderungen an der Registry auf eigene Verantwortung durchgeführt werden  ;)

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.