Audit de l AD : Contrôle des bonnes pratiques dans une université de grande taille avec des outils Open Source.

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

taille avec des outils Open Source.

Yves Agostini

RSSI - Université de Lorraine 34 Cours Léopold

54 000 Nancy

Camille Herry

Administrateur Active Directory UL Campus ARTEM - BP 14234 54 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 ou d’applications en font un service critique pour un établissement. Cependant, ses nombreuses fonctionnalités sont complexes à maîtriser et il n’existe pas d’interfaces pour s’assurer de la cohérence de l’ensemble des paramètres. Il faut alors régulièrement vérifier que des erreurs de manipulations n’aient pas compromis la sé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 sources nous permet d’être sûr de leur fonctionnement. Les principaux outils que nous avons utilisés proviennent de 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 sources, nous ont permis de gérer le contexte particulier des établissement universitaires. En effet, contrairement à l’industrie, la gestion des parcs informatiques universitaires 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 permis d’avoir une première vision de l’état de notre système et de corriger rapidement un certain nombre de faiblesses et de mauvaises pratiques involontaires.

Mots clefs

Active Directory, AD, Audit, BTA, Sécurité, Open source

1 Introduction

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

harmoniser les pratiques des anciens établissements. Après cinq ans de déploiement et de fonctionnement, notre système gère actuellement 106000 comptes¹, 800000 groupes et 15000 machines, répartis sur 18 contrô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 pas d’une expertise absolue. Cet article va présenter notre démarche pour auditer nous même notre Active Directory à l’aide d’outilsopen source. Ces outils, facilement disponibles et dont l’accès aux codes sources nous permet d’être sûr de leur fonctionnement, nous ont permis d’avoir une première vision de l’état de notre systè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 postes utilisateurs 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’une architectureActive 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, lesDomains Controllers(DC), qui sont interrogés par les clients pour vérifier les autorisations d’accès et récupérer les informations 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 être spé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 volume d’information important. De plus, les interfaces de gestion fournies par l’interface graphique des systèmes Windows permettent essentiellement une consultation manuelle qui s’avère longue et répétitive. À plus ou moins long terme, des erreurs de gestion vont créer des objets avec des autorisations excessives et donc potentiellement 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 de disposer sur tous les sites d’un accès performant aux serveurs de l’Active Directory. Cela permet de limiter le nombre de serveurs et de domaines et d’éviter les problématiques d’intégration de forêts (intégration inter-domaines).

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

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². L’accès aux contrôleurs de domaine est alors 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és

2. Techniquement cette base ce situe sur tous les contrôleurs de domaine est peut être exporté sous la forme d’un fichierntds.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é et défini un certain nombre. Par exemple l’abandon du protocole de chiffrement obsolète LM mais surtout la définition de plusieurs conventions de nommage pour faciliter la visualisation et la gestion des éléments de l’AD. Ces conventions portent sur les identifiants de compte, les entités (OU), les groupes et les stratégies de 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 ou exceptionnellement 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 aux DC.

Les niveaux 2 et 3 sont des comptes spécifiques qui doivent être différents du compte utilisateur géré par le système d’information. À cet effet, les administrateurs locaux disposent d’un compte supplémentaire sous la formelogin-loc, les administrateurs de domaine ont également un compte spécifique sous la forme login-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 qui seraient 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’administrateurs ne contiennent que des comptes «-loc».

Il est également possible de trouver les machines sans connexion depuis un certain temps, des systèmes d’exploitation obsolètes, ou des machines qui ne serait pas rattachées à l’AD. Il permet aussi d’identifier si les 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 plan gé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 d’administrateurs les bonnes 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é estBTA, distribué depuis 2014 par les équipes sécurité de Airbus[2]. Il s’agit d’un ensemble de scripts python qui permettent d’injecter une base AD, sous la forme d’un fichierntds.dit, dans une base mongoDB. Le fichiersntds.ditcontient toutes les données de l’annuaire, y compris les mots de passe. Il est alors particulièrement sensible et doit être manipulé avec toutes les précautions qui s’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

des scripts python et des outils de la bibliothèquelibesedbqui permet de lire le formatExtensible Storage Engine(ESE) du fichier ntds.dit.

Lorsquentds.ditest importé dans la base mongoDB, l’auditeur peut ensuite consulter cette base à l’aide de «miners» : des scripts python dédiés à chaque recherche. Un ensemble de miners se révèlent très utiles pour 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’outil NTDSXtractpeut également être utilisé, avec les mêmes outils de la libesedb, pour extraire spécifiquement les hashs des mots de passe.

Pour terminer, les miners actuellement fournis par BTA peuvent difficilement exprimer la complexité de notre 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 fichier ntds.ditainsi que la base de registre système de ce serveur (SYSTEM) au format REGF (Windows NT Registry 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 standards python-dev et mongodb-server, il suffit d’un simple # pip install btapour installer l’ensemble des scripts de BTA.

La base ntds.dit est au format ESE. BTA fournit les sources C de la libesedb qui se compile facilement.

Le scriptbtaimportpeut alors l’utiliser si son chemin d’accès se trouve dans la variable d’environnement LD_LIBRARY_PATH.

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

5.1 Audit des mots de passe

esedbexportpermet d’exporter les tables du fichier ntds.dit dans un simple format texte³.

# esedbexport -m tables ntds . dit

Le script./dsusers.pydeNTDSXtractutilise alors les tablesdatatableetlink_table ainsi que la base de registreSYSTEMpour extraire les hash de mots de passe. Depuis windows 2008 server, les hashs de mots 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 fichierlm.outdoit être vide. En effet le format de hash LM est très faible est permet de déchiffrer très rapidement l’intégralité des mots de passe. Ce format est désactivé par défaut depuis Windows 2003 server. 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 que deux informations identiques produisent le même hash. Il est alors facile en comparant les hashs de trouver les 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 dans le fichiernt.outavec des outils classiques commejohn the riperouhashcat. Si aucune politique de complexité 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 des requê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 helppour 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 par le mécanismeSDHolder. Ce mécanisme retire les droits hérités et les comptes sont restaurés en cas de modification. Ce droit est automatiquement appliqué aux membres des groupes privilégiés du système et ne peut ê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.

| Administrateurs | Group | S -1 -5 -32 -544 |

| Administrateurs de l ’ entreprise | Group | S -1 -5 -21 -... -519 |

| Administrateurs du sch é ma | Group | S -1 -5 -21 -... -518 |

| Admins du domaine | Group | S -1 -5 -21 -... -512 |

| Contr ô leurs de domaine | Group | S -1 -5 -21 -... -516 |

| Contr ô leurs de domaine en lecture seule | Group | S -1 -5 -21 -... -521 |

| Duplicateurs | Group | S -1 -5 -32 -552 |

| Op é rateurs de compte | Group | S -1 -5 -32 -548 |

| Op é rateurs de sauvegarde | Group | S -1 -5 -32 -551 |

| Op é rateurs de serveur | Group | S -1 -5 -32 -549 |

| Op é rateurs d ’ impression | Group | S -1 -5 -32 -550 |

| Administrateur | User | S -1 -5 -21 -... -500 |

| Elsa DUPONT ( dom ) | User | S -1 -5 -21 -... -13086 |

| Eric RICE ( dom ) | User | S -1 -5 -21 -... -17697 |

| rice4455 - loc | User | S -1 -5 -21 -... -100117 | <=1

| Martin CARRE ( dom ) | User | S -1 -5 -21 -... -13866 |

| Martin CARRE ( loc ) | User | S -1 -5 -21 -... -19598 | <=1

| carre8775 | User | S -1 -5 -21 -... -8173 | <=2

| Marc LEROY ( dom ) | User | S -1 -5 -21 -... -19108 |

| krbtgt | User | S -1 -5 -21 -... -502 |

| Cl é ment BOUCHET ( dom ) | User | S -1 -5 -21 -... -13872 |

| Ré mi HUBERT ( loc ) | User | S -1 -5 -21 -... -19600 | <=1

| MEEAV Prj | User | S -1 -5 -21 -... -123613 | <=3 +---+---+---+

Grâce à notre convention de nommage, on voit rapidement que des comptes «loc» (1) et même un simple compte utilisateur (2) ont été inclus à des groupes privilégiés. Ce qui est contraire à notre politique. On doit également examiner si le compte du projet MEEAV (3) a réellement besoin d’un accès privilégié.

On peut ensuite examiner les membres des groupes privilégiés comme par exemple les administrateurs du domaine :

$ btaminer -t ReST -C :: dbAD ListGroup -- match " Admins du domaine "

ou trouver les groupes d’un compte particulier :

$ btaminer -t ReST -C :: dbAD Membership -- match " MEEAV Prj "

Analysis by miner : [ Membership ]

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

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

| MEEAV Prj (s -1 -5 -21... -1213) | MEEAV Prj | MEEAV , Utilisateurs du domaine | +---+--- ---+---+

Ici, le compte du projet MEEAV, ne faisant pas parti d’un groupe privilégié, ne semble pas avoir de raison valable pour bénéficier de la protection SDHolder. Cette protection est alorsanormale.

D’autres miners permettent d’obtenir la liste des comptes non utilisés depuis un certain nombre de jours (ici 365) :

$ btaminer -t ReST -C :: dbAD passwords --last - logon 365

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, ... UneAccess Control Entries(ACE)⁴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 lenTSecu- rityDescriptor.

Pour auditer les autorisations on aurait pu se contenter des miners de BTA pour visualiser le contenu des groupes. Cependant notre quantité de groupes donne un résultat tellement volumineux qu’il est difficile d’y repérer une anomalie, d’autre part le simple contenu de chaque groupe est aisément visible par l’interface graphique 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 surtout de faire apparaître les cas non standards. En effet, les modifications d’une autorisation modifient l’ACE et donc le groupe d’autorisations. Si l’identifiant de sécurité de ce nouveau groupe n’existe pas, un nouvel nTSecurityDescriptor est créé.

Nous avons alors créé notre propre miner,btaminerACE, pour visualiser ces identifiants de sécurité et les relations entre ces groupes d’autorisations.

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

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 NTSecurityDescriptor 2052. 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 unAccessMask

5. 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 ont certains droits de lecture.

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 visualiser les 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 navigateur web (figure 1).

Figure 1 - Graphe de relation des groupes

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 est obtenu 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 le groupement des objets par défaut⁶: les foreignSecurityPrincipal («w» orange) comme Self, System, ... et les 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êmes ACEs.

6. 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êmes ACEs. On visualise rapidement le groupe d’utilisateurs possédant les mêmes droits que "Paul Etudiant". Il s’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 le groupe "GL_Admin_Alim_Auto" qui a des accès (has_access) et peut écrire (is_writer). Il s’agit de la représentation simplifiée des 48 ACLs du nTSecurityDescriptor 2052. Pour connaître le détail de ces accès il faudra utiliserbtaminerAce.plou 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 alors différent des autres comptes -loc. Cette situation estnormale.

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

Cette situation est alorsanormale.

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

On voit aussi apparaître que les comptes "Martin CARRE (loc)" et "Rémi HUBERT (loc)" sont liés aux comptes d’administration. Ils ont aussi une protection SDHolder. Il s’agit ici aussi d’une situationanor- 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 derniers ne 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⁷

On reconnaît des utilisateurs (bleu) et des groupes (vert) qui ont des accès en lecture (has_access) à certaines GPOs 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 toutes les GPOs. Cette situation estnormale.

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 son propre compte au lieu de l’attribuer au groupe des administrateurs locaux comme le veux notre politique de gestion. On obtiendrait alors une relation de graphe :u -> is_writer -> x .

7. 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’optionquadgénère un fichier où les relations sont représentées sous forme de quadruplet (N-Quads). Ce format 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 suspects.

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 aux administrateurs locaux qui, contrairement aux recommandations, ré-utilisaient leur mot de passe d’utilisateur. Nous avons également trouvé quelques mots de passe trop faibles.

Des procédures sont en cours d’écriture pour gérer l’obsolescence des comptes administrateurs locaux et identifier 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 des comptes administrateurs uniques au lieu de l’usage recommandé de groupes d’administrateurs locaux.

7 Conclusion

L’usage d’outilsopen sourcenous permet d’auditer de façon autonome, rapide et sûre, notre usage d’Active Directory dans ses versions Windows Server 2008 et 2012 R2. Cette démarche a également mis en lumière les 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’unbiais de confir- mation, où nous ne ferrions que confirmer les résultats attendus et aveuglerait nos recherches. Un audit par une société extérieure, spécialisée dans ce type de travaux, 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