Szenario
Active Directory verfügt über einen geplanten Hintergrundprozess namensSDPropdas regelmäßig einen bestimmten Sicherheitsdeskriptor (Berechtigungen) bestimmter Gruppen (und ihrer Mitglieder) überprüft und anwendet, den AD berücksichtigtgeschütztDie festgelegten Berechtigungen werden von den Berechtigungen abgeleitet, die auf demAdminSDHolderObjekt in AD.
Im Rahmen dieser Diskussion konzentrieren wir uns aufDomänenadministratoren.
Zitat:
... Wenn die Berechtigungen für eines der geschützten Konten und Gruppen nicht mit den Berechtigungen für das AdminSDHolder-Objekt übereinstimmen, werden die Berechtigungen für die geschützten Konten und Gruppen zurückgesetzt, sodass sie mit denen des AdminSDHolder-Objekts der Domäne übereinstimmen.
Weiter,Kontobetreiberhaben standardmäßig die Berechtigung, alle Benutzer-/Computer-/Gruppenobjekte in der Domäne zu verwalten,mit Ausnahme der geschützten Gruppen/Mitglieder, aufgrund dieses SDProp-Prozesses.
Ein typisches Beispiel: Der Versuch, ein Domänenadministratorkonto mit einem Kontooperator zu ändern, führt zu einemZugriff abgelehntFehler.
Probleme
Erste Ausgabe:
Sie können zwar nichtänderndiese geschützten Konten, wie im obigen Verfahren beschrieben,KontobetreiberDÜRFEN, löschen Sie sie jedoch! Dies sollte nach meinem Verständnis dieses Schutzmechanismus nicht möglich sein.
Beim Anzeigen der Berechtigungen des Domänenadministratorkontos werden Kontooperatoren nirgends aufgeführt. Darüber hinaus zeigt eine effektive Zugriffsprüfung für einen AO, dass er nurBerechtigungen/Eigenschaften lesen. Alle Schreib- und Löschberechtigungen werden verweigert. Das ist zu erwarten.
Es scheint, dass die Möglichkeit, das geschützte Konto zu löschen, von einer ACL in der OU herrührt, die es enthält. Dabei hat die Gruppe der Kontobetreiber dieErstellen und Löschen von Benutzerobjekten(nur dieses Objekt) innerhalb dieser Organisationseinheit.
Ein typisches Beispiel: Wenn ich diesen ACE bearbeite und das Löschrecht entferne, verschwindet das oben genannte Problem und der AO kann den Domänenadministrator nicht mehr löschen.
Zweite Ausgabe
Wie oben erwähnt, scheinen die effektiven Berechtigungen die Tatsache zu verbergen, dass der AO das Objekt löschen kann. Das verstehe ich wirklich nicht.
Fragen, die beantwortet werden müssen
Warum überschreibt die Berechtigung für die Organisationseinheit die Berechtigungen, die adminSDHolder für das geschützte Konto festgelegt hat? Der gesamte Zweck dieses Prozesses besteht darin, zu VERHINDERN, dass bestimmte delegierte Berechtigungen von irgendwoher auf die geschützten Konten angewendet werden, umschützenihnen.
Warum wird auf der Registerkarte „Effektiver Zugriff“ nicht richtig angezeigt, dass ich gemäß den OU-Berechtigungen die Möglichkeit habe, dieses Konto zu löschen?
Antwort1
Die wirksamen Berechtigungen scheinen die Tatsache zu verbergen, dass der AO das Objekt löschen kann. Das verstehe ich wirklich nicht.
ich mochte dasSichere IdentitätDa ich so viel zu diesem Thema poste, dachte ich, ich würde die relevanten Teile davon referenzieren und zitieren, da sie sich speziell auf Ihre Frage beziehen.
Ich glaube, das ist eine gute Frage, die viele Leute gerne wissen würden, wenn ihnen klar wird, ob die Verwendung von Kontooperatoren in ihrer AD-Domänenumgebung Standard ist. Ich habe sicherlich nie versucht, ein AD-Konto eines Domänenadministratormitglieds mit einem Kontooperator zu löschen, habe jedoch in der Vergangenheit Umgebungen unterstützt, in denen Kontooperatoren verwendet wurden und ich Domänenadministrator war.
Wenn wir uns nun die Optionen zum Löschen von Objekten in Active Directory ansehen, haben Sie möglicherweise bemerkt, dass es drei verschiedene Löschtypen gibt:
- Löschen (DELETE-Zugriffsmaske)
- Kind löschen (ADS_RIGHT_DS_DELETE_CHILD Zugriffsmaske)
- Teilbaum löschen (Zugriffsmaske ADS_RIGHT_DS_DELETE_TREE)
Und hier wird es interessant. Beim Ausführen einer Löschaktion überprüft das System den Sicherheitsdeskriptor sowohl für das Objekt als auch für sein übergeordnetes Objekt, bevor es die Löschung zulässt oder verweigert.
Ein ACE, der einem Benutzer explizit den Löschzugriff verweigert, hat keine Auswirkung, wenn der Benutzer auf dem übergeordneten Objekt den Löschzugriff auf untergeordnete Objekte hat. Ebenso kann ein ACE, der auf dem übergeordneten Objekt den Löschzugriff auf untergeordnete Objekte verweigert, überschrieben werden, wenn auf dem Objekt selbst der Löschzugriff zulässig ist.
Quelle: Zugriffskontrolle und Objektlöschung
Beispiele für „Löschen“ und „Untergeordnetes Element löschen“:
Beispiel Eins:
Mein Administratorbenutzer Tony verfügt nicht über den ACE: „Löschen zulassen“-Zugriff auf einen Domänenadministratorbenutzer namens Hank. Tony könnte das Konto trotzdem löschen, wenn er über den ACE: „Löschen von untergeordneten Benutzern zulassen“ für die übergeordnete Organisationseinheit verfügt.
Beispiel Zwei:
Wenn für Hank ein expliziter ACE: Löschzugriff verweigern festgelegt ist, kann Tony das Konto trotzdem löschen, wenn er für die übergeordnete Organisationseinheit über den ACE: Löschen von untergeordnetem Benutzer zulassen verfügt.
Und wenn wir es umkehren: Tony landet in einem ACE: Löschen des untergeordneten Benutzers verweigern in der übergeordneten Organisationseinheit. Er könnte ihn dennoch löschen, wenn er in einem ACE für das Benutzerobjekt explizit Löschen zulassen hat.
Damit können wir sehen, dass dies
AdminSDHolder Security Descriptordie Administratoren oder verschachtelten Gruppen nicht in allen Szenarien wirklich schützt.. Wenn Sie sich die aktuellen Berechtigungen noch einmal ansehen, haben Sie gesehen, dass Tony keine Rechte hatte, den Benutzer zu löschen. Aber er hat den ACE: Löschen von untergeordneten Benutzern zulassen für die übergeordnete Organisationseinheit und kann Hank löschen, der Mitglied der Gruppe „Domänenadministratoren“ ist.Standardrechte
Nachdem wir nun über die Löschzugriffsrechte gesprochen haben, wäre es vielleicht eine gute Idee, darüber nachzudenken, wer im Active Directory standardmäßig über diese Befugnisse verfügt.Neben den offensichtlichen wie Administratoren, Domänenadministratoren, Enterprise-Administratoren haben wir natürlich auch die bekannten Gruppe „Kontenoperatoren“.
Kontooperatoren haben standardmäßig explizite Vollzugriffsrechte auf Benutzer-, Computer-, Gruppen- und InetOrgPerson-Objekte. Sie haben diesen expliziten Zugriff nicht auf den Sicherheitsdeskriptor AdminSDHolder, aber sie haben explizite Rechte zum Erstellen/Löschen von untergeordneten Benutzern, Gruppen, Computern und InetOrgPersons auf Organisationseinheiten.Wenn für die übergeordnete Organisationseinheit der Domänenadministratoren keine explizite Berechtigung zum Löschen untergeordneter Benutzer vorliegt, kann die Organisationseinheit Domänenadministratorbenutzer löschen.
(Dies kann aus dem Attribut „defaultSecurityDescriptor“ der im Schema definierten Objektklasse entfernt werden, wenn Sie der Aufgabe gewachsen sind.)
Ein weiterer Ansatzpunkt ist die gezielte Verschachtelung von Gruppen. Wenn Benutzer über die Verschachtelung von Gruppen eine DA-Mitgliedschaft haben, löschen Sie einfach diese Gruppe, und sie sind keine DA mehr.
Dies sind einige Gründe, warum ich die Admin-OU als Root-OU trennen möchte, um das Risiko einer fehlerhaften Delegierung zu minimieren.
Unterstützende Ressourcen
Antwort2
Ich denke, Ihr Missverständnis beruht auf der Annahme, dass alle Mitglieder der Gruppe „Domänenadministratoren“ ebenfalls geschützt sind. Das ist jedoch nicht der Fall. Daher gilt AdminSDHolder nicht für diese Konten.
Dies wird in der Dokumentation nicht explizit erwähnt, aber auch nicht, dass Mitglieder von Domänenadministratoren als geschützt gelten. Ebenso wenig wird darin erwähnt, dass Kontobetreiber keine Mitglieder der Domänenadministratorgruppe löschen können.
Verweise: