audit de l'ad : contrôle des bonnes pratiques dans une

Audit de l’AD : Contrôle des bonnespratiques dans une université de grande

taille avec des outils Open Source.

Yves AgostiniRSSI - Université de Lorraine34 Cours Léopold54 000 Nancy

Camille HerryAdministrateur Active Directory ULCampus ARTEM - BP 1423454 042 Nancy Cedex

RésuméActive Directory est un annuaire de services pour les systèmes d’exploitation Windows largement utilisédans notre communauté. Ses capacités d’identification, d’authentification, de déploiement de stratégies oud’applications en font un service critique pour un établissement. Cependant, ses nombreuses fonctionnalitéssont complexes à maîtriser et il n’existe pas d’interfaces pour s’assurer de la cohérence de l’ensemble desparamètres. Il faut alors régulièrement vérifier que des erreurs de manipulations n’aient pas compromis lasécurité de l’établissement.

Après un rapide rappel des bonnes pratiques d’administration d’un Active Directory et des mesures sélec-tionnées dans le contexte particulier des universités, cette présentation abordera les possibilités d’auto-évaluation à l’aide d’outils open source. Ces outils sont facilement disponibles et l’accès aux codes sourcesnous permet d’être sûr de leur fonctionnement. Les principaux outils que nous avons utilisés proviennentde l’ANSSI et d’Airbus ainsi que nos propres développements librement distribués. Ces développements quiétendent les fonctionnalités des autres outils open source, nous ont permis de gérer le contexte particulierdes établissements universitaires. En effet, contrairement à l’industrie, la gestion des parcs informatiquesuniversitaires nécessitent généralement un grand nombre de délégations.

Sans disposer d’experts pointus dans l’audit de serveurs Active Directory, cette démarche nous a permisd’avoir une première vision de l’état de notre système et de corriger rapidement un certain nombre defaiblesses et de mauvaises pratiques involontaires.

Mots clefsActive Directory, AD, Audit, BTA, Sécurité, Open source

1 Introduction

Lors de la fusion des établissements d’enseignement supérieur lorrains, une architecture Active Directorya été mise en place pour gérer les accès et les configurations des systèmes Windows. Le groupe de travailchargé de ce projet a été formé aux bonnes pratiques de déploiement de cette architecture puis a travaillé à

JRES 2017 - Nantes 1/12

harmoniser les pratiques des anciens établissements. Après cinq ans de déploiement et de fonctionnement,notre système gère actuellement 106000 comptes 1, 800000 groupes et 15000 machines, répartis sur 18contrôleurs de domaine. Il était temps de s’interroger sur la qualité de ce déploiement.

Si nous disposons d’une bonne connaissance des systèmes Windows, nous ne disposons cependant pasd’une expertise absolue. Cet article va présenter notre démarche pour auditer nous même notre ActiveDirectory à l’aide d’outils open source. Ces outils, facilement disponibles et dont l’accès aux codes sourcesnous permet d’être sûr de leur fonctionnement, nous ont permis d’avoir une première vision de l’état de notresystème et de corriger rapidement un certain nombre de faiblesses et de mauvaises pratiques involontaires.

2 C’est quoi Active Directory ?

Les systèmes Windows sont largement répandus dans nos établissements, en particuliers sur les postesutilisateurs ou les salles pédagogiques.

Pour gérer les droits d’accès et la configuration de ces postes, Microsoft propose la mise en place d’unearchitecture Active Directory (AD). Il s’agit d’une base de données, non relationnelle, de toutes les res-sources des systèmes Windows. Cette base de donnée est répliquée entre plusieurs serveurs, les DomainsControllers (DC), qui sont interrogés par les clients pour vérifier les autorisations d’accès et récupérer lesinformations de configuration.

Chaque ressource d’un système Windows dispose d’un descripteur de sécurité où est explicité quels utilisa-teurs, groupes ou machines peuvent accéder ou sont explicitement interdits. Ces autorisations peuvent êtrespécifiques, s’obtenir par héritage, parvenir des configurations par défaut ou encore par des mécanismes im-plicites plus ou moins documentés. La complexité de ce modèle d’autorisations crée rapidement un volumed’information important. De plus, les interfaces de gestion fournies par l’interface graphique des systèmesWindows permettent essentiellement une consultation manuelle qui s’avère longue et répétitive. À plus oumoins long terme, des erreurs de gestion vont créer des objets avec des autorisations excessives et doncpotentiellement dangereux. Il apparaît qu’il ne suffit pas de veiller à la validité des authentifications. Il fautégalement examiner régulièrement les autorisations effectives.

3 Risques et bonnes pratiques

Malgré l’étendue géographique de l’université de Lorraine, la gestion complète du réseau régional permet dedisposer sur tous les sites d’un accès performant aux serveurs de l’Active Directory. Cela permet de limiterle nombre de serveurs et de domaines et d’éviter les problématiques d’intégration de forêts (intégrationinter-domaines).

Le système d’information de l’établissement gère les arrivées et départs des personnels et étudiants. Leurscomptes sont ensuite synchronisés depuis l’annuaire ldap avec l’AD pour permettre l’accès aux systèmesWindows.

L’AD contient alors l’ensemble des mots de passe chiffrés de tous les comptes.

Le premier risque apparent est la protection de la base de données 2. L’accès aux contrôleurs de domaine estalors particulièrement sensible. Les accès physiques et réseau, doivent naturellement être pris en compte,cependant cet article traitera uniquement de l’architecture et des accès logiques.

1. Dont un certain nombre de comptes supprimées qui n’ont pas encore été expurgés2. Techniquement cette base ce situe sur tous les contrôleurs de domaine et peut être exportée sous la forme d’un fichier ntds.dit.


3.1 Bonnes pratiques

Un bon document de référence de l’ANSSI donne une liste très complète des bonnes pratiques de sécuri-sation d’Active Directory [1]. Lors de la création de notre AD, en 2012, nous en avions déjà sélectionné etdéfini un certain nombre. Par exemple l’abandon du protocole de chiffrement obsolète LM, mais surtout ladéfinition de plusieurs conventions de nommage pour faciliter la visualisation et la gestion des éléments del’AD. Ces conventions portent sur les identifiants de compte, les entités (OU), les groupes et les stratégiesde groupes (GPO). Il a été défini en particulier une hiérarchie des comptes à trois niveaux :

— le niveau 1 correspond aux comptes utilisateurs synchronisés depuis le système d’information ouexceptionnellement créés temporairement localement,

— le niveau 2 correspond aux administrateurs locaux (Délégation de droits aux équipes de proximité) :il permet de gérer les machines, comptes, groupes et stratégies d’une unité organisationnelle (OU),

— le niveau 3 correspond aux administrateurs du domaine : seuls ces comptes permettent d’accéder auxDC.

Les niveaux 2 et 3 sont des comptes spécifiques qui doivent être différents du compte utilisateur géré par lesystème d’information. À cet effet, les administrateurs locaux disposent d’un compte supplémentaire sousla forme login-loc, les administrateurs de domaine ont également un compte spécifique sous la formelogin-dom.

Un rapport hebdomadaire, sous format html, généré à partir de scripts powershell, est transmis aux ad-ministrateurs locaux. Il leur permet d’être informés des comptes spécifiques et GPO de leur domaine quiseraient expirés ou désactivés, des groupes ou GPO qui ne respecteraient pas les conventions de nommage.L’utilisation de convention de nommage permet également d’identifier que les groupes d’administrateursne contiennent que des comptes «-loc».

Il est également possible de trouver les machines sans connexion depuis un certain temps, des systèmesd’exploitation obsolètes, ou des machines qui ne serait pas rattachées à l’AD. Il permet aussi d’identifier siles membres des groupes de délégation d’OU sont bien des comptes de la forme login-loc. Les administra-teurs du domaine reçoivent des informations spécifiques comme l’état de réplication des DC.

3.2 Difficultés d’application

Cinq ans de travail en commun depuis la fusion des établissements lorrains ont permis d’harmoniser un cer-tain nombre de procédures informatiques. Néanmoins l’étendue de l’établissement, aussi bien sur le plangéographique que sur la diversité des champs disciplinaires, nécessite une grande souplesse de fonctionne-ment. Il est alors difficile de limiter le nombre d’administrateurs. Sur ce grand nombre de ces derniers, lesbonnes pratiques ne sont pas forcément interprétées ou appliquées à l’identique.

L’audit des autorisations logiques vise également à faire apparaître ces écarts.

4 Outils

Le principal outil utilisé est BTA, distribué depuis 2014 par les équipes sécurité de Airbus[2]. Il s’agit d’unensemble de scripts python qui permettent d’injecter une base AD, sous la forme d’un fichier ntds.dit,dans une base mongoDB. Le fichiers ntds.dit contient toutes les données de l’annuaire, y compris lesmots de passe. Il est alors particulièrement sensible et doit être manipulé avec toutes les précautions quis’imposent.

BTA est initialement destiné aux auditeurs AD pour que l’audit puisse être réalisé sur une machine sûre,totalement déconnectée du réseau. La machine d’audit peut être un linux standard. L’auditeur n’a besoin que


https://bitbucket.org/iwseclabs/bta

des scripts python et des outils de la bibliothèque libesedb qui permet de lire le format Extensible StorageEngine (ESE) du fichier ntds.dit.

Lorsque ntds.dit est importé dans la base mongoDB, l’auditeur peut ensuite consulter cette base à l’aidede «miners» : des scripts python dédiés à chaque recherche. Un ensemble de miners se révèlent très utilespour vérifier immédiatement les comptes disposant d’accès privilégiés, le contenu des groupes sensibles,les comptes abandonnés, les quantités d’erreurs de connexion, ...

Par sécurité les mots de passe ne sont pas exportés par BTA dans la base mongoDB. Cependant l’outilNTDSXtract peut également être utilisé, avec les mêmes outils de la libesedb, pour extraire spécifiquementles hashs des mots de passe.

Pour terminer, les miners actuellement fournis par BTA peuvent difficilement exprimer la complexité denotre structure. Nous avons alors développé notre propre miner, btaminetACE, pour trouver l’intégralitédes graphes de relations d’autorisation. L’affichage utilise un outil publié en 2016 par l’ANSSI : OVALI.

Les travaux en cours visent à détecter les graphes suspects à partir de l’usage d’une base graphe.

5 Méthodologie

Depuis un contrôleur de domaine, un administrateur extrait la base de donnée sous la forme d’un fichierntds.dit ainsi que la base de registre système de ce serveur (SYSTEM) au format REGF (Windows NTRegistry File).

Depuis une console de commande Windows, on lance les commandes suivantes :

ntdsutil

ntdsutil: activate instance ntds

ntdsutil: ifm

ifm: create full C:\Users\dupont44-dom\Desktop\dossier\

ifm: quit

ntdsutil: quit

On obtient l’arborescence suivante :

Dossier

|_Active Directory

| |_ntds.dit

|_registry

|_SECURITY

|_SYSTEM

Il est inutile de recopier la très bonne documentation de BTA mais après l’installation des paquets standardspython-dev et mongodb-server, il suffit d’un simple # pip install bta pour installer l’ensemble desscripts de BTA.

La base ntds.dit est au format ESE. BTA fournit les sources C de la libesedb qui se compile facilement.Le script btaimport peut alors l’utiliser si son chemin d’accès se trouve dans la variable d’environnementLD_LIBRARY_PATH.

La commande btaimport -C ::dbAD ntds.dit permet alors d’extraire la base AD et l’injecter dansune base mongoDB, ici nommée dbAD. Pour notre fichier de 2,2 G qui contient 100000 comptes et 800000groupes, il faut compter trois heures d’importation sur une machine récente. L’export des hashs avec l’outilNTDSXtract s’effectue en un trentaine de minutes.


https://github.com/csababarta/ntdsxtract

https://github.com/yvesago/btaminerACE

5.1 Audit des mots de passe

esedbexport permet d’exporter les tables du fichier ntds.dit dans un simple format texte 3.

# esedbexport -m tables ntds.dit

Le script ./dsusers.py de NTDSXtract utilise alors les tables datatable et link_table ainsi que labase de registre SYSTEM pour extraire les hashs de mots de passe. Depuis windows 2008 server, les hashs demots de passe de l’AD sont chiffrés avec une clé de la base de registre SYSTEM du contrôleur de domaine.

# ./dsusers.py datatable.3 link_table.5 dump --syshive SYSTEM \\

--passwordhashes --pwdformat john --lmoutfile lm.out --ntoutfile nt.out

On peut alors rapidement effectuer trois vérifications :

1. Le fichier lm.out doit être vide. En effet le format de hash LM est très faible est permet de déchiffrertrès rapidement l’intégralité des mots de passe. Ce format est désactivé par défaut depuis Windows 2003server. Un AD correctement configuré doit avoir désactivé ce format depuis longtemps.

2. Notre politique impose que les administrateurs aient des mots de passe différents de leur compte utili-sateur. Le format de hash NT n’utilise pas de salage (salt). Cette donnée variable permet d’empêcher quedeux informations identiques produisent le même hash. Il est alors facile en comparant les hashs de trouverles personnes qui utilisent le même mot de passe.

3. Une troisième vérification peut être effectuée en cherchant à casser par force brute les hashs contenus dansle fichier nt.out avec des outils classiques comme john the riper ou hashcat. Si aucune politique decomplexité des mots de passe n’a été imposée, les mots de passe trop simples seront rapidement trouvés.

5.2 Audit des comptes

L’usage de la base NoSQL mongoDb permet aux «miners» d’afficher très rapidement les résultats desrequêtes. On peut alors utiliser un ensemble de miners pour auditer très rapidement les comptes sen-sibles. La syntaxe générale est «# btaminer -t [type d’affichage] -C ::[base mongo] [nom

du miner] �arguments» Plus de 30 miners sont actuellement disponibles. Le message d’usage de «#btaminer -t ReST -C ::dbAD» en donne la liste. La plupart des miners permettent d’utiliser l’option�help pour obtenir la liste d’arguments.

Voici quelques exemples d’usage de miners :

# btaminer -t ReST -C ::dbAD SDProp --list

La commande ci-dessus permet de générer en quelques secondes l’intégralité des comptes protégés parle mécanisme SDHolder. Ce mécanisme retire les droits hérités et les comptes sont restaurés en cas demodification. Ce droit est automatiquement appliqué aux membres des groupes privilégiés du système et nepeut être retiré que manuellement. C’est alors une protection normale pour les administrateurs du domaine.

Analysis by miner: [SDProp]

===========================

+-----------------------------------------+-------+---------------------+

| cn | type | SID |

+=========================================+=======+=====================+

3. Cette opération est par contre particulièrement longue.


ou encore la quantité d’échecs d’authentification :

$ btaminer -t ReST -C ::dbAD passwords --bad-password-count

5.3 Audit des autorisations

Active Directory permet une granularité très fine des droits ou interdictions de lecture, d’écriture, de sup-pression. Ces droits portent sur un grand nombre d’attributs : contrôle d’accès, de gestion d’éléments en-fants, de gestion de mot de passe, ... Une Access Control Entries (ACE) 4 regroupe un ensemble de droits.Un objet de l’Active Directory est alors géré par un ensemble d’ACEs qui peuvent être héritées, par l’ap-partenance à un groupe, ou spécifiques. Cet ensemble d’ACEs est identifié par un entier unique le nTSecu-rityDescriptor.

Pour auditer les autorisations on aurait pu se contenter des miners de BTA pour visualiser le contenu desgroupes. Cependant notre quantité de groupes donne un résultat tellement volumineux qu’il est difficile d’yrepérer une anomalie, d’autre part le simple contenu de chaque groupe est aisément visible par l’interfacegraphique standard. Nos scripts identifient déjà quotidiennement ces éventuelles incohérences.

Visualiser les nTSecurityDescriptor permet d’être sûr de visualiser l’ensemble des autorisations et surtoutde faire apparaître les cas non standards. En effet, les modifications d’une autorisation modifient l’ACE etdonc le groupe d’autorisations. Si l’identifiant de sécurité de ce nouveau groupe n’existe pas, un nouvelnTSecurityDescriptor est créé.

Nous avons alors réalisé notre propre miner, btaminerACE, pour visualiser ces identifiants de sécurité et lesrelations entre ces groupes d’autorisations.

Notre miner permet de visualiser les ACE pour les objets de types User, Group, Computer 5 ou encore lesGPOs.

Usage: ./btaminerAce.pl -d <dbname> -c <[user|group|computer|gpo]>

options:

--json affichage json pour affichage OVALI

--quad affichage quad pour traitement

--user cn=’nom prenom (DOM)’ que pour les utilisateurs

--user cn=login autre utilisateur

Actuellement sur notre AD, la plupart des utilisateurs importés du ldap utilisent le NTSecurityDescriptor2052. Ce SecurityDescriptor contient 48 ACEs.

Voici un exemple d’ACE simple :

AccessAllowedObject | (16) ADSRightDSReadProp controlAccessRight: \\

User-Account-Restrictions | : | GROUP: Serveurs RAS et IAS

qui signifie : «l’objet GROUP "Serveurs RAS et IAS" peut lire (ADSRightDSReadProp) l’objet "User-Account-Restrictions" qui est un controlAccessRight, identifié par l’AccessMask 16»

Quatre autres exemples (nous vous épargnons les 48 ACEs) :

AccessAllowed | (983551) ADSRightACTRLDSList ,ADSRightDSControlAccess , \\

ADSRightDSCreateChild ,ADSRightDSDeleteChild ,ADSRightDSDeleteTree , \\

4. Identifiée par un AccessMask5. Computer est en réalité un sous groupe de User



ADSRightDSListObject ,ADSRightDSReadProp ,ADSRightDSSelf , \\

ADSRightDSWriteProp , Delete,ReadControl ,StandardsRightsRequired , \\

WriteDAC,WriteOwner : | : | GROUP: Admins du domaine

AccessAllowed | (983551) ADSRightACTRLDSList ,ADSRightDSControlAccess , \\

ADSRightDSCreateChild ,ADSRightDSDeleteChild ,ADSRightDSDeleteTree , \\

ADSRightDSListObject ,ADSRightDSReadProp ,ADSRightDSSelf , \\

ADSRightDSWriteProp ,Delete,ReadControl ,StandardsRightsRequired , \\

WriteDAC,WriteOwner : | : | GROUP: Opérateurs de compte

AccessAllowed | (131072) ReadControl : | : | \\

foreignSecurityPrincipal: Authenticated Users

AccessAllowed | (131220) ADSRightACTRLDSList ,ADSRightDSListObject , \\

ADSRightDSReadProp ,ReadControl : | : | foreignSecurityPrincipal: Self

Sans surprise, le groupe des "Admins du domaine" ou des "Opérateurs de compte" ont tous les droits.

Plus obscur, l’objet lui même (Self) ou les utilisateurs authentifiés de la classe foreignSecurityPrincipal ontcertains droits de lecture. 6

Vérifier l’intégralité de ces droits est difficilement envisageable. Notre miner permet de condenser ces infor-mations en regroupant les autorisations d’écritures. Un affichage au format json permet alors de visualiserles relations grâce à notre version légèrement adaptée d’un outil de l’ANSSI : OVALI

L’intégralité des relations d’autorisations de nos 800000 groupes est alors consultable depuis un navigateurweb (figure 1).

Figure 1 - Graphe de relation des groupes

6. Les paramètres de sécurité avancés d’un compte affichent pour le premier exemple d’ACE : «Lire Restrictions de compte».


https://github.com/yvesago/OVALI

5.3.1 Autorisations utilisateurs

Pour illustrer les possibilités de visualisation de graphe, voici un exemple de graphe simplifié. Il est générépour visualiser quelques utilisateurs et quelques comptes d’administrateurs locaux (-loc). Ce résultat estobtenu par la commande :

./btaminerAce.pl -d dbAD -c user --json \\

-u cn=’Martin CARRE (loc)’ -u cn=’Rémi HUBERT (loc)’ \\

-u cn=’Alain Leadmin (loc)’-u cn=carre8775 \\

-u cn=etudiant5 -u cn=autreuser2 -u cn=prof1861

OVALI fait apparaître les indications lorsque l’on survole les objets ou les liens. L’image ci-dessous (fi-gure 2) condense les informations affichables.

Figure 2 - Graphe administrateurs et utilisateurs

Les «g» verts sont les groupes.

Le gros «g» central est un groupe artificiel "BUILTIN" (qui n’existe pas dans AD) pour faire apparaître legroupement des objets par défaut 7 : les foreignSecurityPrincipal («w» orange) comme Self, System, ... etles groupes par défaut comme "Serveurs RAS et IAS", "Admins du domaine", ... .

Les «S» violets sont les nTSecurityDescriptor : ils permettent de grouper les objets possédants les mêmesACEs.

7. Nous avons actuellement 15 groupes appliqués systématiquement à tous les objets de l’AD


Les «u» bleu sont les users. Un cercle volumineux groupe plusieurs utilisateurs possédants les mêmesACEs. On visualise rapidement le groupe d’utilisateurs possédant les mêmes droits que "Paul Etudiant". Ils’agit des comptes générés du ldap. On voit également le groupe d’administrateurs locaux "Martin CARRE(loc)".

Interprétation du graphe :On voit que le groupe d’utilisateurs "Paul Etudiant" est gérable par le pseudo-groupe BUILTIN et par legroupe "GL_Admin_Alim_Auto" qui a des accès (has_access) et peut écrire (is_writer). Il s’agit de lareprésentation simplifiée des 48 ACLs du nTSecurityDescriptor 2052. Pour connaître le détail de ces accèsil faudra utiliser btaminerAce.pl ou l’interface graphique Windows.

On peut également noter 2 utilisateurs particuliers :

"Alain Leadmin (loc)" : est gérable par le groupe GL_Admin_LHAS. Son nTSecurityDescriptor est alorsdifférent des autres comptes -loc. Cette situation est normale.

L’utilisateur dont le nTSecurityDescriptor est 3103, est le compte carre8775. Nous avons vu qu’il possèdede façon anormale une protection SDHolder alors qu’il devrait respecter le nTSecurityDescriptor 2052.Cette situation est alors anormale.

Nous obtenons ici une confirmation du cas traité par le miner SDProp de BTA. Cependant le graphe faitsystématiquement apparaître tout utilisateur possédant des droits spécifiques non standards. Il faut ensuiteexaminer les raisons de cette anomalie.

On voit aussi apparaître que les comptes "Martin CARRE (loc)" et "Rémi HUBERT (loc)" sont liés auxcomptes d’administration. Ils ont aussi une protection SDHolder. Il s’agit ici aussi d’une situation anor-male.

5.3.2 Autorisations GPO

On peut effectuer la même opération sur les autorisations des stratégies de groupes (GPO). Voici, ci-dessous,le graphe des GPO d’une composante où les nTSecurityDescriptor ont été effacés (figure 3). Ces derniersne sont pas très utiles dans la visualisation du graphe. Ils servent surtout à réaliser les groupements.

Les GPO sont représentées par des «x» bruns. Comme précédemment pour les utilisateurs, les GPOs pos-sédant les même accès ont été groupées dans un cercle volumineux.

Les liens peuvent avoir les valeurs :

— is_member : essentiellement les membres du groupes BUILTIN

— has_member : (sens inverse de is_member) les membres d’un nTSecurityDescriptor

— has_access : accès en lecture

— is_writer : accès en écriture 8

On reconnaît des utilisateurs (bleu) et des groupes (vert) qui ont des accès en lecture (has_access) à certainesGPOs et enfin des machines «m» rouges.

Interprétation du graphe :Le groupe central est le groupe des administrateurs locaux qui possèdent des accès "is_writer" sur toutesles GPOs. Cette situation est normale.

5 GPOs ont des autorisations particulières qui s’appliquent à des groupes, des machines ou des utilisateurs.Ici il n’y a pas d’anomalie manifeste.

Nous pouvons par contre facilement identifier lorsque un administrateur local a créé une GPO sous sonpropre compte au lieu de l’attribuer au groupe des administrateurs locaux comme le veux notre politique degestion. On obtiendrait alors une relation de graphe : u -> is_writer -> x .

8. il y a des propriétés comme ADSRightDSControlAccess dont l’attribution «write» est discutable


Figure 3 - Graphe GPOs

5.3.3 Travaux en cours

L’option �quad génère un fichier où les relations sont représentées sous forme de quadruplet (N-Quads). Ceformat permet d’injecter les données dans une base de données orientée graphe comme Cayley ou Neo4j.Les bases orientées graphe vont permettre d’exécuter des requêtes de recherche SPARQL.

Nous travaillons actuellement à repérer les groupes de relations suspectes.

6 Résultats

Les premiers résultats ont été immédiatement encourageants. Nous avons déjà détecté des oublis de désac-tivations de comptes d’administrateurs locaux après leur départ de l’établissement. De la même façon,un rappel des bonnes pratiques a été fait à ces utilisateurs qui, contrairement aux recommandations, ré-utilisaient le même mot de passe. Nous avons également identifié et fait corriger quelques mots de passe decomptes particuliers où la complexité n’était pas satisfaisante.

Des procédures sont en cours d’écriture pour gérer l’obsolescence des comptes administrateurs locaux etidentifier rapidement les grands nombres de tentatives d’accès échouées par compte. L’examen des auto-risations nous a également permis d’identifier des mauvaises pratiques comme la gestion de GPO par descomptes administrateurs uniques au lieu de l’usage recommandé de groupes d’administrateurs locaux.


7 Conclusion

L’usage d’outils open source nous permet d’auditer de façon autonome, rapide et sûre, notre usage d’ActiveDirectory dans ses versions Windows Server 2008 et 2012 R2. Cette démarche a également mis en lumièreles dérives d’usages d’un outil de nature complexe.

Néanmoins, l’auto-évaluation n’est pas sans danger. Nous ne sommes pas à l’abri d’un biais de confir-mation 9 qui aveuglerait nos recherches. Un audit par une société extérieure, spécialisée dans ce type detravaux, est tout à fait envisageable et permettrait certainement d’améliorer encore nos pratiques.

Bibliographie

[1] ANSSI. Recommandations de sécurité relatives à active directory. 2014. https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_ActiveDirectory_NoteTech.pdf.

[2] Joffrey Czarny Philippe Biondi. Bta : outil open-source d’analyse ad. Actes SSTIC 2014,2014. https://www.sstic.org/media/SSTIC2014/SSTIC-actes/BTA_Analyse_de_la_securite_Active_Directory/SSTIC2014-Article-BTA_Analyse_de_la_securite_Active_Directory-czarny_biondi.pdf.

Téléchargements :

— BTA : https://bitbucket.org/iwseclabs/bta

— OVALI : https://github.com/yvesago/OVALI

— btaminerACE : https://github.com/yvesago/btaminerACE

— NTDSXtract : https://github.com/csababarta/ntdsxtract

9. Le biais de confirmation est la tendance, très commune, à ne rechercher et prendre en considération que les informations quiconfirment les croyances et à ignorer ou sous-estimer l’importance de celles qui les contredisent. Psychomedia


https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_ActiveDirectory_NoteTech.pdf

https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_ActiveDirectory_NoteTech.pdf

https://www.sstic.org/media/SSTIC2014/SSTIC-actes/BTA_Analyse_de_la_securite_Active_Directory/SSTIC2014-Article-BTA_Analyse_de_la_securite_Active_Directory-czarny_biondi.pdf

https://www.sstic.org/media/SSTIC2014/SSTIC-actes/BTA_Analyse_de_la_securite_Active_Directory/SSTIC2014-Article-BTA_Analyse_de_la_securite_Active_Directory-czarny_biondi.pdf

https://bitbucket.org/iwseclabs/bta

https://github.com/yvesago/OVALI


https://github.com/csababarta/ntdsxtract

audit de l'ad : contrôle des bonnes pratiques dans une

Documents