Jump to content

msDS-CreatorSid Attribut manuell löschen


Recommended Posts

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

Link to comment
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...

Edited by cj_berlin
  • Like 1
Link to comment

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.

 

 

Link to comment

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?

Link to comment
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.

  • Like 1
  • Thanks 1
Link to comment
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?

Link to comment

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?

Link to comment

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

 

  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...