Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Septembre 2009 >  Active Directory : AdminSDHolder, Groupes proté...
Affichage du contenu :  côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
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, Groupes protégés et SDPROP
John Policelli
 
Vue d'ensemble :
  • Présentation de AdminSDHolder, groupes protégés et SDPROP
  • Contrôle de groupes qui sont protégés par AdminSDHolder
  • Propagateur de descripteurs de sécurité

Services de domaine Active Directory utilise AdminSDHolder, groupes protégés et descripteur de sécurité propagateur (propagateur de descripteur de sécurité ou SDPROP en abrégé) aux utilisateurs privilégiés sécurisés et aux groupes contre toute modification accidentelle. Cette fonctionnalité a été introduite dans la version c d'Active Directory dans Windows 2000 Server et il est assez bien connu. Toutefois, pratiquement tous les administrateurs ont été négatif affectés par cette fonctionnalité, et qui va pour continuer sans avoir parfaitement évalué fonctionnement AdminSDHolder, groupes protégés et SDPROP.
Chaque domaine Active Directory possède un objet nommé AdminSDHolder, qui réside dans le conteneur System du domaine. L'objet AdminSDHolder possède une unique liste de contrôle (accès), qui est utilisée pour contrôler les autorisations des entités de sécurité membres de groupes Active Directory privilégiés intégrés (que j'aime appeler «protected»groupes). Toutes les heures, un processus d'arrière-plan appelé SDPROP s'exécute sur le contrôleur de domaine qui détient le rôle de maître d'opérations émulateur PDC. Il compare l'ACL sur toutes les entités de sécurité (utilisateurs, groupes et comptes d'ordinateur) appartenant à des groupes protégés contre l'ACL sur l'objet AdminSDHolder. Si les listes ACL ne sont pas identiques, l'ACL sur l'entité de sécurité est remplacée par l'ACL de l'objet Admin–SDHolder. En outre, l'héritage est désactivé sur l'entité de sécurité.
Comme vous pouvez le constater, plusieurs couches de sécurité sont incorporées dans cette fonctionnalité. Tout d'abord, les autorisations appliquées aux utilisateurs appartenant aux groupes protégés sont plus strictes que les autorisations par défaut appliquées sur les autres comptes utilisateur. Ensuite, cette fonctionnalité désactive l'héritage sur ces comptes privilégiés, garantissant que les autorisations appliquées au niveau du parent ne sont pas héritées par les objets protégés, quel que soit leur emplacement. Enfin, le processus SDPROP toutes les 60 minutes identifie les modifications manuelles à une liste de contrôle d'accès et les inverse afin que l'ACL correspond à l'ACL sur l'objet AdminSDHolder.
Consultez l'encadré «Un exemple commun de l'impact des AdminSDHolder, groupes de Protected et SDPROP»pour un aspect réelles à cette fonctionnalité.

L'objet AdminSDHolder
Comme nous l'avons mentionné, chaque domaine Active Directory contient un objet AdminSDHolder qui réside dans la partition système du domaine. Le nom unique de l'objet AdminSDHolder est «CN = AdminSDHolder, CN = System, DC = domain, DC = com "où DC = domain, DC = com est le nom unique du domaine. La figure 1 présente l'objet AdminSDHolder dans un domaine Windows Server 2008 R2.
Figure 1 Objet AdminSDHolder (cliquez sur l'image pour l'agrandir)

ACL par défaut
Étant donné que l'objet AdminSDHolder est utilisé dans le processus de sécurisation des comptes privilégiés, l'ACL par défaut sur l'objet AdminSDHolder est plus stricte que l'ACL sur les autres objets, tels que le domaine, unités d'organisation et conteneurs.
Dans l'ACL pour AdminSDHolder par défaut, le propriétaire par défaut est le groupe Admins du domaine, qui est assez rare. La plupart des objets Active Directory ont le groupe Administrateurs le propriétaire par défaut. C'est important car un propriétaire peut prendre le contrôle d'un objet et réinitialiser les autorisations.
Un autre facteur de conception important pour l'objet AdminSDHolder est que l'héritage est désactivé, ce qui garantit que non parent-level autorisations sont héritées.
Enfin, les groupes Administrateurs, Admins du domaine et administrateurs d'entreprise sont les groupes qui ont l'autorisation Écriture d'attributs sur AdminSDHolder, qui est plus strict que les autorisations par défaut appliquées aux autres objets Active Directory.

Groupes protégés
Comme déjà indiqué, autorisations AdminSDHolder s'appliquent aux entités de sécurité appartenant aux groupes protégés. La liste de groupes protégés a développée depuis le premier lancement de Active Directory dans Windows 2000 Server. La figure 2 indique la valeur par défaut protégé des groupes et les utilisateurs à partir de Windows 2000 Server pour Windows Server 2008 R2.
Par défaut de la figure 2 protégé groupes
Version commerciale de Windows 2000 Server
Windows 2000 Server avec SP1
Windows 2000 Server avec SP2
Windows 2000 Server avec SP3
Windows 2000 Server SP4
Windows Server 2003 RTM
Windows Server 2003 avec SP1
Windows Server 2003 avec SP2
Windows Server 2008 RTM
Windows Server 2008 R2
Administrateurs Opérateurs de compte Opérateurs de compte Opérateurs de compte
Administrateurs de domaine Administrateur Administrateur Administrateur
Administrateurs d'entreprise Administrateurs Administrateurs Administrateurs
Administrateurs du schéma Opérateurs de sauvegarde Opérateurs de sauvegarde Opérateurs de sauvegarde
  Éditeurs de certificats Administrateurs de domaine Administrateurs de domaine
  Administrateurs de domaine Contrôleurs de domaine Contrôleurs de domaine
  Contrôleurs de domaine Administrateurs d'entreprise Administrateurs d'entreprise
  Administrateurs d'entreprise KRBTGT KRBTGT
  KRBTGT Opérateurs d’impression Opérateurs d’impression
  Opérateurs d’impression Duplicateur Contrôleurs de domaine en lecture seule
  Duplicateur Administrateurs du schéma Duplicateur
  Administrateurs du schéma Opérateurs de serveur Administrateurs du schéma
  Opérateurs de serveur   Opérateurs de serveur
Un exemple commun de l'impact des AdminSDHolder, protégé par groupes et SDPROP
Active Directory la plupart des administrateurs sont AdminSDHolder, groupes et protégées SDPROP un scénario comme celle-ci :
Vous déléguez des autorisations sur un Organizational Unit (OU). Vous êtes informé ultérieurement que les autorisations sont en place pour la plupart, mais pas toutes, comptes d'utilisateurs dans l'unité d'organisation. Vous déterminez que l'ACL sur les comptes concernés est différente de vous délégué et que l'héritage n'est pas activé, afin que l'héritage résoudre le problème. Initialement, cela semble fonctionner, mais plus tard resurfaces le problème. Vous déterminez à nouveau que diffère de l'ACL et héritage a été désactivé.
J'ai vu personnes passent par ce cycle sans fin apparente maintes et maintes.
Cette situation se réellement produit par sa conception, cependant. Il est provoqué par AdminSDHolder, groupes protégés et SDPROP.
Les comptes affectés par ce problème appartiennent à un groupe protégé. Par conséquent, l'ACL sur ces comptes est héritée de l'objet AdminSDHolder dans le domaine, et l'héritage est désactivé. C'est pourquoi les autorisations qui vous délégués ne sont pas appliquées aux comptes d'utilisateur affecté. Lorsque vous activez manuellement l'héritage sur ces comptes, les autorisations déléguées sont ajoutées à la liste ACL.
Toutefois, lorsque le processus SDPROP s'exécute sur le contrôleur de domaine qui détient le rôle de maître d'opérations émulateur PDC — par défaut, toutes les 60 minutes, la liste ACL est remplacée à l'ACL sur l'objet AdminSDHolder et l'héritage est désactivé.
La liste des groupes protégés consistait à quatre groupes de sécurité en version commerciale de Windows 2000 Server. Dans Windows 2000 Server SP4 et Windows Server 2003, plusieurs autres groupes ont été ajoutés, y compris les comptes administrateur et KRBTGT. Dans Windows Server 2003 avec SP1 et versions ultérieures, Microsoft supprimé le groupe Éditeurs de certificats dans les groupes par défaut protégé. Dans Windows Server 2008, Microsoft étendu cette liste pour inclure le groupe contrôleurs de domaine en lecture seule. La liste de groupes protégés n'a pas été modifiée dans la version Release Candidate de Windows Server 2008 R2.

Contrôle de groupes protégés par AdminSDHolder
Dans mon expérience, un sous-ensemble de ces défaut protégé groupes entraîne des problèmes avec AdminSDHolder. Par exemple, de nombreuses organisations utiliser le groupe Opérateurs d'impression pour la gestion des services d'impression mais pas pour gestion d'Active Directory. Toutefois, le groupe Opérateurs d'impression est un groupe protégé, car il a élevés des autorisations sur les contrôleurs de domaine par défaut. Une meilleure solution consiste à supprimer les autorisations élevées ce groupe dispose sur les contrôleurs de domaine. Si vous suivez cette méthode conseillée (et vous devriez!), vous ne devrez probablement protéger ce groupe avec AdminSDHolder.
Vous pouvez exclure un sous-ensemble de la valeur par défaut empêcher des groupes du processus AdminSDHolder, y compris :
  • Opérateurs de compte
  • Opérateurs de serveur
  • Opérateurs d’impression
  • Opérateurs de sauvegarde
Cette possibilité de groupes de contrôles qui sont protégés par AdminSDHolder a été introduite par un correctif pour les versions RTM de Windows 2000 Server et Windows Server 2003 et est incluse dans le dernier service pack pour Windows Server 2003 et dans les versions RTM de Windows Server 2008 et Windows Server 2008 R2. Pour plus d'informations sur le correctif, accédez à délégué autorisations ne sont pas disponibles et l'héritage est automatiquement désactivé.
La possibilité de contrôle de groupes protégés par AdminSDHolder est activée par modification de l'indicateur dsHeuristic. Ceci est une chaîne Unicode dans lequel chaque caractère contient une valeur pour un seul paramètre à l'échelle du domaine. Position de caractère 16 est interprétée comme une valeur hexadécimale, où le caractère de la plus à gauche est la position 1. Par conséquent, les valeurs uniquement valides sont «0»par "f". Chaque groupe opérateur dispose d'un bit spécifique, comme dans figure 3.
La figure 3 dsHeuristic opérateur de bits
Bit Groupe à exclure Valeur binaire Valeur hexadécimale
0 Opérateurs de compte 0001 1
1 Opérateurs de serveur 0010 2
2 Opérateurs d’impression 0100 4
3 Opérateurs de sauvegarde 1000 8
Cette situation se complique au même lorsque vous essayez exclure plusieurs groupes AdminSDHolder, principalement parce que vous pouvez plusieurs combinaisons d'exclusions — par exemple, opérateurs de compte et opérateurs de serveur, ou opérateurs de compte et opérateurs de sauvegarde. Pour traiter ce problème, ajoutez simplement la valeur binaire de chaque groupe, puis convertir le résultat une valeur hexadécimale. Par exemple, pour exclure les opérateurs d'impression et opérateurs de sauvegarde groupes, prendre la valeur binaire pour les opérateurs d'impression (0100) de groupe et ajoutez-le à la valeur binaire des opérateurs de sauvegarde regrouper (1000), ce qui équivaut à 1100. Vous ensuite convertir la somme binaire (1100) la valeur hexadécimale (C).
Pour faciliter un peu cette tâche, la figure 4 répertorie toutes les combinaisons possibles au format binaire et hexadécimal.
Figure 4 valeurs dsHeuristic pour hors de combinaisons de groupes
Groupes à exclure Valeur binaire Valeur hexadécimale
Aucun (par défaut) 0 0
Opérateurs de compte 1 1
Opérateurs de serveur 10 2
Opérateurs de compte
Opérateurs de serveur
0001 + 0010 = 0011 3
Opérateurs d’impression 100 4
Opérateurs de compte
Opérateurs d’impression
0001 + 0100 = 0101 5
Opérateurs de serveur
Opérateurs d’impression
0010 + 0100 = 0110 6
Opérateurs de compte
Opérateurs de serveur
Opérateurs d’impression
0001 + 0010 + 0100 = 0111 7
Opérateurs de sauvegarde 1000 8
Opérateurs de compte
Opérateurs de sauvegarde
0001 + 1000 = 1001 9
Opérateurs de serveur
Opérateurs de sauvegarde
0010 + 1000 = 1010 Une
Compte d'opérateurs de serveur
Opérateurs de sauvegarde
0001 + 0010 + 1000 = 1011 B
Opérateurs d’impression
Opérateurs de sauvegarde
0100 + 1000 = 1100 C
Opérateurs de compte
Opérateurs d’impression
Opérateurs de sauvegarde
0001 + 0100 + 1000 = 1101 D
Opérateurs de serveur
Opérateurs d’impression
Opérateurs de sauvegarde
0010 + 0100 + 1000 = 1110 E
Opérateurs de compte
Opérateurs de serveur
Opérateurs de sauvegarde Opérateurs d'impression
0001 + 0010 + 0100 + 1000 = 1111 F
Une fois les groupes à exclure, vous êtes prêt à modifier l'attribut dsHeuristics. Pour plus d'informations sur ce processus, consultez l'encadré «How to use l'attribut dsHeuristics exclure les groupes de AdminSDHolder».

Déterminer si une entité de sécurité est protégée par AdminSDHolder
Un très grand nombre d'utilisateurs par défaut et les groupes est protégé par AdminSDHolder. Une chose à garder à l'esprit est que les utilisateurs sont protégés par AdminSDHolder si elles ont l'appartenance au direct ou transitive dans un groupe de sécurité ou de distribution. Groupes de distribution sont inclus comme un groupe de distribution ne peut pas être converti en un groupe de sécurité.
Supposons qu'un utilisateur appartient à une liste de distribution appelée IT Canada. La DL IT Canada fait partie le groupe de sécurité informatique d'Amérique du Nord ;le groupe de sécurité IT Amérique du Nord est membre du groupe Administrateurs. Étant donné que transitive de l'utilisateur l'appartenance au groupe contient le groupe Administrateurs (en raison de l'imbrication des groupes), le compte d'utilisateur est protégé par AdminSDHolder.
Il existe toutefois une méthode simple pour déterminer quels utilisateurs et groupes AdminSDHolder protège dans votre domaine. Vous pouvez interroger l'attribut adminCount pour déterminer si un objet est protégé par l'objet AdminSDHolder. Les exemples suivants utilisent l'outil ADFind.exe, qui peut être téléchargé à partir de joeware. le réseau.
  • Pour rechercher tous les objets dans un domaine sont protégés par AdminSDHolder, tapez :
Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN
  • Pour rechercher tous les objets utilisateur dans un domaine sont protégés par AdminSDHolder, tapez :
Adfind.exe -b DC=domain,DC=com -f "(&(objectcategory=person)(objectclass=user)(admincount=1))" DN
  • Pour rechercher tous les groupes dans un domaine sont protégés par AdminSDHolder, tapez :
Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN
Remarque : Dans les exemples précédents, remplacez DC = domain, DC = com avec le nom unique de votre domaine.

Objets orphelins AdminSDHolder
Lorsqu'un utilisateur est supprimé d'un groupe protégé, l'attribut adminCount sur ce compte d'utilisateur est remplacé par 0. Cependant, l'héritage n'est pas réactivé sur le compte d'utilisateur. Par conséquent, le compte d'utilisateur ne reçoive plus ses ACL de l'objet AdminSDHolder, mais il n'est pas également héritent des autorisations des objets parents. Le terme courant pour résoudre ce problème est «orphelins AdminSDHolder objets». Aucun mécanisme n'automatique pour corriger l'héritage sur les objets qui n'appartiennent plus au groupes protégés ;Vous devez traiter des objets orphelins AdminSDHolder manuellement. Microsoft a développé et mis à disposition un VBScript vous aidera à réactiver l'héritage des comptes d'utilisateurs qui étaient précédemment membres de groupes protégés. Pour rechercher le VBScript, atteindre délégué autorisations ne sont pas disponibles et l'héritage est automatiquement désactivé.

Propagateur de descripteurs de sécurité
SDPROP est un processus d'arrière-plan qui s'exécute sur le contrôleur de domaine qui détient le rôle de maître d'opérations émulateur PDC. Par défaut, SDPROP s'exécute toutes les 60 minutes. SDPROP est conçu pour comparer l'ACL sur les utilisateurs et groupes membres de groupes protégés. Si la liste ACL est le même, SDPROP ne touchent l'ACL. Toutefois, si l'ACL est différente, il est remplacé par l'ACL de l'objet AdminSDHolder.

Modification des procédures souvent SDPROP exécute
Si la fréquence par défaut de 60 minutes pour SDPROP exécuter n'est pas suffisante, vous pouvez le modifier en créant ou en modifiant l'entrée AdminSDProtectFrequency dans la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
Si cette clé n'existe pas, la fréquence par défaut (60 minutes) est utilisée.
Vous pouvez configurer la fréquence à n'importe où entre une minute et deux heures. Vous devez entrer le nombre de secondes lorsque vous créez ou modifiant l'entrée de Registre. La commande suivante va configurer SDPROP pour exécuter toutes les 10 minutes (600 secondes) :
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
Notez, cependant, que modification de cette sous-clé n'est pas recommandée, car ainsi peut augmenter LSA (autorité de sécurité locale) une surcharge de traitement.

Forcer SDPROP pour exécuter
Vous pouvez également forcer SDPROP pour exécuter dans les cas où vous testez les modifications ou vous ne pouvez pas attendre l'intervalle configuré. Forcer SDPROP pour exécuter implique manuellement l'initialisation de thread SDPROP à évaluer les autorisations héritées des objets dans Active Directory. Ce processus peuvent être atteints en effectuant les étapes suivantes sur le contrôleur de domaine qui détient le rôle de maître d'opérations émulateur PDC :
  1. Accédez à démarrer. Cliquez sur Exécuter. Tapez Ldp.exe. Cliquez sur OK.
  2. Dans le menu connexion dans la console LDP, cliquez sur connexion.
  3. Dans la boîte de dialogue connexion, tapez le nom du serveur que vous souhaitez vous connecter dans le champ du serveur et assurez-vous que 389 est répertorié dans le champ port. Cliquez sur OK.
  4. Dans le menu connexion, cliquez sur Lier.
  5. Dans la fenêtre liaison, sélectionnez la liaison que l'option utilisateur ayant ouvert une session, ou sélectionnez la liaison avec l'option informations d'identification. Si vous avez le second, entrez les informations d'identification que vous souhaitez lier à. Cliquez sur OK.
  6. Dans le menu Parcourir, cliquez sur Modifier.
  7. Dans la boîte de dialogue Modifier, laissez le champ nom de domaine vide. Tapez FixUpInheritance dans le champ attributs. Tapez Oui dans le champ de valeur. Sélectionnez l'opération Ajouter, puis appuyez sur ENTRÉE. La figure 5 présente l'aspect de la fenêtre Modifier.
  8. Dans la boîte de dialogue Modifier, cliquez sur Exécuter. Le volet d'informations sera identique au texte mis en surbrillance dans la figure 6.
La figure 5 la fenêtre de modification. Lorsque SDPROP forcer à s'exécuter dans la boîte de dialogue Modifier, cliquez sur Exécuter. Le volet de détails sera semblable au texte mis en surbrillance dans la figure 6. (Cliquez sur l'image pour l'agrandir)
Figure 6 Appel modifier une opération dans LDP.exe. (Cliquez sur l'image pour l'agrandir)
À ce stade, SDPROP doit initialiser. La quantité de temps que le processus SDPROP dépend de la taille de votre environnement Active Directory. L'environnement de plus, plus il faudra l'exécution du processus. Vous pouvez surveiller le compteur DS manifestations propagation dans l'objet de performances NTDS pour déterminer lorsque SDPROP a terminé, indiqué par une valeur de compteur de 0.

Conclusion
Le AdminSDHolder est une fonctionnalité de sécurité important dans Active Directory. AdminSDHolder, protégés groupes et descripteur de sécurité propagateur aide sécurisé comptes d'utilisateurs qui contiennent des autorisations Active Directory avec des privilèges élevés. La fonctionnalité AdminSDHolder a évolué à partir de Windows 2000 Server vers Windows Server 2008. Au cours de cette évolution, Microsoft a développé le nombre d'objets qui sont sécurisés par AdminSDHolder, a introduit la possibilité d'exclure certains groupes les Admin–SDHolder et ajouté la possibilité de contrôler la fréquence à laquelle SDPROP s'exécute.
La plupart des administrateurs Active Directory ont été introduites pour AdminSDHolder, intentionnellement ou accidentellement. Vous avez essayé de vous fournir une bonne compréhension de AdminSDHolder, son fonctionnement ainsi que le nettoyage est nécessaire lorsque vous supprimez un utilisateur d'un groupe protégé, ainsi que certains ajustements utiles. J'espère que ces informations aideront vous empêcher d'est interceptée désactiver la protection par la fonctionnalité AdminSDHolder la prochaine fois vous déléguez ou supprimez des autorisations Active Directory.
Utilisation de l'attribut dsHeuristics pour exclure les groupes de AdminSDHolder
L'attribut dsHeuristics peut être utilisé pour exclure certains groupes protégés par AdminSDHolder. Les instructions suivantes décrivent les étapes pour modifier l'attribut dsHeuristics sous Windows Server 2008 R2 :
  1. Ouvrez une session sur un contrôleur de domaine ou à un membre qui a le Remote Server administrateur outils (RSAT) installé.
  2. Accédez à démarrer. Cliquez sur Exécuter. Tapez adsiedit.msc, puis cliquez sur OK.
  3. Dans la console Modification ADSI, cliquez avec le bouton droit sur ADSI Edit dans l'arborescence. Sélectionnez se connecter À.
  4. Dans la fenêtre Paramètres de connexion, sélectionnez Configuration de la sélection d'une contexte de nommage connus liste déroulante. Cliquez sur OK.
  5. Dans l'arborescence de la console, développez Configuration, développez Services et développez Windows NT. Cliquez avec le bouton droit sur le nœud Service d'annuaire, puis sélectionnez Propriétés.
  6. Dans le CN = fenêtre Propriétés du service annuaire, sélectionnez dsHeuristics. Cliquez sur Modifier.
  7. Dans la fenêtre Éditeur d'attribut String, copiez la valeur existante pour dsHeuristics si elle est définie.
  8. Dans la fenêtre Éditeur d'attribut String, remplacez la valeur dsHeuristics avec ce que vous souhaitez définir, telles que 000000000100000f pour exclure les groupes Opérateurs de compte, opérateurs de serveur, opérateurs d'impression et opérateurs de sauvegarde. La figure A affiche la fenêtre Éditeur d'attribut String.

    Remarque : Remplacer les zéros dans la première partie de la valeur de ce que vous pouvez avoir déjà dans dsHeuristics. Assurez-vous d'avoir le nombre correct de chiffres à "f"ou n'importe quelle bits que vous souhaitez définir.
  9. Cliquez sur OK dans la fenêtre Éditeur d'attribut String. Cliquez sur OK dans l'attribut CN = fenêtre Propriétés du service annuaire.
Figure A Fenêtre d'éditeur d'attribut String(Click the image for a larger view)

John Policelli, MVP Microsoft pour les services d'annuaire MCTS, MCSA, ITSM, iNet +, Network + et A +, est un consultant informatique axée sur les solutions avec plus d'une décennie de succès combiné dans architecture de sécurité, planification stratégique et planification de récupération d'urgence. Ces neuf dernières années, il est concentré sur la gestion des identités et des accès et fournissant considérée leadership pour certains des installations plus grandes du Canada d'Active Directory. Policelli est l'auteur de Active Directory Domain Services 2008 procédure (Sams Publishing, 2009).

Page view tracker