TIP 3.12 – Gérer groupes, unités d’organisation et droits

Créer des comptes Active Directory ne suffit pas à administrer correctement les accès.

Dans une organisation, il faut également déterminer :

• comment regrouper les utilisateurs ;
• comment organiser les objets dans l’annuaire ;
• comment attribuer les permissions aux ressources ;
• comment conserver une administration compréhensible et maintenable.

Deux notions sont essentielles :

les groupes de sécurité, utilisés pour attribuer des droits ;

les unités d’organisation, utilisées pour organiser et administrer les objets Active Directory.

1. Groupe et OU : deux fonctions différentes

Il est important de ne pas confondre ces deux objets.

2. Les groupes de sécurité

Un groupe de sécurité permet de rassembler plusieurs comptes ou groupes et peut être utilisé dans les listes de contrôle d’accès.

Par exemple :

GG_COMPTABILITE

peut contenir les utilisateurs du service Comptabilité.

Au lieu d’attribuer une permission à chaque utilisateur, on peut gérer l’accès par groupe.

3. Groupe de sécurité et groupe de distribution

Active Directory distingue notamment :

Pour contrôler l’accès à un partage réseau, on utilise donc un groupe de sécurité.

4. Les portées des groupes

Dans Active Directory, un groupe possède également une portée.

Les principales sont :

• Globale ;
• Domaine local ;
• Universelle.

5. Groupe global

Un groupe global est couramment utilisé pour regrouper des utilisateurs partageant une caractéristique ou un rôle.

Exemples :

GG_COMPTABILITE

GG_RH

GG_INFORMATIQUE

On peut ainsi considérer le groupe comme une représentation du métier ou du rôle.

6. Groupe Domaine local

Un groupe de portée Domaine local est particulièrement adapté pour recevoir une permission sur une ressource située dans le domaine où il existe.

Exemples :

GDL_COMPTA_MODIF

GDL_COMPTA_LECTURE

GDL_RH_MODIF

Ces groupes représentent davantage un niveau d’accès à une ressource.

7. Groupe universel

Les groupes universels sont surtout utiles dans certaines architectures comportant plusieurs domaines.

Ils permettent de regrouper des membres provenant de plusieurs domaines selon les règles Active Directory.

Dans un environnement simple à domaine unique, le technicien de proximité rencontre souvent principalement les groupes :

Global et Domaine local.

8. La méthode AGDLP

Une méthode classique d’organisation des accès est appelée :

AGDLP

Elle signifie :

9. Exemple concret AGDLP

Sophie travaille en Comptabilité.

Son compte est :

smartin

Elle est ajoutée au groupe :

GG_COMPTABILITE

Le groupe global est lui-même membre de :

GDL_COMPTA_MODIF

Ce dernier reçoit la permission :

Modification

sur :

D:\Partages\Comptabilite

Le droit n’est donc pas attribué directement à Sophie.

10. Pourquoi cette méthode est-elle utile ?

Imaginons que Sophie change de service.

Avec une structure correcte, il suffit principalement de modifier son appartenance aux groupes métier appropriés.

Il n’est pas nécessaire de rechercher son compte dans toutes les ACL de tous les serveurs.

Cela facilite :

• l’administration ;
• les audits ;
• les changements de poste ;
• les départs ;
• la compréhension des droits.

11. Créer un groupe avec l’interface graphique

Depuis :

dsa.msc

on peut créer un groupe dans l’OU prévue.

Il faut notamment choisir :

• son nom ;
• sa portée ;
• son type.

Pour un groupe métier dans un domaine simple :

Nom : GG_COMPTABILITE

Portée : Globale

Type : Sécurité

12. Créer un groupe global avec PowerShell

New-ADGroup `
  -Name "GG_COMPTABILITE" `
  -SamAccountName "GG_COMPTABILITE" `
  -GroupCategory Security `
  -GroupScope Global `
  -Path "OU=Groupes,DC=entreprise,DC=local"

Il faut évidemment adapter le chemin à la structure réelle de l’annuaire.

13. Créer un groupe Domaine local

New-ADGroup `
  -Name "GDL_COMPTA_MODIF" `
  -SamAccountName "GDL_COMPTA_MODIF" `
  -GroupCategory Security `
  -GroupScope DomainLocal `
  -Path "OU=Groupes,DC=entreprise,DC=local"

Ce groupe peut ensuite recevoir la permission sur la ressource Comptabilité.

14. Ajouter un utilisateur à un groupe

Avec PowerShell :

Add-ADGroupMember `
  -Identity "GG_COMPTABILITE" `
  -Members "smartin"

Cette opération doit correspondre à une demande autorisée.

15. Ajouter un groupe dans un autre groupe

Dans la logique AGDLP :

Add-ADGroupMember `
  -Identity "GDL_COMPTA_MODIF" `
  -Members "GG_COMPTABILITE"

Le groupe métier devient ainsi membre du groupe représentant le niveau d’accès.

16. Retirer un membre

Remove-ADGroupMember `
  -Identity "GG_COMPTABILITE" `
  -Members "smartin"

PowerShell demande normalement une confirmation.

Pour automatiser certaines opérations maîtrisées :

-Confirm:$false

peut être utilisé avec prudence.

17. Afficher les membres d’un groupe

Get-ADGroupMember `
  -Identity "GG_COMPTABILITE"

Pour obtenir uniquement certaines informations :

Get-ADGroupMember "GG_COMPTABILITE" |
Select-Object Name,
              SamAccountName,
              ObjectClass

18. Connaître les groupes d’un utilisateur

PowerShell fournit :

Get-ADPrincipalGroupMembership smartin

Par exemple :

Get-ADPrincipalGroupMembership smartin |
Select-Object Name

C’est particulièrement utile lorsqu’un utilisateur signale un problème d’accès.

19. Attention aux appartenances imbriquées

Un utilisateur peut recevoir un droit indirectement.

Par exemple :

Sophie est membre de GG_COMPTABILITE, lui-même membre de GDL_COMPTA_MODIF.

Une lecture rapide des groupes directement affectés à Sophie peut donc ne pas suffire pour comprendre tous ses accès.

20. Qu’est-ce qu’une OU ?

Une Organizational Unit est un conteneur logique Active Directory.

Elle sert principalement à organiser l’annuaire.

Une organisation pourrait utiliser :

• OU Utilisateurs ;
• OU Ordinateurs ;
• OU Serveurs ;
• OU Groupes ;
• des sous-OU par service ou type d’équipement.

21. Une OU n’est pas un groupe de sécurité

Placer Sophie dans une OU appelée :

Comptabilite

ne lui donne pas automatiquement accès au partage :

\\SRV-FICHIERS\COMPTABILITE

Pour cela, on utilise les mécanismes d’autorisation appropriés, généralement basés sur des groupes de sécurité.

22. Créer une OU avec PowerShell

New-ADOrganizationalUnit `
  -Name "Comptabilite" `
  -Path "OU=Utilisateurs,DC=entreprise,DC=local"

On peut vérifier les OU avec :

Get-ADOrganizationalUnit -Filter *

23. Déplacer un utilisateur dans une OU

Un objet peut être déplacé lorsque l’organisation évolue.

Il faut d’abord obtenir son Distinguished Name :

Get-ADUser smartin |
Select-Object DistinguishedName

Puis, si la procédure le prévoit :

Move-ADObject `
  -Identity "CN=Sophie Martin,OU=Comptabilite,OU=Utilisateurs,DC=entreprise,DC=local" `
  -TargetPath "OU=Finances,OU=Utilisateurs,DC=entreprise,DC=local"

24. Déplacer un objet peut avoir des conséquences

Une OU peut être concernée par :

• des GPO ;
• des délégations ;
• des scripts ;
• des outils d’administration ;
• des processus automatisés.

Déplacer un utilisateur ou un ordinateur n’est donc pas une simple opération esthétique.

25. La délégation d’administration

Active Directory permet de déléguer certaines opérations sur une OU à une équipe sans lui donner tous les droits du domaine.

Par exemple, le support peut être autorisé à :

• réinitialiser des mots de passe ;
• déverrouiller des comptes ;
• créer certains utilisateurs ;
• joindre ou gérer certains postes.

sans devenir administrateur du domaine.

26. Retour aux droits sur les fichiers

Dans TIP 3.8, nous avons vu les permissions NTFS et de partage.

Une architecture correcte peut par exemple utiliser :

On attribue ces permissions aux groupes représentant les niveaux d’accès.

27. Exemple de changement de service

Sophie quitte Comptabilité et rejoint les Finances.

Une procédure correcte peut prévoir :

1. validation de la demande ;
2. retrait de Sophie des groupes Comptabilité devenus inutiles ;
3. ajout aux groupes Finances requis ;
4. déplacement dans l’OU appropriée si l’architecture le nécessite ;
5. contrôle des accès ;
6. documentation.

Il ne faut pas conserver ses anciens accès « au cas où » sans justification.

28. Le principe du moindre privilège

Un utilisateur ne doit appartenir qu’aux groupes nécessaires à ses missions.

Exemple :

Un utilisateur devant uniquement consulter les documents Comptabilité doit être orienté vers un groupe de Lecture, pas automatiquement vers le groupe de Modification.

29. Groupes administratifs sensibles

Certains groupes Active Directory accordent des privilèges importants.

Par exemple :

Domain Admins

L’appartenance à ces groupes doit être strictement contrôlée.

Un utilisateur ne doit jamais être ajouté à un groupe administratif simplement pour résoudre un problème de droits sur un dossier.

30. Vérifier avant de modifier

Lorsqu’un utilisateur indique :

« Je n’ai pas accès au dossier », commence par comprendre l’existant.

Vérifie :

• le compte utilisé ;
• les groupes de l’utilisateur ;
• la structure d’imbrication ;
• les permissions du partage ;
• les permissions NTFS ;
• les droits réellement nécessaires.

Ne l’ajoute pas immédiatement à plusieurs groupes « pour tester ».

31. Les changements de groupes et la session utilisateur

Lorsqu’une appartenance à un groupe change, le nouvel accès n’est pas toujours visible instantanément dans une session déjà ouverte.

Le jeton de sécurité de l’utilisateur est notamment construit lors de son authentification.

Selon le contexte, une nouvelle ouverture de session peut donc être nécessaire pour prendre en compte certains changements.

32. Vérifier les groupes dans la session

Windows permet d’afficher les groupes présents dans le jeton de sécurité de la session avec :

whoami /groups

Cette commande complète utilement les informations récupérées directement dans Active Directory.

33. Cas pratique – Mauvais usage d’une OU

Sophie est déplacée dans :

OU=Comptabilite

mais elle n’accède toujours pas au dossier Comptabilité.

34. Cas pratique – Droit attribué directement

Le dossier Comptabilité contient dans son ACL :

Sophie Martin : Modification

ainsi que plusieurs dizaines d’autres utilisateurs ajoutés individuellement.

35. Cas pratique – Utilisateur change de service

Sophie appartient à :

GG_COMPTABILITE

Elle rejoint maintenant les Finances.

36. TP – Mettre en place les accès Comptabilité

\\SRV-FICHIERS\COMPTABILITE

New-ADGroup `
  -Name "GG_COMPTABILITE" `
  -SamAccountName "GG_COMPTABILITE" `
  -GroupCategory Security `
  -GroupScope Global `
  -Path "OU=Groupes,DC=entreprise,DC=local"

Add-ADGroupMember `
  -Identity "GG_COMPTABILITE" `
  -Members "smartin","pdupont"

New-ADGroup `
  -Name "GDL_COMPTA_MODIF" `
  -SamAccountName "GDL_COMPTA_MODIF" `
  -GroupCategory Security `
  -GroupScope DomainLocal `
  -Path "OU=Groupes,DC=entreprise,DC=local"

Add-ADGroupMember `
  -Identity "GDL_COMPTA_MODIF" `
  -Members "GG_COMPTABILITE"

Get-ADGroupMember "GG_COMPTABILITE"

Get-ADGroupMember "GDL_COMPTA_MODIF"

GDL_COMPTA_MODIF

Quiz – Vérifie tes connaissances