Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
TechNet Magazine > Home > Alle Ausgaben > 2009 > TechNet Magazine September 2009 >  Active Directory: AdminSDHolder, Protected Grou...
Inhalt anzeigen:  Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Active Directory
AdminSDHolder, Protected Groups and SDPROP
John Policelli
 
At a Glance:
  • Overview of AdminSDHolder, protected groups and SDPROP
  • Controlling groups that are protected by AdminSDHolder
  • Security Descriptor propagator

Active Directory Domain Services uses AdminSDHolder, protected groups and Security Descriptor propagator (SD propagator or SDPROP for short) to secure privileged users and groups from unintentional modification. This functionality was introduced in the inaugural release of Active Directory in Windows 2000 Server and it's fairly well known. However, virtually all IT administrators have been negatively impacted by this functionality, and that will to continue unless they fully understand how AdminSDHolder, protected groups and SDPROP work.
Each Active Directory domain has an object called AdminSDHolder, which resides in the System container of the domain. The AdminSDHolder object has a unique Access Control List (ACL), which is used to control the permissions of security principals that are members of built-in privileged Active Directory groups (what I like to call "protected" groups). Every hour, a background process called SDPROP runs on the domain controller that holds the PDC Emulator operations master role. It compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the ACL lists aren't the same, the ACL on the security principal is overwritten with the ACL from the Admin–SDHolder object. In addition, inheritance is disabled on the security principal.
As you can see, multiple layers of security are incorporated into this functionality. First, the permissions applied to users belonging to protected groups are more stringent than the default permissions applied onto other user accounts. Next, this functionality disables inheritance on these privileged accounts, ensuring that permissions applied at the parent level aren't inherited by the protected objects, regardless of where they reside. Finally, the SDPROP process running every 60 minutes identifies manual modifications to an ACL and reverses them so that the ACL matches the ACL on the AdminSDHolder object.
See the sidebar "A Common Example of the Impact of AdminSDHolder, Protected Groups, and SDPROP" for a real-world look at this functionality.

The AdminSDHolder Object
As mentioned, each Active Directory domain contains an AdminSDHolder object that resides in the domain's System partition. The distinguished name of the AdminSDHolder object is "CN=AdminSDHolder,CN=System,DC=domain,DC=com," where DC=domain,DC=com is the distinguished name of the domain. Figure 1 shows the AdminSDHolder object in a Windows Server 2008 R2 domain.
Figure 1 AdminSDHolder Object (Click the image for a larger view)

Default ACL
Because the AdminSDHolder object is used in the process to secure privileged accounts, the default ACL on the AdminSDHolder object is more stringent than the ACL on other objects, such as the domain, OUs and containers.
In the default ACL for AdminSDHolder, the default Owner is the Domain Admins group, which is fairly unusual. Most Active Directory objects have the Administrators group as the default Owner. That's significant because an Owner can take control of an object and reset permissions.
Another important design factor for the AdminSDHolder object is that inheritance is disabled, which ensures that no parent-level permissions are inherited.
Finally, the Administrators, Domain Admins and Enterprise Admins groups are the groups that have the write permission to attributes on AdminSDHolder, which is more stringent than the default permissions applied to other Active Directory objects.

Protected Groups
As previously noted, AdminSDHolder permissions apply to security principals that belong to protected groups. The list of protected groups has expanded since the inaugural release of Active Directory in Windows 2000 Server. Figure 2 shows the default protected groups and users from Windows 2000 Server to Windows Server 2008 R2.
Figure 2 Default Protected Groups
Windows 2000 Server RTM
Windows 2000 Server with SP1
Windows 2000 Server with SP2
Windows 2000 Server with SP3
Windows 2000 Server with SP4
Windows Server 2003 RTM
Windows Server 2003 with SP1
Windows Server 2003 with SP2
Windows Server 2008 RTM
Windows Server 2008 R2
Administrators Account Operators Account Operators Account Operators
Domain Admins Administrator Administrator Administrator
Enterprise Admins Administrators Administrators Administrators
Schema Admins Backup Operators Backup Operators Backup Operators
  Cert Publishers Domain Admins Domain Admins
  Domain Admins Domain Controllers Domain Controllers
  Domain Controllers Enterprise Admins Enterprise Admins
  Enterprise Admins Krbtgt Krbtgt
  Krbtgt Print Operators Print Operators
  Print Operators Replicator Read-only Domain Controllers
  Replicator Schema Admins Replicator
  Schema Admins Server Operators Schema Admins
  Server Operators   Server Operators
A Common Example of the Impact of AdminSDHolder, Protected Groups and SDPROP
Most Active Directory administrators become aware of AdminSDHolder, protected groups and SDPROP through a scenario like this one:
You delegate permissions on an Organizational Unit (OU). You're later informed that the permissions are in place for most—but not all—user accounts in the OU. You determine that the ACL on the affected accounts is different from what you delegated and that inheritance is not enabled, so you enable inheritance to resolve the issue. Initially, this seems to work, but later the issue resurfaces. You again determine that the ACL is different and inheritance has been disabled.
I've seen individuals go through this seeming endless cycle over and over.
This situation actually occurs by design, however. It's caused by AdminSDHolder, protected groups and SDPROP.
The accounts affected by this issue belong to a protected group. As a result, the ACL on these accounts is inherited from the AdminSDHolder object in the domain, and inheritance is disabled. That's why the permissions that you delegated aren't applied to the affected user accounts. When you manually enable inheritance on these accounts, the delegated permissions are added to the ACL.
However, when the SDPROP process runs on the domain controller that holds the PDC Emulator operations master role—by default, every 60 minutes—the ACL is overwritten to match the ACL on the AdminSDHolder object and inheritance is disabled.
The list of protected groups consisted of four security groups in Windows 2000 Server RTM. In Windows 2000 Server SP4 and Windows Server 2003, several other groups were added, including the Administrator and Krbtgt accounts. In Windows Server 2003 with SP1 and later versions, Microsoft removed the Cert Publishers group from the default protected groups. In Windows Server 2008, Microsoft expanded this list to include the Read-Only Domain Controllers group. The list of protected groups hasn't changed in the Release Candidate build of Windows Server 2008 R2.

Controlling Groups that are Protected by AdminSDHolder
In my experience, a subset of these default protected groups causes problems with AdminSDHolder. For example, many organizations use the Print Operators group for Print Services management but not for Active Directory management. However, the Print Operators group is a protected group because it has elevated permissions on domain controllers by default. A best practice is to remove the elevated permissions that this group has on domain controllers. If you do follow this best practice (and you should!), you probably won't need to protect this group with AdminSDHolder.
You can exclude a subset of the default protect groups from the AdminSDHolder process, including:
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
This ability to control groups that are protected by AdminSDHolder was introduced via hotfix for the RTM versions of Windows 2000 Server and Windows Server 2003 and is included in the most recent service pack for Windows Server 2003 and in the RTM versions of Windows Server 2008 and Windows Server 2008 R2. For more information on the hotfix, go to Delegated permissions are not available and inheritance is automatically disabled.
The ability to control groups protected by AdminSDHolder is enabled by modifying the dsHeuristic flag. This is a Unicode string in which each character contains a value for a single domain-wide setting. Character position 16 is interpreted as a hexadecimal value, where the left-most character is position 1. Therefore, the only valid values are "0" through "f". Each operator group has a specific bit, as shown in Figure 3.
Figure 3 dsHeuristic Operator Bits
Bit Group to Exclude Binary Value Hexadecimal Value
0 Account Operators 0001 1
1 Server Operators 0010 2
2 Print Operators 0100 4
3 Backup Operators 1000 8
This situation becomes even more complicated when you're trying to exclude more than one group from AdminSDHolder, especially because you can have multiple combinations of exclusions—for example, Account Operators and Server Operators, or Account Operators and Backup Operators. To deal with this issue, simply add the binary value of each group and then convert the result to a hexadecimal value. For example, to exclude the Print Operators and Backup Operators groups, take the binary value for the Print Operators group (0100) and add it to the binary value of the Backup Operators group (1000), which equals 1100. You then convert the binary sum (1100) to the hexadecimal value (C).
To make this task a little easier, Figure 4 lists all possible combinations in binary and hexadecimal format.
Figure 4 dsHeuristic Values for Excluding Combinations of Groups
Group(s) to Exclude Binary Value Hexadecimal Value
None (Default) 0 0
Account Operators 1 1
Server Operators 10 2
Account Operators
Server Operators
0001 + 0010 = 0011 3
Print Operators 100 4
Account Operators
Print Operators
0001 + 0100 = 0101 5
Server Operators
Print Operators
0010 + 0100 = 0110 6
Account Operators
Server Operators
Print Operators
0001 + 0010 + 0100 = 0111 7
Backup Operators 1000 8
Account Operators
Backup Operators
0001 + 1000 = 1001 9
Server Operators
Backup Operators
0010 + 1000 = 1010 A
Account Operators Server Operators
Backup Operators
0001 + 0010 + 1000 = 1011 B
Print Operators
Backup Operators
0100 + 1000 = 1100 C
Account Operators
Print Operators
Backup Operators
0001 + 0100 + 1000 = 1101 D
Server Operators
Print Operators
Backup Operators
0010 + 0100 + 1000 = 1110 E
Account Operators
Server Operators
Print Operators Backup Operators
0001 + 0010 + 0100 + 1000 = 1111 F
After deciding which group(s) you want to exclude, you're ready to modify the dsHeuristics attribute. For details on that process, see the sidebar "How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder."

Determining Whether a Security Principal Is Protected by AdminSDHolder
A fairly large number of default users and groups are protected by AdminSDHolder. One thing to keep in mind is that users are protected by AdminSDHolder if they have direct or transitive membership in a security or distribution group. Distribution groups are included because a distribution group can be converted to a security group.
Let's say a user belongs to a distribution list called Canada IT. The Canada IT DL is a member of the North American IT security group; the North American IT security group is a member of the Administrators group. Because the user's transitive group membership includes the Administrators group (by virtue of group nesting), the user's account is protected by AdminSDHolder.
There's an easy way to determine which users and groups AdminSDHolder protects in your domain. You can query the adminCount attribute to determine whether an object is protected by the AdminSDHolder object. The following examples use the ADFind.exe tool, which can be downloaded from joeware. net.
  • To find all objects in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN
  • To find all user objects in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "(&(objectcategory=person)(objectclass=user)(admincount=1))" DN
  • To find all groups in a domain that are protected by AdminSDHolder, type:
Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN
Note: In the preceding examples, replace DC=domain,DC=com with the distinguished name of your domain.

Orphaned AdminSDHolder Objects
When a user is removed from a protected group, the adminCount attribute on that user account is changed to 0. However, inheritance isn't re-enabled on the user account. As a result, the user account no longer receives its ACL from the AdminSDHolder object, but it also doesn't inherit any permissions from parent objects. The common term for this issue is "orphaned AdminSDHolder objects." There is no automated mechanism to fix inheritance on objects that no longer belong to protected groups; you must deal with orphaned AdminSDHolder objects manually. Microsoft has developed and made available a VB Script that will assist you in re-enabling inheritance on user accounts that were previously members of protected groups. To find the VB Script, go to Delegated permissions are not available and inheritance is automatically disabled.

Security Descriptor Propagator
SDPROP is a background process that runs on the domain controller that holds the PDC Emulator operations master role. By default, SDPROP runs every 60 minutes. SDPROP is designed to compare the ACL on users and groups that are members of protected groups. If the ACL is the same, SDPROP doesn't touch the ACL. However, if the ACL is different, it's overwritten with the ACL from the AdminSDHolder object.

Modifying How Often SDPROP Runs
If the default frequency of 60 minutes for SDPROP to run isn't sufficient, you can change it by creating or modifying the AdminSDProtectFrequency entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey.
If this key doesn't exist, the default frequency (60 minutes) is used.
You can configure the frequency to anywhere between one minute and two hours. You must enter the number of seconds when creating or modifying the registry entry. The following command will configure SDPROP to run every 10 minutes (600 seconds):
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
Note, however, that modifying this subkey isn't recommended because doing so can increase LSA (Local Security Authority) processing overhead.

Forcing SDPROP to Run
You can also force SDPROP to run in cases where you're testing changes or you can't wait for the configured interval. Forcing SDPROP to run involves manually initializing the SDPROP thread to evaluate inherited permissions for objects in Active Directory. This process can be achieved by taking the following steps on the domain controller that holds the PDC Emulator operations master role:
  1. Go to Start. Click Run. Type LDP.exe. Click OK.
  2. On the Connection menu in the LDP console, click Connect.
  3. In the Connect dialog box, type the server name you want to connect to in the Server field and ensure that 389 is listed in the Port field. Click OK.
  4. On the Connection menu, click Bind.
  5. In the Bind window, select the Bind as the currently logged-on user option, or select the Bind with Credentials option. If you selected the latter, enter the credentials that you want to bind with. Click OK.
  6. On the Browse menu, select Modify.
  7. In the Modify dialog box, leave the DN field empty. Type FixUpInheritance into the Attribute field. Type Yes into the Value field. Select the Add operation, then click Enter. Figure 5 shows how the Modify window should look.
  8. In the Modify dialog box, click Run. The Details pane will be similar to the highlighted text in Figure 6.
Figure 5 The Modify Window. When Forcing SDPROP to run in the Modify dialog box, click Run. The Details pane will be similar to the highlighted text in Figure 6. (Click the image for a larger view)
Figure 6 Call Modify Operation in LDP.exe. (Click the image for a larger view)
At this point, SDPROP should initialize. The amount of time the SDPROP process takes depends on the size of your Active Directory environment. The larger the environment, the longer it will take the process to run. You can monitor the DS Security Propagation Events counter in the NTDS Performance object to determine when SDPROP has completed, which will be indicated by a counter value of 0.

Wrapping Up
The AdminSDHolder is an important security feature in Active Directory. The AdminSDHolder, protected groups and Security Descriptor propagator help secure user accounts that contain elevated Active Directory permissions. The AdminSDHolder functionality has evolved from Windows 2000 Server to Windows Server 2008. During this evolution, Microsoft has expanded the number of objects that are secured by AdminSDHolder, introduced the ability to exclude certain groups from the Admin–SDHolder and added the ability to control how often SDPROP runs.
Most Active Directory administrators have been introduced to AdminSDHolder, intentionally or unintentionally. I've tried to provide you with a good understanding of what AdminSDHolder is, how it works and what cleanup is required when you remove a user from a protected group, along with some useful tweaks. I hope that this information will help prevent you from being caught off guard by the AdminSDHolder functionality the next time you delegate or remove Active Directory permissions.
How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder
The dsHeuristics attribute can be used to exclude certain groups from being protected by AdminSDHolder. The following instructions outline the steps for modifying the dsHeuristics attribute on Windows Server 2008 R2:
  1. Log on to a domain controller or a member computer that has the Remote Server Administrator Tools (RSAT) installed.
  2. Go to Start. Click Run. Type adsiedit.msc, then click OK.
  3. In the ADSI Edit console, right-click on ADSI Edit in the console tree. Select Connect To.
  4. In the Connection Settings window, select Configuration from the Select a Well-Known Naming Context drop-down. Click OK.
  5. In the console tree, expand Configuration, expand Service, and expand Windows NT. Right-click on the Directory Service node, then select Properties.
  6. In the CN=Directory Service Properties window, select dsHeuristics. Click Edit.
  7. In the String Attribute Editor window, copy the existing value for dsHeuristics if it is set.
  8. In the String Attribute Editor window, replace the dsHeuristics value with what you want to set, such as 000000000100000f to exclude Account Operators, Server Operators, Print Operators, and Backup Operators groups. Figure A shows the String Attribute Editor window.

    Note: Replace the zeros in the first part of the value with what you may already have in dsHeuristics. Make sure that you have the correct count of digits up to the "f" or whatever bits you want to set.
  9. Click OK on the String Attribute Editor window. Click OK on the CN=Directory Service Properties window.
Figure A String Attribute Editor Window(Click the image for a larger view)

John Policelli, Microsoft MVP for Directory Services, MCTS, MCSA, ITSM, iNet+, Network+ and A+, is a solutions-focused IT consultant with more than a decade of combined success in architecture, security, strategic planning and disaster-recovery planning. For the past nine years, he has focused on identity and access management and providing thought leadership for some of Canada's largest installations of Active Directory. Policelli is the author of Active Directory Domain Services 2008 How-To (Sams Publishing, 2009).

Active Directory
AdminSDHolder, Protected Groups und SDPROP
John Policelli
 
Kurz zusammengefasst:
  • Übersicht über AdminSDHolder, geschützten Gruppen und SDPROP
  • Steuern der Gruppen, die durch AdminSDHolder geschützt sind
  • Sicherheitsbeschreibungspropagierer

Active Directory-Domänendienste verwendet AdminSDHolder, geschützten Gruppen und Sicherheitsbeschreibung Propagator (SD Propagator oder SDPROP für Short) für sichere privilegierte Benutzer und Gruppen von unbeabsichtigte Änderung. Diese Funktionalität wurde in der ersten Version von Active Directory in Windows 2000 Server eingeführt, und es ziemlich gut bekannt ist. Allerdings praktisch alle IT-Administratoren haben wurde beeinträchtigt durch diese Funktionalität und, um fortzufahren, wenn Sie vollständig verstehen wie AdminSDHolder, geschützten Gruppen und SDPROP funktionieren wird.
Jede Active Directory-Domäne hat ein Objekt namens AdminSDHolder, die sich im Systemcontainer der Domäne befindet. Das AdminSDHolder-Objekt besitzt eine eindeutige Zugriffssteuerungsliste (ACL), dem Berechtigungen der Sicherheitsprinzipale steuern, die sind Mitglieder der integrierten privilegierten Active Directory-Gruppen (was ich gerne "geschützt protected" aufrufenGruppen). Jede Stunde wird auf die Domänencontroller, der die PDC-Emulator-Betriebsmasterfunktion innehat, Hintergrundprozess SDPROP aufgerufen ausgeführt. Es vergleicht die ACL auf alle Sicherheitsprinzipale (Benutzer, Gruppen und Computerkonten), die zu geschützten Gruppen mit der ZUGRIFFSSTEUERUNGSLISTE für das AdminSDHolder-Objekt gehören. Wenn die ACL-Listen identisch sind, wird die ACL für den Sicherheitsprinzipal mit der ACL aus dem Admin–SDHolder-Objekt überschrieben. Darüber hinaus ist die Vererbung auf das Sicherheitsprinzipal deaktiviert.
Wie Sie sehen können, werden mehrere Sicherheitsebenen in diese Funktionalität integriert. Zunächst sind die Berechtigungen auf Benutzer, die zu geschützten Gruppen gehören angewendet strengere als den Standard-Berechtigungen auf andere Benutzerkonten angewendet. Diese Funktionalität deaktiviert anschließend Vererbung auf privilegierten Konten, sicherstellen, dass Berechtigungen auf der übergeordneten Ebene angewendeten werden nicht durch geschützte Objekte vererbt, unabhängig davon, wo Sie sich befinden. Schließlich wird der SDPROP Prozess alle 60 Minuten manuelle Änderungen an einer ACL kennzeichnet und kehrt diese, so dass die ACL die ACL des Objekts AdminSDHolder übereinstimmt.
Siehe die Randleiste "Eine allgemeine Beispiel der Auswirkungen von AdminSDHolder, geschützten Gruppen und SDPROP"eine reale Betrachtung dieser Funktionalität.

AdminSDHolder Object
Wie bereits erwähnt, enthält jede Active Directory-Domäne ein AdminSDHolder-Objekt, die sich in der Domäne Systempartition befindet. Der definierte Name des AdminSDHolder-Objekts ist "CN = AdminSDHolder, CN = System, DC = Domain, DC = com"DC = Domain, DC = com ist der DN der Domäne. Abbildung 1 zeigt das Objekt AdminSDHolder in einer Domäne Windows Server 2008 R2.
Abbildung 1 AdminSDHolder Object (auf das Bild für eine größere Ansicht klicken.)

Standard-ACL
Da das AdminSDHolder-Objekt so sichern Sie privilegierte Konten im Prozess verwendet wird, ist die Standardeinstellung ACL auf das Objekt AdminSDHolder strengere als die ACL für andere Objekte, wie die Domäne, Organisationseinheiten und Container.
In der ZUGRIFFSSTEUERUNGSLISTE für AdminSDHolder standardmäßig ist die Standardeinstellung Besitzer Gruppe der Domänenadministratoren, ziemlich ungewöhnlich ist. Die meisten Active Directory-Objekte haben der Gruppe "Administratoren" als den Standardwert Besitzer. Nämlich erhebliche ein Besitzer Kontrolle über ein Objekt und Berechtigungen zurücksetzen kann.
Ein weiterer wichtiger Entwurf Faktor für das Objekt AdminSDHolder ist, dass Vererbung deaktiviert ist, wird sichergestellt, dass keine parent-level Berechtigungen geerbt werden.
Schließlich sind die Gruppen Administratoren, Domänenadministratoren und Organisationsadministratoren die Gruppen, die haben die Schreibberechtigung zu Attributen auf AdminSDHolder, strengere als den Standard-Berechtigungen auf andere Objekte Active Directory angewendet ist.

Geschützten Gruppen
Wie bereits erwähnt, Sicherheitsprinzipale AdminSDHolder Berechtigungen zuweisen, die zu geschützten Gruppen gehören. Die Liste der geschützten Gruppen wurde seit der ersten Veröffentlichung von Active Directory in Windows 2000 Server erweitert. Abbildung 2 zeigt die Standardeinstellung Gruppen und Benutzer vor Windows 2000 Server auf Windows Server 2008 R2 geschützt.
Abbildung 2 Standard geschützten Gruppen
Windows 2000 Server RTM
Windows 2000 Server mit SP1
Windows 2000 Server mit SP2
Windows 2000 Server mit SP3
Windows 2000 Server mit SP4
Windows Server 2003 RTM
Windows Server 2003 mit SP1
Windows Server 2003 mit SP2
Windows Server 2008 RTM
Windows Server 2008 R2
VSS-Administratoren Kontenoperatoren Kontenoperatoren Kontenoperatoren
Domänen-Admins Administrator Administrator Administrator
Organisations-Admins VSS-Administratoren VSS-Administratoren VSS-Administratoren
Schema-Admins Sicherungsoperatoren Sicherungsoperatoren Sicherungsoperatoren
  Zertifikatherausgeber Domänen-Admins Domänen-Admins
  Domänen-Admins Domänencontroller Domänencontroller
  Domänencontroller Organisations-Admins Organisations-Admins
  Organisations-Admins KRBTGT KRBTGT
  KRBTGT Druckoperatoren Druckoperatoren
  Druckoperatoren Replikations-Operator Nur-Lese-Domänencontroller
  Replikations-Operator Schema-Admins Replikations-Operator
  Schema-Admins Serveroperatoren Schema-Admins
  Serveroperatoren   Serveroperatoren
Eine allgemeine Beispiel der Auswirkungen von AdminSDHolder, Protected, Gruppen und SDPROP
Die meisten Active Directory Administratoren mehr bewusst AdminSDHolder, Gruppen und SDPROP über ein Szenario wie diesem geschützt:
Delegieren Sie Berechtigungen auf ein Organizational Unit (OU). Sie können später informiert, dass die Berechtigungen für die meisten sind – aber nicht alle – Benutzerkonten in der ORGANISATIONSEINHEIT. Sie ermitteln, dass die ACL für den betreffenden Konten unterscheidet was Sie delegiert und die Vererbung nicht aktiviert ist, sodass Aktivieren von Vererbung, um dieses Problem zu beheben. Zunächst diese arbeiten scheint, aber das Problem später resurfaces. Sie ermitteln erneut, dass die ACL unterscheidet und Vererbung deaktiviert wurde.
Ich habe Einzelpersonen immer wieder durchlaufen dieser seeming endlosen Zyklus gesehen.
Diese Situation tritt tatsächlich standardmäßig jedoch. Es ist von AdminSDHolder, geschützten Gruppen und SDPROP verursacht.
Die von diesem Problem betroffenen Konten gehören zu einer geschützten Gruppe. Als Ergebnis der ZUGRIFFSSTEUERUNGSLISTE für diese Konten wird aus dem AdminSDHolder-Objekt in der Domäne geerbt, und Vererbung wird deaktiviert. Deswegen Berechtigungen, die Sie delegiert werden auf die betroffene Benutzerkonten nicht angewendet. Wenn Sie manuell die Vererbung für diese Konten aktivieren, werden die ACL delegierten Berechtigungen hinzugefügt.
Jedoch, wenn der SDPROP Prozess ausgeführt wird auf dem Domänencontroller, der PDC-Emulator-Betriebsmasterfunktion innehat, wird standardmäßig alle 60 Minuten – die ACL wird entsprechend die ACL des Objekts AdminSDHolder überschrieben und Vererbung deaktiviert ist.
Die Liste der geschützten Gruppen Bestand aus vier Sicherheitsgruppen in Windows 2000 Server RTM. In Windows 2000 Server SP4 und Windows Server 2003 wurden mehrere Gruppen hinzugefügt, einschließlich die Konten Administrator und Krbtgt. In Windows Server 2003 mit SP1 und höher entfernt Microsoft Gruppe Zertifikatherausgeber aus den Gruppen standardmäßig geschützt. In Windows Server 2008 erweitert Microsoft diese Liste für die Gruppe Read-Only-Domänencontroller enthalten. Die Liste der geschützten Gruppen noch nicht in den Release Candidate-Build von Windows Server 2008 R2 geändert.

Steuern der Gruppen, die von AdminSDHolder geschützt
Meiner Erfahrung eine Teilmenge dieser Standard Gruppen Ursachen Probleme mit AdminSDHolder geschützt. Beispielsweise verwenden viele Organisationen die Gruppe Druck-Operatoren für Druckdienste Verwaltung jedoch nicht für Active Directory-Verwaltung. Die Gruppe Druck-Operatoren ist jedoch einer geschützten Gruppe, da Berechtigungen auf Domänencontrollern standardmäßig erhöht wurde. Es wird empfohlen erhöhten Berechtigungen entfernen, die dieser Gruppe auf einem Domänencontroller verfügt. Wenn Sie diese optimale Methode führen (und Sie sollten!), müssen Sie nicht wahrscheinlich dieser Gruppe mit AdminSDHolder geschützt.
Sie können eine Teilmenge der Standardwert ausschließen Schützen von Gruppen vor den AdminSDHolder-Prozess, einschließlich:
  • Kontenoperatoren
  • Serveroperatoren
  • Druckoperatoren
  • Sicherungsoperatoren
Diese Möglichkeit zum Steuerelement Gruppen, die durch AdminSDHolder geschützt sind wurde über Hotfix für die RTM-Versionen von Windows 2000 Server und Windows Server 2003 eingeführt und ist im neuesten Servicepack für Windows Server 2003 und in der RTM-Version von Windows Server 2008 und Windows Server 2008 R2 enthalten. Für Weitere Informationen zu den Hotfix wechseln zu delegierten Berechtigungen sind nicht verfügbar und Vererbung ist automatisch deaktiviert.
Die Fähigkeit zum Steuerelement Gruppen von AdminSDHolder geschützt wird durch Ändern der DsHeuristic-Flag aktiviert. Ist dies eine Unicodezeichenfolge in der jedes Zeichen für eine einzelne domänenweite Einstellung einen Wert enthält. Zeichenposition 16 wird als hexadezimalen Wert interpretiert, wobei das am weitesten links befindlichen Zeichen Position 1 ist. Daher sind die einzigen gültigen Werte "0"über "f". Jeder Operator-Gruppe hat etwas bestimmtes, wie in Abbildung 3 dargestellt.
Abbildung 3 DsHeuristic Operator Bits
Bit Gruppe löschen Binärwert Hexadezimaler Wert
0 Kontenoperatoren 0001 1
1 Serveroperatoren 0010 2
2 Druckoperatoren 0100 4
3 Sicherungsoperatoren 1000 8
Diese Situation wird noch komplizierter, wenn Sie mehr als einer Gruppe ausgeschlossen werden AdminSDHolder, insbesondere, da Sie mehrere Kombinationen von Ausschlüssen aufweisen können, z. B. Kontenoperatoren und Serveroperatoren, oder Konten-Operatoren und Sicherungs-Operatoren. Um dieses Problem zu beheben, fügen Sie einfach den binären Wert jeder Gruppe, und konvertieren Sie das Ergebnis anschließend in einen hexadezimalen Wert zu. Beispielsweise gruppieren ausgeschlossen werden, die Druckoperatoren und Sicherungsoperatoren Gruppen, nehmen der binäre Wert für den Druck-Operatoren (0100) gruppieren und zu den Binärwert des Sicherungs-Operatoren hinzufügen (1000) entspricht dem 1100. Die binäre Summe (1100) konvertieren Sie dann in den Hexadezimalwert (C).
Um diese Aufgabe etwas vereinfachen, werden in Abbildung 4 alle mögliche Kombinationen im binären und hexadezimalen Format aufgeführt.
Abbildung 4 DsHeuristic Werte für Kombinationen von Gruppen ausschließen
Gruppe(n) zu löschen Binärwert Hexadezimaler Wert
Keine (Standard) 0 0
Kontenoperatoren 1 1
Serveroperatoren 10 2
Kontenoperatoren
Serveroperatoren
0001 + 0010 = 0011 3
Druckoperatoren 100 4
Kontenoperatoren
Druckoperatoren
0001 + 0100 = 0101 5
Serveroperatoren
Druckoperatoren
0010 + 0100 = 0110 6
Kontenoperatoren
Serveroperatoren
Druckoperatoren
0001 + 0010 + 0100 = 0111 7
Sicherungsoperatoren 1000 8
Kontenoperatoren
Sicherungsoperatoren
0001 + 1000 = 1001 9
Serveroperatoren
Sicherungsoperatoren
0010 + 1000 = 1010 a
Konto-Operatoren Serveroperatoren
Sicherungsoperatoren
0001 + 0010 + 1000 = 1011 B
Druckoperatoren
Sicherungsoperatoren
0100 + 1000 = 1100 C
Kontenoperatoren
Druckoperatoren
Sicherungsoperatoren
0001 + 0100 + 1000 = 1101 D
Serveroperatoren
Druckoperatoren
Sicherungsoperatoren
0010 + 0100 + 1000 = 1110 E
Kontenoperatoren
Serveroperatoren
Drucken von Operatoren Sicherungs-Operatoren
0001 + 0010 + 0100 + 1000 = 1111 F
Nach der Entscheidung, welche Gruppe(n), die Sie ausschließen möchten, können Sie das Ändern des Attributs DsHeuristics. Informationen zu diesem Prozess finden Sie unter der Randleiste "How mit DsHeuristics Attribut zum Löschen von Gruppen von AdminSDHolder."

Bestimmen, ob einem Sicherheitsprinzipal von AdminSDHolder geschützt ist
Eine relativ große Anzahl von Standardbenutzer und Gruppen werden durch AdminSDHolder geschützt. Was Denken Sie daran ist, dass Benutzer durch AdminSDHolder geschützt werden, wenn Sie direkte oder transitive in eine Sicherheits- oder Verteilergruppe Gruppe verfügen. Verteilergruppen sind enthalten, da eine Verteilergruppe in eine Sicherheitsgruppe konvertiert werden kann.
Angenommen, ein Benutzer an eine Verteilerliste namens Kanada IT angehört. Der Kanada IT-VERTEILERLISTE ist ein Mitglied der nordamerikanischen IT-Sicherheitsgruppe;Die nordamerikanische IT-Sicherheitsgruppe ist Mitglied der Gruppe "Administratoren". Da des Benutzers transitiv Gruppenmitgliedschaft enthält der Gruppe Administratoren (durch Verwendung der Gruppenverschachtelung), das Konto des Benutzers durch AdminSDHolder geschützt ist.
Es gibt eine einfache Möglichkeit, um festzustellen, welche Benutzer und Gruppen in Ihrer Domäne AdminSDHolder geschützt. Sie können Abfragen das Attribut AdminCount, um festzustellen, ob ein Objekt durch das AdminSDHolder-Objekt geschützt ist. Die folgenden Beispiele verwenden das ADFind.exe-Tool, das von Joeware gedownloadet werden kann. NET.
  • Suchen alle Objekte in einer Domäne, die durch AdminSDHolder geschützt sind, geben Sie:
Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN
  • Suchen alle Benutzerobjekte in einer Domäne, die durch AdminSDHolder geschützt sind, geben Sie:
Adfind.exe -b DC=domain,DC=com -f "(&(objectcategory=person)(objectclass=user)(admincount=1))" DN
  • Suchen alle Gruppen in einer Domäne, die durch AdminSDHolder geschützt sind, geben Sie:
Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN
Hinweis: Ersetzen Sie in den vorherigen Beispielen, DC = Domain, DC = com mit dem definierten Namen Ihrer Domäne.

Verwaiste AdminSDHolder-Objekte
Wenn ein Benutzer aus einer geschützten Gruppe entfernt wird, wird das AdminCount-Attribut für das Benutzerkonto auf 0 geändert. Vererbung ist jedoch nicht für das Benutzerkonto wieder aktiviert. Als Ergebnis das Benutzerkonto nicht mehr die ACL von AdminSDHolder-Objekts empfängt, aber es nicht auch alle Berechtigungen von übergeordneten Objekten erbt. Der allgemeine Begriff für dieses Problem ist 'verwaiste AdminSDHolder Objekten'. Es gibt keinen automatisierten Mechanismus Vererbung auf Objekte zu beheben, die nicht mehr zu geschützten Gruppen gehörenSie müssen manuell mit verwaisten AdminSDHolder-Objekte behandelt. Microsoft entwickelt und ein VBScript, die Sie bei der Vererbung für Benutzerkonten aktivieren unterstützen wird, die zuvor Mitglieder geschützter Gruppen wurden zur Verfügung gestellt. Um den VBScript zu suchen, wechseln Sie zu delegierten Berechtigungen sind nicht verfügbar und Vererbung ist automatisch deaktiviert.

Security Descriptor Übermittlung
SDPROP ist ein Hintergrundprozess, der auf dem Domänencontroller ausgeführt wird, die PDC-Emulator-Betriebsmasterfunktion innehat. SDPROP führt standardmäßig alle 60 Minuten. SDPROP dient zum Vergleich der ACL auf Benutzer und Gruppen, die Mitglieder geschützter Gruppen sind. Wenn die ACL identisch ist, berühren nicht SDPROP die ACL. Jedoch ist die ACL unterscheidet, ist Sie mit der ACL des Objekts AdminSDHolder überschrieben.

Ändern von SDPROP so oft ausgeführt
Wenn die Häufigkeit Standardwert 60 Minuten für SDPROP Ausführen nicht ausreichend ist, können Sie es durch das Erstellen oder Ändern der AdminSDProtectFrequency Eintrags im Unterschlüssel HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters ändern.
Wenn dieser Schlüssel existiert, wird die Standard-Häufigkeit (60 Minuten) verwendet.
Sie können die Häufigkeit an eine Stelle zwischen 1 Minute und zwei Stunden konfigurieren. Sie müssen die Anzahl der Sekunden eingeben, beim Erstellen oder ändern den Registrierungseintrag. Der folgende Befehl wird SDPROP Ausführung alle 10 Minuten (600 Sekunden) konfigurieren:
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
Beachten Sie jedoch, dass die Ändern dieser Teilschlüssel empfohlen wird nicht, da dies so LSA (Local Security Authority) Verarbeitungsaufwand erhöhen kann.

Erzwungene SDPROP ausführen
Sie können auch erzwingen SDPROP in Fällen, in dem Sie gerade Testen von Änderungen oder kann nicht für das konfigurierte Intervall warten, ausgeführt werden soll. Erzwingen SDPROP auszuführenden umfasst manuell Initialisieren des SDPROP Threads geerbte Berechtigungen für Objekte in Active Directory ergeben. Dieser Prozess kann durch die folgenden Schritte auf dem Domänencontroller, der PDC-Emulator-Betriebsmasterfunktion innehat erreicht werden:
  1. Wechseln Sie zu starten. Klicken Sie auf Ausführen. Geben Sie Ldp.exe ein. Klicken Sie auf OK.
  2. Klicken Sie auf im Menü Verbindung in der LDP-Konsole wird.
  3. Geben Sie in das Dialogfeld verbinden die Servernamen, die Sie möchten, im Feld Verbindung und vergewissern Sie sich, dass im Feld Port 389 aufgeführt ist. Klicken Sie auf OK.
  4. Klicken Sie im Menü Connection (Verbindung) auf Bind (Binden).
  5. Wählen Sie im Fenster binden die Bindung als die Option aktuell angemeldeten Benutzer, oder wählen Sie binden mit Anmeldeinformationen Option. Wenn Sie die zweite ausgewählt haben, geben Sie die Anmeldeinformationen, denen Sie mit binden möchten. Klicken Sie auf OK.
  6. Wählen Sie im suchen die Option ändern.
  7. Klicken Sie im Dialogfeld ändern lassen Sie das DN-Feld leer. Geben Sie FixUpInheritance in das Attribut-Feld. Geben Sie Ja in das Feld Wert ein. Markieren Sie den Vorgang hinzufügen und Sie die EINGABETASTE. Abbildung 5 zeigt, wie das Fenster ändern aussehen sollte.
  8. Klicken Sie in das Dialogfeld ändern auf Ausführen. Im Detailbereich werden den markierten Text im Abbildung 6 ähnelt.
Abbildung 5 der Fenster ändern. Wenn erzwingen SDPROP zum Ausführen in das Dialogfeld ändern, klicken Sie auf Ausführen. Im Detailbereich werden ähnelt dem hervorgehobenen Text in Abbildung 6. (Zum Vergrößern auf das Bild klicken)
Abbildung 6 aufrufen ändern wird Ldp.exe. (Zum Vergrößern auf das Bild klicken)
Zu diesem Zeitpunkt sollte SDPROP initialisieren. Der Zeitraum der SDPROP dauert hängt von der Größe der Active Directory-Umgebung. Je größer der Umgebung, die länger der Prozess ausführen dauert. Sie können überwachen DS Verteilung Sicherheitsereignisse Datenquelle unter NTDS-Leistungsobjekt zu bestimmen, wenn SDPROP abgeschlossen hat, die durch eine Leistungsindikator-Wert 0 angezeigt wird.

Zusammenfassung
AdminSDHolder ist eine wichtige Sicherheitsfunktion in Active Directory. Das AdminSDHolder geschützt, Gruppen und Sicherheitsbeschreibung Propagator Hilfe sichere Benutzerkonten, die erhöhte Active Directory Berechtigungen enthalten. AdminSDHolder-Funktionalität hat sich von Windows 2000 Server auf Windows Server 2008 entwickelt. Während dieser Entwicklung hat Microsoft die Anzahl der Objekte erweitert, die durch AdminSDHolder geschützt sind, die Möglichkeit, bestimmte Gruppen aus der Admin–SDHolder auszuschließen eingeführt und steuern, wie oft SDPROP ausgeführt wird hinzugefügt.
Die meisten Active Directory-Administratoren wurden auf AdminSDHolder, absichtlich oder unbeabsichtigt eingeführt. Ich haben versucht, bieten Sie gute Kenntnisse der was AdminSDHolder ist, wie es funktioniert und welche Cleanup erforderlich ist, wenn Sie einen Benutzer aus einer geschützten Gruppe zusammen mit einige nützlichen Anpassungen entfernen. Ich hoffe, dass diese Informationen verhindert helfen wird, wird abgefangen deaktivieren Schützen von AdminSDHolder-Funktionalität das nächste Mal zuweisen oder Entfernen von Active Directory Berechtigungen.
Verwendung von DsHeuristics Attribut zum Ausschließen von Gruppen von AdminSDHolder
Das DsHeuristics-Attribut kann verwendet werden, ausgeschlossen werden, bestimmte Gruppen von AdminSDHolder geschützt. Die folgenden Anweisungen beschreiben die Schritte zum Ändern des Attributs DsHeuristics für Windows Server 2008 R2:
  1. Melden Sie sich auf einem Domänencontroller oder einem Member-Computer, der Remote Server Administrator Tools (RSAT) installiert ist.
  2. Wechseln Sie zu starten. Klicken Sie auf Ausführen. Geben Sie adsiedit.msc, und klicken Sie dann auf OK.
  3. Mit der Maustaste in der Konsolenstruktur auf ADSI Edit, in der ADSIEDIT-Konsole. Wählen Sie Verbindung zu.
  4. Wählen Sie im Fenster Verbindungseinstellungen Konfiguration aus wählen Sie eine Dropdownliste bekannten Namenskontext. Klicken Sie auf OK.
  5. In der Konsolenstruktur erweitern Sie Konfiguration, erweitern Sie Dienst, und erweitern Sie Windows NT. Mit der rechten Maustaste auf den Knoten Active Directory, und wählen Sie Eigenschaften.
  6. Im = CN Directory Service Eigenschaftenfenster auswählen DsHeuristics. Klicken Sie auf Bearbeiten.
  7. Kopieren Sie im Fenster String Attribut-Editor den vorhandenen Wert DsHeuristics, wenn Sie festgelegt ist.
  8. Ersetzen Sie im Fenster String Attribute Editor DsHeuristics Wert Sie festlegen, wie z. B. 000000000100000f Gruppen Kontenoperatoren, Serveroperatoren, Druckoperatoren und Sicherungsoperatoren ausschließen möchten. Abbildung A zeigt das String Attribute Editor-Fenster.

    Hinweis: Ersetzen Sie die Nullen im ersten Teil des Werts mit bereits in DsHeuristics kann. Sicherstellen Sie, dass die richtige Anzahl von Ziffern bis zu "f" habenoder beliebige Bits, die Sie festlegen möchten.
  9. Klicken Sie in das Fenster String Attribut-Editor auf OK. Klicken Sie auf OK im CN = Directory Service Eigenschaftenfenster.
Abbildung A String Attribute Editor-Fenster(Click the image for a larger view)

John Policelli, Microsoft MVP für Verzeichnisdienste, MCTS, MCSA, ITSM, iNet +, Network + und A + ist ein Lösungen konzentriert sich IT-Berater mit mehr als einem Jahrzehnt kombinierten Erfolg in Architektur, Sicherheit, strategische Planung und Planung der Notfallwiederherstellung. Für die letzten neun Jahre er auf Identitäts- und Zugriffsverwaltung konzentriert hat, und Führung bereitstellen für einige der größten Installationen von Active Directory Kanada betrachtet. Policelli ist Autor von How-Active Directory Domain Services 2008 to (SAMS Publishing, 2009).

Page view tracker