SISR / Cybersécurité / Active Directory et GPO

Active Directory et GPO

Active Directory centralise l'authentification, l'annuaire et la politique de sécurité d'un parc Windows. C'est le support concret du RBAC et du moindre privilège vus en théorie.

1. Installer le rôle AD DS

1. Donner au serveur une adresse IP fixe et le déclarer comme son propre serveur DNS primaire.
2. Gestionnaire de serveur > Ajouter des rôles et des fonctionnalités : installer d'abord le service DNS.
3. Ajouter le rôle Services de domaine Active Directory (AD DS).
4. Promouvoir le serveur en contrôleur de domaine et créer la forêt / le domaine (ex. gameon.local).
5. Redémarrer, puis créer les unités d'organisation et les comptes.

Quelques termes à ne pas confondre :

En production, on déploie au moins deux contrôleurs de domaine : un DC unique est un point de défaillance unique, plus aucune authentification n'est possible s'il tombe. C'est le critère de disponibilité du triptyque DIC.

2. Le rôle du DNS

Active Directory ne peut pas fonctionner sans DNS : les clients localisent les contrôleurs de domaine via des enregistrements SRV publiés dans la zone du domaine. Un poste dont le DNS pointe vers la box ou vers un résolveur public ne trouvera pas le domaine, quelle que soit la qualité du reste de la configuration. C'est la cause numéro un des échecs de jonction au domaine.

nslookup -type=SRV _ldap._tcp.dc._msdcs.gameon.local
dcdiag /test:dns

3. Unités d'organisation et groupes

On ne range pas les comptes en vrac dans le conteneur Users : on construit une arborescence d'OU qui reflète l'organisation, parce que c'est sur les OU que se lient les GPO et que se délèguent les droits.

gameon.local
├── OU_Sieges
│   ├── OU_Utilisateurs
│   │   ├── OU_Comptabilite
│   │   ├── OU_Developpement
│   │   └── OU_Support
│   ├── OU_Ordinateurs
│   ├── OU_Groupes
│   └── OU_Admins

Groupes et RBAC

Le principe du RBAC se traduit directement ici : on n'attribue jamais un droit à un utilisateur, on l'attribue à un groupe, et on place les utilisateurs dans les groupes correspondant à leur fonction. À l'arrivée d'un salarié, on l'ajoute aux bons groupes ; à son départ, on désactive le compte — sans avoir à parcourir l'ensemble des ressources.

La méthode recommandée par Microsoft s'appelle AGDLP : les Acomptes vont dans des groupes Globaux, placés dans des groupes Domaine Local, auxquels on attribue les Permissions. L'intérêt est de séparer « qui fait quoi dans l'organisation » de « qui a accès à quel dossier », les deux n'évoluant pas au même rythme.

New-ADOrganizationalUnit -Name "OU_Developpement" -Path "OU=OU_Utilisateurs,DC=gameon,DC=local"
New-ADGroup -Name "G_Developpement" -GroupScope Global -Path "OU=OU_Groupes,DC=gameon,DC=local"
Add-ADGroupMember -Identity "G_Developpement" -Members alice, bob

4. Les GPO

Une stratégie de groupe applique automatiquement une configuration à un ensemble de postes ou d'utilisateurs. C'est ce qui rend une politique de sécurité réellement opposable : elle n'est pas une consigne, elle est imposée par le système.

• Deux volets : Configuration ordinateur (appliquée au démarrage) et Configuration utilisateur (appliquée à l'ouverture de session).
• Ordre d'application : Local, Site, Domaine, OU — d'où l'acronyme LSDOU. La dernière appliquée l'emporte, sauf blocage d'héritage ou option « appliqué / enforced ».
• Rafraîchissement automatique toutes les 90 minutes environ, ou forcé.

gpupdate /force        # forcer l'application
gpresult /r            # voir les GPO appliquées à la session courante
gpresult /h rapport.html

Exemples de GPO utiles en sécurité : verrouillage automatique de session, désactivation de l'exécution automatique des supports amovibles, configuration du pare-feu Windows, déploiement du proxy, restriction des droits d'installation, redirection des dossiers personnels.

5. Stratégie de mot de passe

Éditeur de gestion des stratégies de groupe > Default Domain Policy > Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de compte > Stratégie de mot de passe.

La stratégie de mot de passe du domaine s'applique au niveau du domaine, pas d'une OU : la lier à une OU n'a aucun effet. Pour différencier les exigences selon les populations (comptes d'administration plus stricts, par exemple), il faut passer par des Fine-Grained Password Policies (PSO), définies dans le centre d'administration AD et appliquées à des groupes.

6. Partages : NTFS et permissions de partage

Deux jeux de permissions coexistent sur un dossier partagé, et c'est une source de confusion classique.

Lors d'un accès réseau, les deux se cumulent et les permissions effectives correspondent aux plus restrictives des deux. Un utilisateur ayant « Contrôle total » en NTFS mais « Lecture » en partage ne pourra que lire à distance.

Pratique courante : laisser le partage en « Contrôle total » pour le groupe Utilisateurs authentifiés et piloter finement les droits en NTFS uniquement — un seul endroit à maintenir, avec la granularité la plus fine.

Rappel des droits sous Linux, pour la comparaison : r lire un fichier ou lister un répertoire, w modifier, créer ou supprimer, x exécuter un binaire ou traverser un répertoire.

7. Comptes à privilèges et comptes de service

• Séparer les comptes : un administrateur dispose d'un compte quotidien standard (alice) et d'un compte d'administration distinct (adm-alice). Le second ne sert jamais à lire ses mails ni à naviguer — c'est ce qui limite l'impact d'un phishing réussi.
• Renommer et désactiver le compte Administrateur intégré, dont le nom est connu de tous.
• Comptes de service : un compte dédié par service, sans droit d'ouverture de session interactive, avec les seules permissions nécessaires. Les Managed Service Accounts (gMSA) permettent en plus une rotation automatique du mot de passe.
• Procédure d'arrivée et de départ systématique : la création comme la suppression de comptes doit être formalisée. Les comptes de salariés partis mais toujours actifs sont une porte d'entrée classique.
• MFA sur les accès d'administration, surtout à distance.

8. Journalisation et revue des habilitations

Une politique de droits ne vaut que si elle est vérifiée dans la durée.

• Activer l'audit par GPO : ouvertures de session réussies et échouées, modifications de groupes sensibles, accès aux dossiers critiques. Les événements remontent dans l'observateur d'événements (identifiants 4624 connexion réussie, 4625 échec, 4728/4732 ajout à un groupe).
• Centraliser les journaux vers un serveur dédié : sur la machine d'origine, un attaquant ayant obtenu des droits d'administration peut les effacer.
• Revue annuelle des habilitations : repérer les comptes inutilisés ou obsolètes, les appartenances à des groupes à privilèges qui ne se justifient plus, et les droits accumulés au fil des changements de poste.
• Surveiller les comptes à privilèges : alertes sur l'ajout d'un membre au groupe Admins du domaine, sur les connexions hors horaires, sur les échecs répétés.

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly
Get-ADGroupMember "Admins du domaine"

9. Tester

1. Joindre une machine Windows 10 au domaine (DNS du client pointant vers le DC).
2. Se connecter avec un compte du domaine.
3. Tenter de changer le mot de passe pour une valeur triviale (12345) : le message d'erreur doit rappeler les exigences.
4. Recommencer avec un mot de passe conforme : le changement doit aboutir.
5. Vérifier avec gpresult /r que la GPO attendue est bien appliquée.
6. Sur un partage, retirer un droit NTFS et vérifier le comportement en accès distant.

Un test négatif et un test positif : c'est ce qui prouve que la stratégie s'applique réellement, et pas seulement qu'elle est enregistrée quelque part.