NTLMv1: LmCompatibilityLevel - Domänenweit auf 5?

[wznutzer 35]

Guten Morgen,

 

NTLMv1 sollte man idealerweise deaktiviert haben. Nun ist es so, dass es wahrscheinlich hier und da (wie bei mir) noch Überbleibsel aus vergangenen Zeiten gibt, in denen man die Clients per GPO auf 3 gesetzt hat. Bei allen Windows-Systemen die Support haben ist das der Defaultwert.

 

Könnte ich nicht einfach in der "Default Domain Policy" das auf 5 setzen und die alte Client-GPO löschen? Bei den DCs sollte das sowieso gemacht werden und bei den Clients schadet es nicht. Irre ich mich?

 

Danke und Grüße

 

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

[NorbertFe 2.034]

Das ist "normalerweise" kein Problem. Und wenn doch, siehst du das ja dann ;)

[zahni 554]

Die Default-Vorgabe gemäß CIS-Benchmark ist

 

"Send NTLMv2 response only. Refuse LM & NTLM" Also kann man es in der Default Domain Policy setzen und überall sonst auf "Nicht konfiguriert" setzen.

 

Am Ende wirst Du sehen, ob es mit Euren Anwendungen Probleme gibt. Man kann es auch wieder ändern und dann dem Hersteller aufs Dach steigen.

 

https://www.cisecurity.org/benchmark/microsoft_windows_server

bearbeitet 16. Oktober von zahni

[daabm 1.354]

[OT] In der DDP setzt man gar nichts . Man macht sich eine eigene, die man oberhalb der DDP verlinkt. Und da kommen auch nur Settings rein, die da reingehören - Account und Kerberos, sonst nichts. [/OT]

[wznutzer 35]

vor 17 Stunden schrieb daabm:

[OT] In der DDP setzt man gar nichts . Man macht sich eine eigene, die man oberhalb der DDP verlinkt. Und da kommen auch nur Settings rein, die da reingehören - Account und Kerberos, sonst nichts. [/OT]

Zufällig habe ich das sogar gemacht. Die Stufe 3 aus der DDP raus und 5 in eine eigene GPO. Die spezielle GPO für DCs die ich hatte, ist dann auch überflüssig. Allerdings verstehe ich die Aussage nicht komplett. Warum oberhalb und warum meinst du Settings zu Accounts und Kerberos kommen in die DDP oder gerade nicht?

 

Ich habe tatsächlich mal angefangen alles in eigene GPOs zu packen mit eindeutiger Benennung. Aber, wie gesagt, das war Zufall, das hätte ich auch ohne Bedenken in die DDP gemacht, Stufe 3 war ja auch drin.

1)

Warum sollte man nichts in die DDP packen? Organisatorisch verstehe ich das, wenn man einen Fehler sucht und GPOs in Verdacht hat, ist es ja b***d in einer Richtlinie, die man deaktivieren will, ganz viele Sachen zu haben. Gibt es auch technische Gründe?

2)

Gibt es ein Limit oder "best practice", dass man nicht mehr als X GPOs haben sollte?

3)

Was für Settings zu Accounts und Kerberos meinst Du?

 

Danke und Grüße

Am 16.10.2024 um 09:24 schrieb NorbertFe:

Und wenn doch, siehst du das ja dann ;)

Scheint tatsächlich kein Problem zu sein :-).

[NorbertFe 2.034]

vor 3 Minuten schrieb wznutzer:

Warum oberhalb

In der Abarbeitungsreihenfolge. Damit deine wirkt und nicht irgendwas, was irgendwer mal in die DDP schreibt.

 

vor 4 Minuten schrieb wznutzer:

warum meinst du Settings zu Accounts und Kerberos kommen in die DDP

Weils da einige Besonderheiten mit der DDP gibt.

 

vor 5 Minuten schrieb wznutzer:

Warum sollte man nichts in die DDP packen?

Weils die DDP ist und die ist halt nicht dafür gedacht, dass man sie filtert oder ähnliches. Denn sie soll ja für alle gelten und je mehr du da reinpackst, umso eher wirst du etwas finden, was du da besser nicht reingepackt hättest. Und genau deswegen packt man da mit der oben erwähnten Ausnahme am besten gar nichts rein.

 

vor 6 Minuten schrieb wznutzer:

Gibt es ein Limit oder "best practice", dass man nicht mehr als X GPOs haben sollte?

Nein, das hängt vor allem von deiner Arbeitsweise und Organisation deiner OUs usw. ab.

 

vor 6 Minuten schrieb wznutzer:

Was für Settings zu Accounts und Kerberos meinst Du?

 

Password Richtlinie und Kerberostickets.

vor 7 Minuten schrieb wznutzer:

Scheint tatsächlich kein Problem zu sein :-).

Manchmal ist es so einfach.

[zahni 554]

Ich für meinen Teil nutze die DDP für domain-weite Security Policies und Zertifikate. Gerade die Kennwirtrichtlinie muss bei uns zentral definiert sein, 

Zumal ich am Ende zur Prüfung von Härtungsvorgaben nicht "überall" gucken will. Andere GPO werden dort nicht definiert.

 

[wznutzer 35]

vor 2 Stunden schrieb NorbertFe:

In der Abarbeitungsreihenfolge. Damit deine wirkt und nicht irgendwas, was irgendwer mal in die DDP schreibt.

Ach jetzt wirds Tag, oberhalb meint die Verknüpfung an von der Zahl her niedrigerer Stelle . Aber die GPOs der OUs können dann ja noch immer das "überschreiben".

vor 2 Stunden schrieb NorbertFe:

Weils da einige Besonderheiten mit der DDP gibt.

Organisatorische oder technische Besonderheiten. Ist die DDP nicht den anderen gleichgestellt?

vor 2 Stunden schrieb NorbertFe:

Password Richtlinie und Kerberostickets.

Passwortrichtlinie ist separat und steht an Stelle 1 .

[NorbertFe 2.034]

vor 23 Minuten schrieb wznutzer:

Aber die GPOs der OUs können dann ja noch immer das "überschreiben".

Grundsätzlich ja, es sei denn man setzt auf der DDP den Haken bei erzwingen. Aber meinen Kunden sage ich meist: Wer "erzwingen" setzen muss hat das Konstrukt nicht verstanden. ;)

[toao 4]

2 hours ago, wznutzer said:

Ach jetzt wirds Tag, oberhalb meint die Verknüpfung an von der Zahl her niedrigerer Stelle . Aber die GPOs der OUs können dann ja noch immer das "überschreiben".

Organisatorische oder technische Besonderheiten. Ist die DDP nicht den anderen gleichgestellt?

Passwortrichtlinie ist separat und steht an Stelle 1 .

OffTopic
Hi,

ein kurzer Hinweis, bezüglich Deiner Aussage "Aber die GPOs der OUs können dann ja noch immer das "überschreiben". (Und da die DDP allgemein angesprochen wurde.) Dies trifft nicht auf Password Policy settings zu, diese werden by design ausschließlich über GPO's applied, die auf "domain level" verknüpft wurden.

/Offtopic

 

Gruß,

toao

[daabm 1.354]

vor 6 Stunden schrieb NorbertFe:

Weils da einige Besonderheiten mit der DDP gibt.

 

Um das aufzuklären - da gibt's mehrere Aspekte...

 

DDP und DDCP haben statische GUIDs, die in jeder Domain gleich sind. Mit dcgpofix kann man den "Originalzustand" wiederherstellen. Das ist der eine Grund, daß man die nicht anfasst. Wenn was damit schiefgeht und man dcgpofix braucht, sind eigene Anpassungen natürlich weg.

 

Und dann gibt es noch das "Phänomen" der engen Verbindung zwischen Account-/Kerberos-Settings in Domain Policies und dem PDC-Emulator. Der ist der einzige Computer in der Domäne, der Kerberos-Settings anwendet, die mit der Domäne verlinkt sind. Und er ist der einzige Domain Controller, der Account-Settings verarbeitet, die ebenfalls mit der Domäne verlinkt sein müssen (Links an Domain Controllers werden ignoriert). Die wiederum schreibt er dann in Attribute im Domain Head (des Domänen-Objekts in Active Directory). Ändert man DORT jetzt was, dann findet das seinen Rückweg - aber nicht in die eigene GPO, sondern anhand der statischen GUID in die DDP. Ein "gpupdate" behebt dann die jetzt abweichenden Einstellungen im Domain Head, weil Security Settings per Default auch dann verarbeitet werden sollten, wenn sie sich nicht geändert haben (https://admx.help/?Category=Windows_11_2022&Policy=Microsoft.Policies.GroupPolicy::CSE_Security). Und selbst wenn man das nicht aktiviert - alle 960 Minuten werden sie zwangsweise verarbeitet, was man auch nicht abschalten kann. Ok, man kann schon, aber das wollen wir jetzt nicht breit treten... Und damit stellt man am Ende sicher, daß die eigenen Account-Settings aus der eigenen GPO auch dann wirksam sind, wenn jemand im Domain Head rumfuhrwerkt...

 

Hoffe das war jetzt nicht zu kompliziert

vor 7 Stunden schrieb wznutzer:

Gibt es ein Limit oder "best practice", dass man nicht mehr als X GPOs haben sollte?

 

Jein. Die Anzahl von GPOs ist irrelevant (unsere größten Domänen haben weit mehr als 10.000) - das sind ja einfach nur Container unter CN=Policies,CN=System und Ordner in Sysvol. Die Anzahl der GPO-Links pro OU ist limitiert, weil im GPLink-Attribut nur 999 GPO-CNs reinpassen. Und dann gibt es noch das Problem der Verarbeitungsgeschwindigkeit, aber das ist ein sehr weites Feld... Bissle was dazu hab ich mal runtergeschrieben: https://evilgpo.blogspot.com/search?q=performance

Aber das ist bei weitem nicht erschöpfend. "Eine GPO pro Setting" ist aber definitiv der falsche Weg.

[cj_berlin 1.315]

Die "Account Policy <--> DDP"-Magie hat, wenn ich mich recht erinnere, auch ihre Entsprechung in "Klassische Audit-Policy <--> DDCP", woher die Empfehlung resultiert, Auditing für DCs in der DDCP zu konfigurieren, die man vereinzelt noch liest. Tatsächlich nutzt aber vermutlich keiner mehr die klassische Variante, und für Advanced gibt es keinen solchen Rückkanal mehr. Aber an sich war der Gedanke nicht ganz falsch - setze ich mit AUDITPOL.EXE die Einstellungen auf einem DC, dübelt er sie in die DDCP, und eine Zeit später haben wieder alle DCs die gleichen Überwachungseinstellungen.

[wznutzer 35]

Am 17.10.2024 um 17:39 schrieb daabm:

Hoffe das war jetzt nicht zu kompliziert

Ich glaube ich habe es verstanden. Ich frage mich aber immer, wie kommt man an solche Informationen ?

 

Am 17.10.2024 um 17:39 schrieb daabm:

Jein. Die Anzahl von GPOs ist irrelevant (unsere größten Domänen haben weit mehr als 10.000)

Ich kann da zwei Nullen wegmachen und habe noch immer weniger . ==> andere Welten

[NorbertFe 2.034]

vor 15 Minuten schrieb wznutzer:

Ich frage mich aber immer, wie kommt man an solche Informationen ?

Lesen, probieren und regelmäßig mit den Fehlern konfrontiert werden. ;)

[daabm 1.354]

vor 2 Stunden schrieb wznutzer:

wie kommt man an solche Informationen

 

5 Jahre MVP Group Policy und ein Buch drüber schreiben, das hilft AD kennen, seit es AD gibt. Und 30 Jahre lang ein Enterprise Umfeld betreuen, das vom DOS PC LAN Programm über OS/2 LAN Server zu Windows migrierte.