msDS-CreatorSid Attribut manuell löschen

[phatair 39]

Hallo zusammen,

 

Bei uns in der Domäne steht der Wert ms-DS-MachineAccountQuota auf 0, so dass kein User ohne explizite Delegation ein Gerät in die Domäne aufnehmen kann. Es gibt eine extra AD Sicherheitsgruppe in der die User enthalten sind, die Geräte in die Domäne aufnehmen können und diese AD Gruppe ist in dann in der AD berechtigt.

Eine Frage hätte ich jetzt zum msDS-CreatorSid Attribut. Dieses wird ja erstellt, wenn ein User ohne Delegation ein Gerät aufnimmt. Das ist nur dann möglich, wenn ms-DS-MachineAccountQuota nicht auf 0 steht. 

Oder sehe ich das falsch?

 

Ich habe nun bei uns nach Computerobjekten in der AD gesucht, die das Attribut msDS-CreatorSid besitzen. Mir werden hier fast alle Server aufgelistet. Diese wurden dann wohl vor der Anpassung des ms-DS-MachineAccountQuota Wertes in die Domäne aufgenommen und es wurde ein Account verwendet, der dafür nicht in der AD berechtigt war. Ich habe die SIDs geprüft, die bei den Servern im msDS-CreatorSid stehen, dass sind die Server Admin Accounts die auch jetzt das Recht haben Server in die Domäne aufzunehmen.

Soweit ist das also OK.

 

Meine Frage ist jetzt, kann ich diesen msDS-CreatorSid Eintrag irgendwie löschen oder muss ich dazu das Gerät aus der Domäne nehmen und wieder aufnehmen?

Seht ihr es als kritisch an, wenn das msDS-CreatorSid Attribut bei den Server gefüllt ist, auch wenn es sich dabei um SIDs der aktuellen Server Admins handelt?

In Bezug auf LAPS sollte das ja kein Sicherheitsrisiko darstellen, da diese Accounts das LAPS Passwort sowieso lesen dürfen und wenn einer der Admins nicht mehr im Unternehmen ist, wird der Account sowieso deaktiviert.

 

Für Meinungen/Infos wäre ich sehr dankbar.

Grüße

[cj_berlin 1.306]

vor 3 Stunden schrieb phatair:

 

Meine Frage ist jetzt, kann ich diesen msDS-CreatorSid Eintrag irgendwie löschen oder muss ich dazu das Gerät aus der Domäne nehmen und wieder aufnehmen?

Seht ihr es als kritisch an, wenn das msDS-CreatorSid Attribut bei den Server gefüllt ist, auch wenn es sich dabei um SIDs der aktuellen Server Admins handelt?

In Bezug auf LAPS sollte das ja kein Sicherheitsrisiko darstellen, da diese Accounts das LAPS Passwort sowieso lesen dürfen und wenn einer der Admins nicht mehr im Unternehmen ist, wird der Account sowieso deaktiviert.

Moin,

hast Du mal probiert, es zu löschen?  

Warum sollte das kritisch sein? So wie es jetzt ist, ist der jeweilige Admin ja vermutlich sogar Owner des Computer-Objektes - das wäre evtl. kritisch, wenn das Admin-Account kompromittiert wird. Aber die SID eines Accounts kann doch jeder lesen, also nicht "Jeder", sondern jeder  

Und welchen Bezug hat es zum LAPS? Wenn ein Angreifer wissen will, wer LAPS-Attribute lesen darf, fragt er auch danach und nicht nach obskuren Attributen...

bearbeitet 20. September 2022 von cj_berlin

[phatair 39]

Also wenn ich es jetzt nicht komplett falsch verstehe, kann der User der im msDS-CreatorSid steht das laps Kennwort auslesen. Deshalb prüfen wir das. 

Da jetzt nur admins enthalten sind und diese das laps Kennwort sowieso auslesen dürfen, halte ich es auch nicht für kritisch. 

 

Würde hier aber ein normaler User enthalten sein, da dieser z.b. einen computer in die Domäne aufnehmen durfte (da ms-DS-MachineAccountQuota nicht 0) könnte dieser user das laps Kennwort auslesen.

So verstehe ich das zumindest.

 

Auszug aus dem offiziellen laps Operation guide:

Zitat

Active Directory by default allows ordinary users to join machines to the domain, up to the limit imposed by the msDS-MachineAccountQuota attribute. The user must have local Administrator privileges on a machine in order to perform the join. When a machine is joined this way, the resultant security configuration on the machine account allows the joining user to read the value of the ms-Mcs-AdmPwd attribute, even after the user in question no longer has local Administrator privileges on a machine.

 

Machine that have been joined this way can be discovered by querying the msDS-CreatorSid attribute attribute, for example:

 

Get-ADComputer -LdapFilter '(msds-CreatorSid=*)' -SearchBase '<domain-or-OU-DN>' -SearchScope Subtree

 

You can prevent this issue by disabling the ability of ordinary users to join machines to the domain. This can be done by setting the ms-DS-MachineAccountQuota attribute to Zero.

 

 

[cj_berlin 1.306]

Moin,

nein, der Wert im Attribut verleiht dem User keine Berechtigungen am Computer-Objekt - meistens wird der User aber auch Owner sein, und daraus leiten sich die Rechte an, wenn auch nicht automatisch. Das ist aber per se ein Problem.

Das Attribut ist nur dafür da, das MachineQuota überwachen zu können.

[phatair 39]

Danke Dir Evgenij.

Da hatte ich einen Denkfehler und beim nochmaligen lesen ist es mir jetzt auch klar

Zitat

When a machine is joined this way, the resultant security configuration on the machine account allows the joining user to read the value of the ms-Mcs-AdmPwd attribute

Das sagt es ja eben aus, dass die Security configuration dann erlaubt das LAPS Attribut zu lesen und nicht das Attribut msDS-CreatorSid.

 

Es ist dann tatsächlich so, dass der entsprechende User dann als Owner eingetragen ist und auch direkt im Computerobjekt Berechtigungen hat.

Eine Frage hätte ich jetzt aber doch noch - wenn die Admin Accounts dann im Server Objekt stehen, sollte man dann den Domain Join von Servern über einen dedizierten Service Account durchführen? Wenn der Admin jetzt das Unternehmen verlässt, würde der User ja irgendwann gelöscht und damit würden im Server Computerobjekt SID Leichen entstehen. Oder löscht ihr Admin Accounts gar nicht, sondern deaktiviert diese nur, wenn die nicht mehr benötigt werden?

[daabm 1.348]

vor 20 Stunden schrieb phatair:

Oder löscht ihr Admin Accounts gar nicht, sondern deaktiviert diese nur, wenn die nicht mehr benötigt werden?

 

Ganz altes Thema Wir archivieren Security Principals, wir löschen sie nicht. Damit bleiben die SIDs erhalten und nachvollziehbar. UPN/sAMAccountName/CN etc. bekommen einen Timestamp, User/Computer werden deaktiviert, Sicherheitsgruppen in Verteilergruppen umgewandelt, geleert und Mailadresse ggf. entfernt.

[cj_berlin 1.306]

vor 5 Minuten schrieb daabm:

UPN/sAMAccountName/CN etc. bekommen einen Timestamp, 

Ist bei euch irgendwas davon mit personenbezogenen Informationen verknüpft oder alles generisch? Sprich: Wenn eine Lisa Müller bei euch anfängt, kriegt sie dann muellerl2, obwohl aktuell keine L. Müller in dieser Domain beschäftigt ist, aber mal beschäftigt war?

[daabm 1.348]

Ne, Lisa kriegt - wie jeder andere auch - eine 7stellige Kennung, die mit ihrem Namen nichts zu tun hat.

[NilsK 2.930]

Moin,

 

vor 21 Minuten schrieb daabm:

Sicherheitsgruppen in Verteilergruppen umgewandelt

dabei verlieren die doch ihren SID, oder?

 

Gruß, Nils

 

[cj_berlin 1.306]

vor einer Stunde schrieb NilsK:

dabei verlieren die doch ihren SID, oder?

Nö, auch Verteilergruppen haben eine SID. Die kommt nur nicht in den Anmeldetoken der Mitglieder.

[phatair 39]

Oh, ok :)

Also wir verwenden keine generischen Anmeldenamen und alle User zu archivieren ist nicht realisierbar.
Ich denke mal, wir werden das vielleicht auf Admin Accounts begrenzen und diese Accounts dann "archivieren".

 

Vielen Dank.

[NorbertFe 2.027]

vor 30 Minuten schrieb phatair:

zu archivieren ist nicht realisierba

Warum nicht? Wird die Platte dann voll? ;)

[phatair 39]

Ja, es muss aktuell überall gespart werden ;)

 

Nein, mal ernsthaft. Der UPN/SamAccountName ist bei uns immer der Nachname, wenn dieser schon belegt ist gibt es bestimmte Reihenfolge wie der Account benannt wird.

Nun war mein erster Gedanke, wenn wir die Accounts deaktivieren und "archivieren" blockiere ich damit ja eben mögliche neue Accounts, die den gleichen Namen tragen würden. Beispiel von Evgenij mit Frau Müller wurde ja schon genannt.

 

Aber ich könnte ja Accounts umbenennen, wenn die Mitarbeiter das Unternehmen verlassen. Dann wird aus Müller eben Müller220922. Wenn ich das, wie auch Martin schreibt, im UPN/SamAccountName/usw. mache, kann ich ja wieder einen Account Müller erstellen. Die SID wird dadurch ja nicht verändert, oder verstehe ich das gerade falsch?

[NilsK 2.930]

Moin,

 

richtig, das wäre ein möglicher Weg. Die Idee hinter dem Archivieren ist ja, dass die SIDs weiter aufgelöst werden können. Das wäre dann ja gegeben. Den "historischen" Namen kann man dann ja noch mal in einem anderen Feld dokumentieren, ebenso die Metadaten (Konto aktiv von/bis usw.).

 

Gruß, Nils

 

[phatair 39]

Ich denke das werden wir so machen. Gefällt mir gut die Idee und wir haben das Problem mit den SID Leichen nicht mehr.

Vielen Dank an alle!