[PDF] Audit de lAD : Contrôle des bonnes pratiques dans une université

View - Download Audit de lAD : Contrôle des bonnes pratiques dans une université

Previous PDF

Next PDF

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

54000 Nancy

Camille Herry

Administrateur Active Directory UL

Campus ARTEM - BP 14234

54042 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

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 eet, 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é àJRES 2017 - Nantes1/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 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

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 sut pas de veiller à la validité des authentifications. Il faut

également examiner régulièrement les autorisations eectives.

3 Risques et bonnes pratiques

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 chiré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 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.JRES 2017 - Nantes2/12

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 chirement 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 ni veau1 correspond aux comptes utilisateurs synchronisés depuis le système d"information ou

exceptionnellement créés temporairement localement,

le ni veau2 correspond aux administrateurs locaux (Délég ationde droits aux équipes de proximité) :

il permet de gérer les machines, comptes, groupes et stratégies d"une unité organisationnelle (OU),

le ni veau3 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 diérents du compte utilisateur géré par le

système d"information. À cet eet, 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 dicile 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 queJRES 2017 - Nantes3/12

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 dicilement 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"achage 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 sut 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"eectue en un trentaine de minutes.JRES 2017 - Nantes4/12

5.1 Audit des mots de passe

esedbexportpermet d"exporter les tables du fichier ntds.dit dans un simple format texte3.# esedbexport -m tables ntds.dit

Le script./dsusers.pydeNTDSXtractutilise alors les tablesdatatableetlink_tableainsi 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 chiré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 eectuer trois vérifications :

1. Le fichierlm.outdoit être vide. En eet le format de hash LM est très faible est permet de déchirer

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 dié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. 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"acher 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.

JRES 2017 - Nantes5/12

| 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

JRES 2017 - Nantes6/12

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)4regroupe 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 dicile 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 eet, 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,

btaminerA CE , 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

5ou encore les

GPOs.Usage: ./btaminerAce.pl -d -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 UserJRES 2017 - Nantes7/12

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 dicilement envisageable. Notre miner permet de condenser ces infor-

mations en regroupant les autorisations d"écritures. Un achage au format json permet alors de visualiser

les relations grâce à notre version légèrement adaptée d"un outil de l"ANSSI :

O VALI

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

JRES 2017 - Nantes8/12

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 achables.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

6: 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

JRES 2017 - Nantes9/12

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

quotesdbs_dbs9.pdfusesText_15

[PDF] cours active directory ppt

[PDF] installation et configuration windows server 2012 pdf

[PDF] guide de ladministrateur windows server 2012 pdf

[PDF] toutes les formules excel 2007

[PDF] astuces excel 2007 pdf

[PDF] excel astuces formules

[PDF] excel astuces avancées

[PDF] les formules de calculs et fonctions dexcel pdf

[PDF] 85 astuces pour microsoft excel pdf

[PDF] tout sur excel pdf

[PDF] astuces excel avancé

[PDF] facebook pour les nuls 2017

[PDF] comment utiliser facebook en français

[PDF] facebook mode emploi gratuit

[PDF] facebook guide d utilisation