Active Directory : LDIF, une extraction pour les gouverner tous

L’extraction d’un Active Directory, annuaire LDAP par Microsoft pour les OS Windows, permet de réaliser une multitude de contrôles, simples à mettre en œuvre, automatisables et ainsi créer le premier rempart dans votre gouvernance des accès sur vos systèmes Windows.

L’objectif de cet article est de vous présenter l’extraction LDIF d’un AD, comment elle s’obtient ainsi qu’une série de contrôles basés sur les recommandations de l’ANSSI.

1 – Extraction LDIF, quel format pour quelles données ?

LDIF pour « LDAP Data Interchange Format » est un format standardisé pour permettre l’échange de données d’un annuaire LDAP. Il représente donc les données d’un annuaire mais il permet aussi les actions sur un annuaire (ajout, modification, suppression d’une donnée). L’extraction LDIF est un fichier texte (avec pour extension ldif ou ldf) et peut donc être lu ou modifié à l’aide d’un simple éditeur de texte.

A l’intérieur, les données sont formatées sous forme d’objet ou d’enregistrement, chaque enregistrement est séparé par une ligne vide. La fin du fichier est marquée par deux lignes vides. Les enregistrements sont composés d’un ou plusieurs attributs représentés par un couple « nom : valeur ».

dn: cn=The Postmaster,dc=example,dc=com
objectClass: organizationalRole
cn: The Postmaster

2 – Comment obtenir l’extraction LDIF d’un Active Directory

Microsoft a mis à disposition un outil d’extraction dédié. De son nom complet « Lightweight Directory Access Protocol Data Interchange Format Directory Exchange », mais plus communément appelé LDIFDE, il est un outil de ligne de commande qui permet d’importer ou d’exporter des fichiers LDIF. Cet outil est disponible sur les serveurs Windows lorsque le rôle serveur AD DS ou AD LDS (Active Directory Lightweight Directory Services) est positionné sur la machine.

3 – Que faire avec mon extraction ?

Maintenant que nous avons une extraction LDIF de notre AD en bonne et due forme, il est temps de passer à la partie qui nous intéresse ici : les contrôles !

Nous vous proposons 23 contrôles à réaliser sur votre extraction pour identifier les anomalies à votre gouvernance des identités et des accès et éviter les risques de vulnérabilités de votre SI.

Contrôle 1 : Un nombre important de membres de groupes privilégiés

Les groupes privilégiés sont les groupes d’administration et les groupes opératifs ayant tous les droits et privilèges sur le domaine ou pouvant se les attribuer. Nous avons les groupes suivants :

• Account Operators
• Administrators
• Backup Operators
• Domain Admins
• Enterprise Admins
• Print Operators
• Schema Admins
• Server Operators

L’attribution de ces groupes est à éviter, ou seulement si l’ensemble des permissions est réellement nécessaire. Il faudra préférer l’utilisation de groupe « custom » appliquant la politique de moindre privilège.

Contrôle 2 : Contrôleurs de domaine incohérents

Un contrôleur de domaine est un serveur qui permet d’authentifier un utilisateur sur le domaine et valider son accès au réseau. Il est donc important que ses attributs d’UAC (User Account Control) soient correctement positionnés. Il faut donc vérifier que le contrôleur de domaine dispose des attributs SERVER_TRUST_ACCOUNT et TRUSTED_FOR_DELEGATION et aucun autre. Des attributs supplémentaires pourront être appliqués pour les « Read Only Domain Controller » (RODC)

Contrôle 3 : Comptes privilégiés sans pré-authentification Kerberos

Kerberos est un protocole d’authentification qui permet l’utilisation d’une authentification forte par le biais de clefs secrètes

Les comptes privilégiés (comptes ayant ou pouvant s’octroyer tous les droits sur le domaine) ne doivent pas disposer de l’attribut « DONT_REQUIRE_PREAUTH ».

Contrôle 4 : Comptes privilégiés avec SPN

L’attribut servicePrincipalName est positionné par défaut sur les comptes machines. Cet attribut ne doit jamais être positionné sur un compte privilégié car une attaque « brute force » pourrait retrouver le mot de passe du compte privilégié par l’intermédiaire du ticket émis par Kerberos.

Contrôle 5 : Comptes privilégiés dont le mot de passe n’expire jamais

Inutile de lister les innombrables risques liés à cette anomalie. L’attribut « DONT_EXPIRE » ne doit jamais être positionné sur un compte privilégié. L’ensemble du domaine pourrait être facilement compromis (par un ancien collaborateur par exemple).

Contrôle 6 : Comptes privilégiés dont le mot de passe est inchangé depuis une certaine période

Afin de limiter les risques lors d’un vol de mot de passe, il est important d’avoir une rotation fréquente. C’est vrai pour l’ensemble des utilisateurs mais encore plus importants pour les comptes privilégiés.

Contrôle 7 : Contrôleurs de domaine dont le mot de passe de compte d’ordinateur est inchangé depuis plus de 45 jours

Par défaut, la rotation s’effectue tous les 30 jours. Si celle-ci n’a pas pu être réalisée, il est important d’investiguer sur la cause dans les plus brefs délais.

Contrôle 8 : Contrôleurs de domaine inactifs

Par défaut, un contrôleur de domaine se connecte tous les 30 jours pour changer son mot de passe. L’absence d’authentification peut être causé par une désynchronisation. Dans ce cas, le contrôleur de domaine doit être réinstallés ou supprimés.

Contrôle 9 : Comptes avec un primaryGroupId inférieur à 1 000

Cet attribut permet d’associer un utilisateur à un groupe de manière implicite. Certaines interfaces n’affichent pas cette relation dans la liste des membres d’un groupe. Il est donc important de laisser cette valeur par défaut 513 pour un utilisateur, 514 pour un invité, 515 pour un ordinateur.

Contrôle 10 : Comptes membres du groupe DnsAdmins

Il est recommandé de ne pas utiliser le groupe DnsAdmins. Celui-ci permet d’exécuter du code par le service DNS qui est habituellement hébergé sur le contrôleur de domaine.

Contrôle 11 : Nombre important de comptes actifs inutilisés

Un compte dormant est un compte qui ne s’est pas connecté sur le domaine depuis un certain temps. Celui-ci peut être un compte rarement utilisé (ou son propriétaire est parti en congé) ou un compte obsolète (compte rattaché à un collaborateur parti de l’organisation). Il est important de pouvoir catégoriser efficacement les comptes dormants pour pouvoir désactiver les comptes obsolètes. Cette action permet de réduire la surface d’attaque mais aussi réduire la charge de travail lors d’une revue de droits.

Contrôle 12 : Délégation d’authentification non contrainte

La propriété « TRUSTED_FOR_DELGATION » ne doit être portée uniquement par les contrôleurs de domaine. Si un autre compte possède cet attribut, alors celui-ci pourra s’authentifier auprès d’un service Kerberos avec l’identité d’un autre compte s’étant déjà authentifié auprès du premier compte.

Contrôle 13 : Comptes sans pré-authentification Kerberos

L’attribut « DONT_REQUIRE_PREAUTH » ne doit pas être portée par un compte.

Contrôle 14 : Comptes utilisateurs avec un chiffrement Kerberos faible

Kerberos peut utiliser le chiffrement DES pour émettre des tickets. Cependant, cet algorithme est considéré comme obsolète donc l’attribut « USE_DES_KEY_ONLY » est à retirer des comptes de l’AD.

Contrôle 15 : Comptes dont le mot de passe n’expire jamais

Deuxième contrôle sur l’expiration du mot de passe, mais cette fois-ci le critère ne se limite plus aux comptes privilégiés mais à l’ensemble des utilisateurs de l’AD.

Contrôle 16 : Mauvaise version de l’Active Directory

Dans certaines versions de l’Active Directory, les groupes Key Admins et Enterprise Key Admins ont des « Access Control Entries » (ACE) trop permissives. Les versions Windows Server 1709 corrige ce problème, il est donc important de faire une mise à jour. Il suffit de vérifier la valeur « ActiveDirectoryUpdate » dans le fichier LDIF. Si la version est égale à 15, il est recommandé de faire la mise à jour.

Contrôle 17 : Le groupe « Pre-Windows 2000 Compatible Access » contient Anonymous

Ce groupe ne doit contenir que « Utilisateurs authentifiés » (S-1-5-11) et non « Anonymous » (S-1-5-7). Dans le cas contraire, une énumération anonyme de certains éléments est possible auprès du contrôleur de domaine.

Contrôle 18 : Mot de passe du compte krbtgt inchangé depuis plus d’un an

La compromission du compte « krbtgt » permettrait à un attaquant de forger des tickets Kerberos et ainsi s’authentifier avec des droits d’Administration sur l’ensemble du domaine.

Contrôle 19 : Compte avec un primaryGroupID modifié

Nous conseillions plus tôt d’interdire les primaryGroupId inférieur à 1 000 (hors valeur par défaut). Nous conseillons maintenant d’interdire la modification de cette propriété qui permet l’appartenance à un groupe de manière implicite. Il faut préférer la déclaration explicite par le biais de la propriété « MemberOf ».

Contrôle 20 : Comptes ou groupes membres de « Pre-Windows 2000 Compatible Access »

Mêmes explications que pour le contrôle 17, mais cette fois-ci on élargit le périmètre de contrôle pour éviter que Anonymous puisse tout de même être membre de ce groupe par un intermédiaire.

Contrôle 21 : Comptes privilégiés non membres du groupe « Protected Users »

Le groupe « Protected Users » permet de mettre en place certaines barrières aux utilisateurs membres :

• Forcer l’authentification Kerberos
• Réduire la durée de vie des tickets Kerberos
• Forcer l’utilisation d’algorithme de chiffrements forts (ex : AES)
• Interdire la mise en cache du mot de passe sur les postes de travail
• Interdire toute forme de délégation

Contrôle 22 : Comptes ayant leur mot de passe stocké de manière réversible

Si l’attribut « ENCRYPTED_TEXT_PASSWORD_ALLOWED » est positionné sur un compte alors le mot de passe de ce compte peut être récupéré en clair.

Contrôle 23 : Comptes ou groupes ayant un historique de SID

L’attribut sIDHistory doit être vide pour l’ensemble des utilisateurs et groupes du domaine. S’il est rempli, celui génère des logs qui polluent les journaux et il peut être utilisé par un attaquant pour se donner des droits illégitimes sur des ressources.

Conclusion

Nous venons de lister quelques contrôles que l’on peut facilement exécuter pour un aperçu de la conformité de son Active Directory aux bonnes pratiques de l’ANSSI. De plus, ces contrôles sont facilement automatisables par le biais d’un script PowerShell.

Une fois les contrôles mis en place, il faut pouvoir remonter les anomalies de manière claire pour qu’elles puissent être gérées de manière rapide.

Kleverware propose de mener ces contrôles de manière « One Shot » pour avoir un aperçu rapide des premières actions à mener ou bien d’intégrer ces contrôles à une politique de gouvernance des identités et accès beaucoup plus large qui couvre l’ensemble du SI, le tout consultable depuis une interface web pour des rapports précis et clairs.