Komplexitätsvoraussetzungen im AD anpassen

[NorbertFe 2.050]

Nein das können nicht nur die großen, aber die sind bereit dafür zu bezahlen. ;)

[LK28 11]

Mich würde mal interessieren, wie ihr das handhabt mit den regelmäßigen Passwort Wechseln der Service Accounts? Gerade in Bezug auf Kerberoasting.

Oder vertraut ihr euren langen komplexen Passwörtern so sehr, dass ihr sie nicht ändert?

 

Darauf aufbauend die Frage: Regelmäßige Passwortwechsel überhaupt möglich, wenn mit dem Service Account wichtige Applikations Dienste betrieben werden?

 

Ich persönlich finde das Thema PAM (Privileged Access Management) in dem Bezug ganz spannend, unter anderem wegen der Frage der Service Accounts. 

 

Was eine Komplexität und Länge von 10 Zeichen angeht, und dann zu sagen, dass die Bordmittel nicht ausreichen, ist ein Widerspruch in Sachen Sicherheit.

[daabm 1.357]

vor einer Stunde schrieb LK28:

Regelmäßige Passwortwechsel überhaupt möglich,

Nur mit großem Aufwand, wenn viele Syteme dahinter stecken -> nutze gMSA wo immer möglich. Und sorge von Anfang an dafür, daß nur die nötigen Computer den gMSA nutzen dürfen.

[cj_berlin 1.323]

vor 13 Minuten schrieb daabm:

Nur mit großem Aufwand, wenn viele Syteme dahinter stecken -> nutze gMSA wo immer möglich. Und sorge von Anfang an dafür, daß nur die nötigen Computer den gMSA nutzen dürfen.

+1 zu gMSA

 

und dort, wo es nicht möglich ist, gMSA zu nutzen:

• ein Account pro Service --> Abhängigkeiten zwischen den Services kennen und Kennwörter konzertiert und skriptgesteuert im Mini-Wartungsfenster durchtauschen. Ich habe bei einem Kunden eine 3-Tier-Anwendung aus >10 Servern, wo der Wechsel sämtlicher Service-Kennwörter unter 20 Sekunden dauert. Das muss einmal in 14 Tagen oder einmal im Monat möglich sein.
• gleicher Service auf mehreren Computern unter demselben Account NUR DANN, wenn die Computer tatsächlcih geclustert sind und es nicht zu vermeiden ist (pseudo-gMSA)
• Accounts für Sachen wie LDAP-Lookup, was in Tausenden von Appliances eingetragen wird und nur drei Attribute bei 10% der Objekte lesen soll --> in einer Gruppe, die ein explizites Deny auf privilegierte OUs, Objekte und kritische Attribute hat. Kein Telefonbuch der Welt braucht Leserechte auf userAccountControl, adminCount, servicePrincipalName usw.

bearbeitet 7. Dezember 2022 von cj_berlin

[daabm 1.357]

vor 14 Minuten schrieb cj_berlin:

in einer Gruppe, die ein explizites Deny auf privilegierte OUs, Objekte und kritische Attribute hat.

 

Deny brauchst mit LOM nicht, da arbeiten wir grad hart daran - daß das Identity Management nur noch dort rein kann, wo es rein muß. Und es zeigte sich leider auch, daß Deny bei LOM nicht funktioniert wie erwartet, weil LOM sich nur für Allow zu interessieren scheint - trotz Deny auf ne Top-OU können wir in Downlevel-OUs noch lesen... Wenn wir (natürlich) den DN kennen.

[cj_berlin 1.323]

Was ist LOM?

[daabm 1.357]

List Object Mode (sorry, das ist bei uns sowas von gängig... ) - ABE in AD.

[testperson 1.682]

Hi,

vor 7 Minuten schrieb cj_berlin:

Was ist LOM?

der List Object Mode. Bspw.: Active Directory: Controlling Object Visibility – List Object Mode - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)

 

Gruß

Jan

[cj_berlin 1.323]

vor 6 Minuten schrieb daabm:

trotz Deny auf ne Top-OU können wir in Downlevel-OUs noch lesen... Wenn wir (natürlich) den DN kennen.

Deswegen sage ich ja: Explizites Deny auf Objekte und Attribute  

 

Wird auch im verlinkten Artikel erwähnt, wenn ich mich daran noch richtig erinnere.

bearbeitet 7. Dezember 2022 von cj_berlin

[daabm 1.357]

Gerade eben schrieb cj_berlin:

Deswegen sage ich ja: Explizites Deny auf Objekte und Attribute  

 

Jepp, unser Problem - wir dachten (ok, wir waren jung und hoffnungsvoll), daß ein Deny "oben" reicht. Tut er aber nicht... Bei ABE funktioniert es wie erwartet, bei LOM nicht. Schade, Microsoft

[meinerjunge 10]

Da hab ich ja was losgetreten..

 

Also noch mehr Zeichen sind besser als mehr Zeichen, das ist klar.

 

Aber mit den Komplexitätsvoraussetzungen komme ich dann trotzdem nicht weiter, da diese ja auch beinhalten "Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.".

Wie soll man das bei einer Zeichenlänge von 10+ verhindern?

 

D.h. ich kann diese Komplexitätsvoraussetzungen in der Richtlinie nicht aktivieren und dann auch nicht verhindern, das jemand 20 x ein "a" als Passwort vergibt.

 

MfG Meiner

[NorbertFe 2.050]

vor 4 Minuten schrieb meinerjunge:

"Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.".

Wie soll man das bei einer Zeichenlänge von 10+ verhindern?

Das funktioniert hier seit Jahren problemlos. ;) Schreibst du immer den Nutzernamen in Kennwort oder wie? ;)

 

vor 5 Minuten schrieb meinerjunge:

D.h. ich kann diese Komplexitätsvoraussetzungen in der Richtlinie nicht aktivieren und dann auch nicht verhindern, das jemand 20 x ein "a" als Passwort vergibt.

Die Schlußfolgerung verstehe ich nicht, es sei denn du schreibst immer den Nutzernamen ins Kennwort. :p

[NilsK 2.940]

Moin,

 

da sekundiere ich Norbert. Ich nutze seit ca. 20 Jahren sehr lange Kennwörter und habe damit noch nie ein Problem mit den vordefinierten Kennwortrichtlinien gehabt. Und ja, es geht um eine große Zahl sehr langer Kennwörter. Mein Eindruck ist, dass ihr euch da zu "akademische" Gedanken vor dem Hintergrund traditioneller Ansätze macht.

 

Aber wie gesagt - wenn das bei euch so ist, dann recherchier halt nach einem Drittanbietertool.

 

Gruß, Nils

 

[cj_berlin 1.323]

+1. Ich habe auch noch nie Probleme mit den "im Namen vorkommenden" Zeichen gehabt.

[mwiederkehr 373]

vor 27 Minuten schrieb meinerjunge:

Aber mit den Komplexitätsvoraussetzungen komme ich dann trotzdem nicht weiter, da diese ja auch beinhalten "Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.".

Wie soll man das bei einer Zeichenlänge von 10+ verhindern?

Meine Kenntnisse der Stochastik sind zu eingerostet, um beweisen zu können, dass die Wahrscheinlichkeit dafür bei zufälligen Passwörtern mit Sonderzeichen sehr klein ist.

 

Aber ich glaube, es liegt ein Missverständnis vor. Die Definition der Regel gemäss Microsoft:

Zitat

The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be included in the password. Tokens that are less than three characters are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.

Quelle: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh994562(v=ws.11)

 

"Substrings of the tokens are not checked" heisst, dass keine Teile von Namen geprüft werden. Ein "Hans Muster" kann also schon "ans" oder "ust" im Kennwort haben.