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é

Contenu

L'objet AdminSDHolder
ACL par défaut
Groupes protégés
Contrôle de groupes protégés par AdminSDHolder
Déterminer si une entité de sécurité est protégée par AdminSDHolder
Objets orphelins AdminSDHolder
Propagateur de descripteurs de sécurité
Modification des procédures souvent SDPROP exécute
Forcer SDPROP pour exécuter
Conclusion

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.

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.

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.

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).