Comment fonctionne les Rôles et délégations d’administration AD ?

Active Directory logo

Rôles et délégations d’administration de l’AD

Les droits d’administration portés par l’AD sont répartis en 2 catégories principales

  • L’administration de l’Active Directory et des contrôleurs de domaine
  • L’administration des serveurs membres et des applications

Afin de limiter la portée d’attaque connue de l’AD (Active Directory) tel que le « Pass The Hash » une des règles principales et de bien différentier les comptes permettant l’administration de l’AD de ceux pour l’administration des serveurs membres.

Principe du modèle RBAC dans l’AD

La mise en œuvre des délégations d’administration est faite sur le principe du modèle RBAC, c’est-à-dire que :

  • Chaque fonction sera associée à un « rôle »
  • Chaque « rôle » sera accrédité des « permissions » correspondantes (droits, stratégies, configuration, etc.)

Rôles devant être créés dans le modèle de base des domaines

L’étendue des groupes utilisés pour la mise en œuvre de ce modèle est contrainte par le choix de l’architecture logique : dans une forêt, les ressources dans un autre. La logique sera donc la suivante :

Cette double inclusion de groupes peut se comprendre de la façon suivante :

  • Le groupe Global permet d’identifier une population dans la forêt d’administration (Rôles)
  • Le groupe de Domaine Local permet d’accorder des autorisations (il peut s’agir d’autorisations sur un fichier, sur une application, sur un objet Active Directory, etc.). Le groupe de domaine local est hébergé dans le domaine où se trouve la ressource sur laquelle la permission s’applique

Exigences du modèle RBAC

En complément des permissions de base nécessaires à chaque fonction, le modèle RBAC doit permettre de garantir l’application des règles de sécurisation

  • Un administrateur ne doit pas cumuler des rôles d’administration de l’AD et des rôles d’administration de serveurs
  • Un rôle d’administration doit appliquer une stratégie de mot de passe adapté
  • Un compte non nominatif (dit compte de service) ne doit pas pouvoir ouvrir de session interactive (locale ou à distance)
  • Un administrateur ne doit pas avoir l’option « le mot de passe n’expire jamais » activée
  • Les rôles d’administration du schéma doivent être vides. L’utilisation de ces rôles n’est que temporaire et soumise à dérogation
  • Rôles d’administration de l’Active Directory et des contrôleurs de domaine
  • Recours aux groupes « built-in » pour l’administration de l’AD

Les limites du modèles d’administration RBAC

Certaines actions d’administration de l’AD sont complexes voire impossible à déléguer à des comptes de la forêt d’administration.

  • Modification du schéma
  • Création/suppression de relations d’approbation
  • Restauration AD
  • Ajout/suppression de domaines enfant
  • Sécurisation des groupes d’administration AD

Sécurisation des groupes d’administration de l’AD

La sécurisation des groupes d’administration peut se faire de deux manières différentes selon qu’ils s’agissent d’un groupe par défaut (appelés aussi « built-in ») et ses membres ou d’un groupe ajouté dans le modèle.

D’autre part un domaine d’administration sert uniquement à isoler les groupes d’administration.

  • Groupes de permissions du modèle

L’essentiel des permissions ne font pas parties du modèle de base de l’AD. Certaines sont cependant requises pour permettre la création des rôles listés précédemment.

NB : il n’est pas nécessaire d’apporter une permission de type « mot de passe complexe » dans les domaines puisque la stratégie du domaine appliquera par défaut une stratégie de mots de passe complexes dans ces deux domaines.

  • Sécurité : Spécifications complémentaires du modèle
Description
Les groupes built-in doivent rester localisés dans leur emplacement par défaut.

https://technet.microsoft.com/fr-fr/library/cc700835.aspx

Les groupes suivants de l’OU « users » doivent être déplacés dans l’OU « Administration\Groupe d’administration\niveau 1 » de la structure

    1. Administrateurs de l’entreprise
    2. Administrateurs du schéma
    3. Admins du domaine
    4. Propriétaires créateurs de la stratégie de groupe
Il est impératif de désactiver un compte lorsqu’il est retiré de la liste des membres d’un groupe d’administration protégé* (Cf. explication ci-dessous)
La création de groupe ou d’utilisateur (non natif) ne doit pas être faite dans le conteneur « Users ».
Les comptes utilisateurs doivent êtres des comptes différents des comptes d’administration
Les comptes d’administration de l’AD doivent être différents des comptes d’administration de serveurs membres ou d’applis
L’identifiant de connexion des utilisateurs membres d’un des rôles d’administration doit être conforme à la règle de nommage
Tous les groupes doivent suivre la convention de nommage
Tous les comptes bénéficiant de droits d’administration doivent appartenir à la forêt d’administration
Les comptes utilisateur et les comptes d’administration ne doivent pas avoir l’option « Le mot de passe n’expire jamais » activée.

Compte Privilégié

Le compte Administrateur est le seul compte privilégié built-in (par défaut). Les autres comptes privilégiés seront donc nécessairement créés par des administrateurs de l’AD grâce à :

  • Appartenance à un groupe privilégié (built-in ou non),
  • Octroi manuel de privilèges.

Certains privilèges sont considérés comme particulièrement sensibles du point de vue de la sécurité du fait qu’ils peuvent permettre des élévations de privilèges aux utilisateurs qui se les voient octroyés.

Remarque importante

L’attribut adminCount d’un objet AD, lorsque sa valeur est à 1, traduit le fait qu’il a fait partie à un moment donné d’un groupe d’administration built-in. Cette valeur n’est jamais réinitialisée à 0 lorsque l’appartenance au groupe est supprimée. L’héritage des permissions AD ne s’appliquant pas sur les objets ayant la valeur à 1 dans cet attribut, des problèmes de sécurité peuvent alors survenir.

L’attribut adminCount doit être positionné à 1 uniquement sur les comptes membres d’un groupe d’administration protégé.

Vous ne parvenez pas à suivre ses étapes seul ?

Prenez une heure de coaching : ici

Autres sujet d’article proposé sur ADCS (Active Directory Certificate Services)

Event id des logs

Liens utiles

Syntaxe des lignes de commandes

10 thoughts on “Comment fonctionne les Rôles et délégations d’administration AD ?”

Laisser un commentaire