Oct 13, 2023

2942

GPO - Kennwortrichtlinie zieht nicht

Hallo zusammen!
Ich habe nun schon auf Foren geschaut und finde leider keine Lösung.
Ich möchte eine GPO verteilen mit den aktuellen Kennwort Richtlinien.

Die GPO ist auf die Domäne verknüpft, die Standard dinge habe ich alle schon probiert.
Am client wird mit rsop.msc auch die richtigen einstellungen angezeigt, jedoch nicht angewendet.

Das spannende ist, dass es für lokale Konten zieht (die Richtlinie) - für Domänen User zieht sie jedoch nicht.

Ich habe eine Domain Controller Policy, diese sollte jedoch nicht stören und wird auch nicht auf normale Client PC´s angewendet.

Es gibt auch noch eine 2te Domain Policy für Benutzerkonfig, diese ist auch auf der domäne verknüpft. (jedoch sind hier die CK Config deaktiviert)

Bitte um Hilfe.
Danke!

2023-10-13 11_06_20-192.168.34.115 - remotedesktopverbindung

Please also mark the comments that contributed to the solution of the article

Content-Key: 13356334492

Url: https://administrator.de/contentid/13356334492

Printed on: May 4, 2024 at 07:05 o'clock

51 Comments

Latest comment

Hi.

Die GPO muss auf die DCs angewendet werden, DORT sind die Userkonten, dort wird überprüft.
Also auf die DC-OU verknüpfen, einmal GPupdate auf allen DCs und es läuft.

Hallo,
hier ein Screenshot..

2023-10-13 11_46_40-konsole mit rsat tools - [konsolenstamm_gruppenrichtlinienverwaltung]

Moin

Kennwortrichtlinie kann direkt ausschließlich auf der Default Domain Policy konfiguriert werden. Somit bist Du da am falschen Ort am konfigurieren.

Für granulare Kennwortrichtlinien musst Du Dich ein wenig weiter aus dem Fenster lehnen. Vgl. z.B. hier:
https://www.faq-o-matic.net/2007/05/21/mehrere-kennwortrichtlinien-in-ei ...

Gruß

Hallo,
vielen Dank das klingt logisch.
Muss die Default Domain Policy auch genauso heißen? - bei uns wurde die umbenannt.
Oder reicht es, wenn es die Default Policy ist egal welcher Name?

Ich werde es testen.
Vielen Dank und schönes WE!

Ich gehe davon aus, dass es technisch egal sein dürfte, wenn man der Policy einen anderen Namen gibt. GPO-Objekte werden immer über ihre SID angesprochen. Ich habe sie aber noch niemals umbenannt.
Ich halte es - gerade bei der Default Domain Policy - für keine gute Idee, diese mit einem anderen Namen zu versehen. Eben gerade weil das eine besondere Policy ist, die man schnell finden und zuordnen können sollte.

Gruß

Moin,

GPO-Objekte werden immer über ihre SID angesprochen.

ich meine bei GPOs sind es keine SID, sondern eben ID.

Ich halte es - gerade bei der Default Domain Policy - für keine gute Idee, diese mit einem anderen Namen zu versehen. Eben gerade weil das eine besondere Policy ist, die man schnell finden und zuordnen können sollte.

Um das finden geht es mir weniger. Meine bedenken geht eher in die Richtung, dass die GPO evtl. mal gelöscht wird und niemand daran denkt, dass es eine Default Policy ist bzw. war.

Gruß,
Dani

Hi,
meines Wissens muss es nicht DIE Default Domain Policy sein, aber diese GPO

muss in jedem Fall an der Domäne verlinkt sein und
sie muss von den DC's angewendet worden sein und
sie muss gelten, sprich: Es darf keine höherrangige GPO geben, welche ebenfalls an der Domäne verlinkt ist und etwas anderes in der Kennwortrichtlinie regelt

Hallo,
ich habe es nun getestet.. die Änderung zieht noch nicht...
Müssen alle Sicherheitseinstellungen in der gleichen bzw. in der Default Domain Policy eingetragen werden?
Aktuell habe ich die Kennwortrichtlinien in der Default Domain Policy eingetragen, jedoch sind einige Lokale Richtlinien in einer anderen Policy konfiguriert.

Sollte ich zum alles auf die Default Domain Policy umstellen, oder ändert sich hier nichts?

Danke!

Zitat von @Dani:
ich meine bei GPOs sind es keine SID, sondern eben ID.

Ja... Stimmt GUIDs...

Um das finden geht es mir weniger. Meine bedenken geht eher in die Richtung, dass die GPO evtl. mal gelöscht wird und niemand daran denkt, dass es eine Default Policy ist bzw. war.

Da meinen wir aber irgendwie das gleiche und drücken es nur unterschiedlich aus??!!

Zitat von @N3wReport:

Hallo,
ich habe es nun getestet.. die Änderung zieht noch nicht...
Müssen alle Sicherheitseinstellungen in der gleichen bzw. in der Default Domain Policy eingetragen werden?
Aktuell habe ich die Kennwortrichtlinien in der Default Domain Policy eingetragen, jedoch sind einige Lokale Richtlinien in einer anderen Policy konfiguriert.

Sollte ich zum alles auf die Default Domain Policy umstellen, oder ändert sich hier nichts?

Danke!

Ist das eine Live-System oder nur eine Spielwiese?

Wie ich schon oben geschrieben habe: Kennwortrichtlinien werden nur in der Default Domain Policy gesetzt und von dort verarbeitet.

Zitat von @emeriks:
meines Wissens muss es nicht DIE Default Domain Policy sein, aber diese GPO

muss in jedem Fall an der Domäne verlinkt sein und
sie muss von den DC's angewendet worden sein und
sie muss gelten, sprich: Es darf keine höherrangige GPO geben, welche ebenfalls an der Domäne verlinkt ist und etwas anderes in der Kennwortrichtlinie regelt

Das wäre mir jetzt neu. Wenn dem so wäre, dann könnte man ja über eine Sicherheitsfilterung doch diverse Kennwortrichtlinien direkt per GPO produzieren.

Du solltest in einem ersten Schritt mal schauen, was überhaupt die Default Domain Policy ist. Die kannst Du über die GUId identifizieren. Diese ist immer {31B2F340-016D-11D2-945F-00C04FB984F9}

Gruß

@Hubert.N

Das wäre mir jetzt neu.

Ich habe mir soeben die Mühe gemacht, das explizit auszuprobieren. Es ist wirklich so. Man muss nur - wie schon von mir geschrieben - dafür sorgen, dass diese GPO höherrangig ist.

Edit:
Beim Testen nicht vergessen, an allen DC's ein gpudate auszulösen.

Zitat von @emeriks:
Ich habe mir soeben die Mühe gemacht, das explizit auszuprobieren. Es ist wirklich so. Man muss nur - wie schon vom mir geschrieben - dafür sorgen, dass diese GPO höherrangig ist.

Auch ich habe es gerade eben getestet und muss eingestehen, dass Du richtig liegst

Hallo, es ist die richtige GUID!
Ich habe nun mal nur die Kennwortrichtlinien konfiguriert und die andere CK GPO deaktiviert.
Domäncontroller schon neugestartet.. jedoch zieht sie nicht.. wie genau lese ich aus welche gerade aktuell zieht?
Mit gpresult /h sehe ich keine Computerdetails..

gpupdate natürlich auf dc und client gemacht.

Habe nun erneut neu gestartet.. sie zieht nicht
Es gibt keine andere Policy die Computerkonfiguriationen verteilt..
Die Default Domain Policy ist auf der Domäne verlinkt!

rsop.msc am Client starten

Mit gpresult /h sehe ich keine Computerdetails..

Was dann? Du siehst damit, welche GPO die aktiven EInstellungen setzt, siehe hier:

rsop.msc am client:
schaut doch eigentlich alles richtig aus..
ich kann trotzdem 123456 als Passwort verwenden..

rsop.msc am client:

Doch nicht am Client. Wie gesagt: Domänenkonten verwalten die DCs.

sorry...
am dc schaut es nicht gut aus:

Zitat von @DerWoWusste:

Mit gpresult /h sehe ich keine Computerdetails..

Was dann? Du siehst damit, welche GPO die aktiven EInstellungen setzt, siehe hier:

Damit die Computer-GPOs zu sehen sind, musst Du

gpresult /h %temp%\res.html & %temp%\res.html

auf einem elevated command prompt ausführen.

Zitat von @DerWoWusste:

Damit die Computer-GPOs zu sehen sind, musst Du

gpresult /h %temp%\res.html & %temp%\res.html

auf einem elevated command prompt ausführen.

Okay hier:

Wie Du siehst: sie zieht auf diesem DC. Wenn Du das nun bitte auf den anderen DCs wiederholst, dann kannst Du schnell sehen, ob es wirkt.

Zitat von @DerWoWusste:

Wie Du siehst: sie zieht auf diesem DC. Wenn Du das nun bitte auf den anderen DCs wiederholst, dann kannst Du schnell sehen, ob es wirkt.

Hallo,
in dieser Test-Umgebung habe ich nur diesen DC.

Und Du kannst jetzt immer noch einem Domänen-Benutzer ein Passwort vergeben mit <9 Zeichen oder ohne Komplexität?

Bedenke bei der Komplexität, dass Kennwort1 bereits als komplexes Kennwort gilt!

Zitat von @emeriks:

Und Du kannst jetzt immer noch einem Domänen-Benutzer ein Passwort vergeben mit <9 Zeichen oder ohne Komplexität?

Ja z.B hallo1 funktioniert...

Zitat von @DerWoWusste:

Bedenke bei der Komplexität, dass Kennwort1 bereits als komplexes Kennwort gilt!

das weiß ich!
123456 geht auch..

Hast Du da eine PSO welche für diesen Benutzer gilt?
Schau mal in den Attributen des Benutzers unter "msDS-ResultantPSO".

Zitat von @emeriks:

Hast Du da eine PSO welche für diesen Benutzer gilt?
Schau mal in den Attributen des Benutzers unter "msDS-ResultantPSO".

ich bin mir nicht sicher was du genau meinst..
Der Attribute-Editor wird mir nicht angezeigt auch nicht mit erweiterten Features in der Anzeige..

Folgendes hab ich noch geschaut im ADAC, hier finde ich aber auch nichts (siehe bild)

Dann ist etwas defekt. Aber es gibt noch einen Weg: öffne secpol.msc am DC und stelle es dort ein und danach wieder gpupdate auf dem DC.

Hab ich eingestellt und siehe da es funktioniert sofort!
Was genau wird hier verwaltet bzw. sollte man diesen Weg verwenden?
Ich gehe davon aus, dass bisher genau diese Einstellungen in secpol.msc gezogen haben aber warum??

Das ist die lokale Sicherheitsrichtlinie. Sie gilt nur auf dem (einen!) DC, während die defdompol natürlich auif jedem DC gilt und auch auf jedem Client (wichtig für lokale Konten).

Warum die gezogen hat und nicht das Angezeigte aus gpresult /h, ist mir nicht klar.

Okay nun habe ich mal eine temporäre Lösung, die ich auf allen DC´s im live system einstellen kann/könnte.
Evtl. werden diese LokalenRichtlinien sowieso zwischen den DC´s gesyncht.

Seht ihr ein Problem es über diese Lokale Sicherheitsrichtlinie einzustellen?
Natürlich wäre es über GPO leichter und ersichtlicher..

Ich würde das zuerst gegenprüfen. Also nach dem Einstellen mit "secpol" explizit noch einmal mit "gpupdate /force" Richtlinien erneut anwenden lassen.
Was gilt danach?

Evtl. werden diese LokalenRichtlinien sowieso zwischen den DC´s gesyncht.

Nö.

Teste bitte zunächst die defdompol. Als Notnagel bleibt das ja noch.
Zusätzlich gibt es die Password Settings objects, die modernere Form der Kennwortrichtlinie

PS: warum noch Kennwörter? Nimm SmartCards.

Zitat von @DerWoWusste:
Zusätzlich gibt es die Password Settings objects, die modernere Form der Kennwortrichtlinie

Hatte ich ja schon geschrieben, dass mal das Attribut am User-Objekt überprüft werden sollte.

Zitat von @N3wReport:
ich bin mir nicht sicher was du genau meinst..
Der Attribute-Editor wird mir nicht angezeigt auch nicht mit erweiterten Features in der Anzeige..

Das muss in älteren Forest erst explizit aktiviert werden. Also solche, welche ursprünglich mit älteren Windows Versionen aufgesetzt wurden.

Beachte auch, dass der Reiter "Attribute-Editor" nicht angezeigt wird, wenn man das Benutzerobjekt über die Suche öffnet. Das ist ein "Feature" der MMC.

Sonst eben über ADSIEDIT.msc gehen.

Zitat von @emeriks:

Ich würde das zuerst gegenprüfen. Also nach dem Einstellen mit "secpol" explizit noch einmal mit "gpupdate /force" Richtlinien erneut anwenden lassen.
Was gilt danach?

nach gpupdate /force ziehen die Einstellungen die ich bei "secpol" eingestellt habe!

Zitat von @DerWoWusste:

Evtl. werden diese LokalenRichtlinien sowieso zwischen den DC´s gesyncht.

sorry.. was verstehst du unter defdompol?
PSO ja habe ich auch schon gehört, wir wollen es aber einfach nur einheitlich ausrollen für die ganze Domäne, schade das sies dies als so schwierig herausstellt

defdompol

Default Domain Policy

PSO

Nicht denken oder wollen. Überprüfen!

Zitat von @emeriks:

defdompol

Default Domain Policy

PSO

Nicht denken oder wollen. Überprüfen!

defdompol ist eingestellt, aber sie wird am client mit folgendem Befehl "gpresult /h %temp%\res.html & %temp%\res.html" auch angezeigt und upgedatet.. jedoch wirken die einstellungen nicht, sondern die von "secpol"

Okay wie genau überpüfe ich PSO... ich hätte heute schonmal einen Screenshot dazua gesendet, war der richtig?
Bin noch nicht sehr lange tätig im AD/GPO Bereich ;(

Es sind nicht die PSO, die wirken. PSOs überstimmen GPOs, ja, aber du hast doch selbst festgestellt, dass das aus secpol.msc zieht.

Du kannst/solltest nun
-anschauen, ob PSOs nicht besser sind und wenn ja, diese einsetzen. Wenn nein, DefDomPol in der Domain konfigurieren - vielleicht klappt es ja dort, wie gewollt.

Oder weg von Kennwörtern. Es wird langsam Zeit.

Zitat von @DerWoWusste:

Es sind nicht die PSO, die wirken. PSOs überstimmen GPOs, ja, aber du hast doch selbst festgestellt, dass das aus secpol.msc zieht.

Du kannst/solltest nun
-anschauen, ob PSOs nicht besser sind und wenn ja, diese einsetzen. Wenn nein, DefDomPol in der Domain konfigurieren - vielleicht klappt es ja dort, wie gewollt.

Oder weg von Kennwörtern. Es wird langsam Zeit.

Hallo,
ich denke ich werde es nun einfach über (voerst) nur eine PSO lösen!
Die weiße ich der Gruppe zu in dem ohnehin alle unsere User vorhanden sind.
Ich denke so habe ich eine saubere Lösung.
Was sagt ihr, bedenken?

PSO ist doch fein.

Dennoch werde ich nicht müde zu promoten, dass man Kennwörter loswird. Wenn Du schon eine CA hast, deployst Du virtuelle SmartCards mit sehr wenig Mühe und hast viel gewonnen und brauchst Dich nicht mehr mit Kennwortregeln abzugeben.

Zitat von @DerWoWusste:

PSO ist doch fein.

Dennoch werde ich nicht müde zu promoten, dass man Kennwörter loswird. Wenn Du schon eine CA hast, deployst Du virtuelle SmartCards mit sehr wenig Mühe und hast viel gewonnen und brauchst Dich nicht mehr mit Kennwortregeln abzugeben.

Hallo,
danke erstmal für die Hilfe.
Ja es ist definitiv ein Thema das angegangen werden sollte nur leider mit viel Aufwand verbunden ist.
So wie ich das verstehe dient die virtuall Smart Card dazu, dass sich der User nur anmelden kann wenn das TPM Modull des Geräts auch mit dem AD User zusammenpasst.. richtig?

Die virtuelle SmartCard ist ein Dateicontainer, der unter Zuhilfenahme des TPMs erzeugt wird. Darin ist dann, wie in einer Smartcard, ein Zertifikat enthalten, mit dem man sich anmelden kann. Es ist nur für den Jenigen nutzbar, der die PIN dazu kennt und kann auch nicht auf andere Rechner übertragen werden, was es also vom Kennwort unterscheidet und damit sicherer (aber weniger funktional) macht.

Einzurichten "from scratch" in wenigen Minuten. Anleitungen bei Microsoft, Kosten: Null.

Hallo!
Eine frage hätte ich noch zu den PSO, wird das auf allen DC´s synchronisiert?

Zitat von @DerWoWusste:

Die virtuelle SmartCard ist ein Dateicontainer, der unter Zuhilfenahme des TPMs erzeugt wird. Darin ist dann, wie in einer Smartcard, ein Zertifikat enthalten, mit dem man sich anmelden kann. Es ist nur für den Jenigen nutzbar, der die PIN dazu kennt und kann auch nicht auf andere Rechner übertragen werden, was es also vom Kennwort unterscheidet und damit sicherer (aber weniger funktional) macht.

Einzurichten "from scratch" in wenigen Minuten. Anleitungen bei Microsoft, Kosten: Null.

Okay danke für die erklärung.. der PIN ist dann auf den User zugewiesen oder kann er denn ganz einfach selber wechseln wie das Passwort?
Erster Gedanken wäre, was ist wenn sich ein User bei einem anderen Geräte mit seinen Daten anmelden möchte z.B Besprechungsraum?

der PIN ist dann auf den User zugewiesen oder kann er denn ganz einfach selber wechseln wie das Passwort?

Kann er selbst wechseln

was ist wenn sich ein User bei einem anderen Geräte mit seinen Daten anmelden möchte z.B Besprechungsraum?

Dort muss für ihn eine weitere virtuelle SmartCard eingerichtet werden. Oder aber echte SmartCards kaufen und verwenden. Gibt viele, die gleichzeitig auch als RFID Türkarte verwendet werden können (Safenet ID Prime MD 930 zum Beispiel).

Eine frage hätte ich noch zu den PSO, wird das auf allen DC´s synchronisiert?