La cybersécurité d’une entreprise passe par bien des sujets différents ! Notre expert Thomas SCHAAL se penche aujourd’hui sur la gestion (et le piège !) des comptes à privilèges dans nos SI.
Aujourd’hui, nous allons parler du piège que peuvent représenter les comptes à privilèges dans la sécurité des entreprises. La première question à laquelle il faut qu’on s’attache à répondre est évidemment « Qu’est-ce qu’un compte à privilèges ? », quels sont les types de comptes que cela comprend, quelles sont les informations auxquelles ils peuvent accéder et évidemment en quoi peuvent-ils représenter un piège ou une problématique dans la sécurité de nos infrastructures informatiques et dans la sécurité de nos entreprises au sens large.
Qu'est-ce qu'un compte à privilèges ?
Différents types de comptes peuvent être des comptes à privilèges. Les plus connus sont les comptes d’administration du domaine. Une fois cela dit, on imagine assez facilement ce qu’est un compte à privilèges. Quand il s’agit du compte administrateur du domaine, c’est un compte qui a le plus haut niveau de droits sur l’infrastructure informatique. Mais il n’est pas seul !
Les comptes à privilèges, ce sont tous les comptes que l'on va retrouver au sein de notre infrastructure informatique, et qui ont des droits suffisants pour qu'ils puissent représenter une menace sur le bon fonctionnement de notre infrastructure.
Ils sont pourtant nécessaires la plupart du temps dans le fonctionnement de nos infrastructures. Revenons donc à nos différents types de comptes.
Le premier, et aussi le plus connu, est donc le compte d’administration du domaine. Nous allons ensuite retrouver le fameux administrateur de notre groupe admin du domaine.
On peut également citer les comptes d’administration des bases de données, qu’elles soient SQL, PostgreSQL, MySQL, etc… Nous allons forcément trouver des comptes qui vont avoir un haut niveau de droits sur ces bases de données, bases de données qui sont souvent critiques puisqu’elles permettent de stocker les données de nos ERP et de nos outils métiers.
On va également retrouver tous les comptes de service, ceux qui servent à démarrer les services applicatifs au sein de nos infrastructures, qui ont eux aussi souvent un très haut niveau de droits.
Enfin, on va retrouver les comptes d’administration locale de nos machines, le comptes administrateur des ordinateurs avant qu’ils soient joints au domaine, et les comptes d’administration des équipements qui sont périphériques à l’infrastructure. On peut parler des caméras, des points d’accès wifi, des pointeuses, des copieurs, des machines à café connectées ou des arrosoirs connectés qui ont systématiquement un compte d’administration et qui ne sont pas toujours suffisamment sécurisés.
Des fois, on se rend compte que les crédenciales par défaut restent mis en
place même après que l’outil ou le produit soient mis en preuve dans
l’infrastructure. Ces comptes qui ont par nature un haut niveau de
privilèges sur le fonctionnement du périphérique concerné peuvent devenir une porte d’entrée pour les pirates au sein de nos infrastructures.
Ces comptes qui sont néanmoins requis, et notre propos n’est pas de dire qu’ils doivent disparaître du jour au lendemain. Au contraire, il faut les maîtriser, car si leur usage est détourné, ils peuvent permettre d’accéder à un certain nombre d’informations qui sont critiques pour l’entreprise.
Quelles sont les informations critiques accessibles via les comptes à haut niveau de privilèges ?
Ces comptes peuvent nous permettre l’accès à toutes les données sensibles de l’entreprise. Et c’est bien en ça qu’on doit s’organiser et s’attacher à les sécuriser de la manière la plus pertinente et la plus cohérente possible.
Dans le détail, on peut parler des bases de données des différents outils, (par exemple les comptes SA de nos bases SQL). Ils vont également nous permettre, par le biais du compte admin du domaine ou du compte admin local des postes de travail, d’accéder à la totalité de l’infrastructure informatique et par rebond à la sauvegarde de notre système d’information et à l’administration de tout l’environnement de nos utilisateurs.
On se rend donc bien compte à quel point ce sont des comptes qui deviennent critiques par nature, parce que leur niveau de droit sur les équipements et sur l’infrastructure, leur confère une très haute importance. Cela ouvre donc une question importante :
En quoi considère-t-on que les comptes à privilèges peuvent être un piège ?
Chez OCI, nous nous rendons comptes que la gestion des comptes à privilèges est un sujet qui revient systématiquement lors des pentests. À chaque fois que nous encadrons un pentesteur, ou que nous produisons nous-même un pentest (donc un « test de pénétration » en français) des défenses des infrastructures informatiques de nos clients, nous nous rendons compte qu’il s’agit systématiquement d’un sujet identifié.
Illustrons cela d’un exemple concret :
Lors du dernier pentest que nous avons managé, sur 27 vulnérabilités identifiées, 8 d'entre elles concernaient des comptes à privilèges.
On se rend donc compte à quel point ce sujet est présent dans nos infrastructures, à quel point il est prédominant et qu’il doit donc être testé dans nos infrastructures informatiques. Ce chiffre de 8 vulnérabilités sur 27 nous permet bien d’imaginer à quel point la compromission de ces comptes est un objectif principal pour les pirates.
En cas d’attaque, un des objectifs rapides du pirate est d’obtenir des droits élevés sur le système d’information pour pouvoir se propager au sein de l’infrastructure. Ils vont donc cibler les comptes à privilèges qui disposent déjà de ces droits. Il est en effet souvent plus simple pour un pirate de corrompre un compte de service qui est administrateur du domaine, dont le mot de passe est écrit en description du compte dans l’Active Directory, que de créer de toutes pièces un compte d’administrateur du domaine qui va lui permettre d’atteindre ses objectifs.
Pour mieux imager cette problématique, prenons deux cas d'étude
🖥️ 1. L'administration locale des postes de travail
Le contexte est celui de l’existence et l’unicité des credencials locaux sur les postes de travail. Globalement, cela veut dire qu’on a un compte administrateur local sur les postes de travail qui est le même sur toutes les machines de notre réseau.
Pourquoi est-ce fait comme ça ? C’est souvent une problématique historique car quand on déployait des images de préparation de nos postes de travail, bien souvent on avait un compte administrateur avec le même mot de passe partout, simple à retenir et simple à utiliser pour les administrateurs. Une fois que le poste est enrôlé dans le domaine Windows, on oublie l’existence de ce compte. Il faut également bien avouer qu’il est bien pratique d’avoir un compte d’administration locale quand notre poste n’a plus été connecté pendant 90 jours au domaine et qu’on se retrouve avec un PC qu’il faut arriver à manager malgré tout.
Pourquoi c’est un problème ? Eh bien si un pirate trouve les credentials locaux d’un poste de travail, ce qui est d’autant plus simple pour le pirate si ce poste est dans une version d’OS obsolète, il faut à peine quelques secondes pour récupérer un mot de passe local. Et leur robustesse est tellement faible que ça devient facile pour les pirates de récupérer la correspondance entre le nom d’utilisateur et le mot de passe !
Si j'arrive à trouver les credentials locaux d'un poste de travail, et que ce sont les mêmes sur tout le réseau, il devient facile de rebondir de poste en poste et d'accéder à des données qui pourraient être critiques au sein de l'infrastructure !
Alors quelles données ? C’est très simple prenons simplement un exemple : certains collaborateurs se déplacent et stockent des données potentiellement confidentielles sur leur bureau, dans leur dossier Mes documents. Grâce à l’accès à un seul poste de travail dans ce contexte-là, il devient facile pour le pirate de se promener de poste en poste et d’accéder potentiellement à ces informations, qui sont d’autant plus critiques quand on sait que nos populations VIP (nos DG, nos DAF) ont plutôt facilement tendance à stocker des informations plutôt confidentielles localement sur leur poste de travail. On se rend compte à quel point cet exemple là est concret et peut avoir des répercussions qui peuvent être extrêmement graves, extrêmement importantes, pour la confidentialité des données.
💾 2. La sauvegarde
Vous avez toutes et tous pour la plupart des infrastructures informatiques qui sont virtualisées avec un ESX avec un HyperV, et cette infrastructure est généralement sauvegardée avec Veeam, mais le fonctionnement est à peu près le même pour tous les outils de sauvegarde des infrastructures virtualisées. C’est l’exemple que nous allons développer.
Quand l’outil va faire la sauvegarde de vos machines virtuelles afin de la rendre la plus cohérente possible, il va mettre en place un traitement applicatif de la machine virtuelle avant de la sauvegarder. Donc si vous avez un Microsoft SQL sur votre VM, si vous avez un Active Directory, si vous avez un PostgreSQL ou autre, l’outil va d’abord traiter le fonctionnement de cette base de données avant de sauvegarder la machine afin que si on soit obligé de faire une restauration, on ait une base de données qui soit cohérente.
Pour appliquer un traitement applicatif sur nos bases de données de quoi a besoin l’outil de sauvegarde ? Il a besoin d’un compte qui a des droits suffisants sur ce process applicatif, pour pouvoir forcer la sauvegarde, le flush des logs ou tout autre traitement applicatif. Historiquement, je retrouve là aussi sur un grand nombre d’infrastructures le fait que le compte qui soit utilisé sur l’ensemble des machines virtuelles soit un compte qui a un niveau de droit d’administrateur du domaine.
Pourquoi est-ce fait comme ça ? Eh bien à nouveau, c’est historique ! Quand on a commencé à sauvegarder des infrastructures virtuelles et que les logiciels de sauvegarde ont été en capacité d’appliquer un traitement applicatif, nous avons tous, par facilité, créé un compte qui avait des droits élevés sur l’infrastructure pour permettre de traiter l’ensemble des machines virtuelles.
Pourquoi est-ce problématique ? Encore une fois, la récupération des crédentials utilisés par le traitement applicatif des sauvegardes pourrait permettre un accès à toute l’infrastructure si tant est que ce compte soit effectivement administrateur du domaine.
Notre exemple reprend exactement ce concept : si on récupère le compte qui est utilisé pour les Guest Processing, qui est souvent administrateur du domaine, on obtient le plus haut niveau d’accès à l’infrastructure.
Ces deux exemples montrent à quel point l’existence de compte à privilèges peut-être un problème pour la sécurité de notre infrastructure face au risque cyber.
Quels sont les risques et les conséquences ?
On va être face à des cas d’exfiltration des données ou de détournement de l’usage de l’infrastructure. Ca va permettre à des pirates d’installer des process de cryptomining, ou d’utiliser votre infrastructure comme un rebond pour en atteindre une autre. Ca va évidemment permettre le contrôle et le chiffrement complets de toute l’infrastructure par le biais d’un cryptovirus, si on l’exécute avec le plus haut niveau de droits sur l’infrastructure. On se rend bien compte à quel point il va pouvoir se déployer de la manière la plus large possible.
Et quelles vont être les conséquences ? Un arrêt de production, la paralysie de l’entreprise, des pertes financières, un impact sur la réputation de l’entreprise… Ce sont des choses qu’on a déjà abordées un certain nombre de fois sur nos présentations précédentes, et qui sont malheureusement toujours d’actualité et qui le sont d’autant plus quand le piratage s’exécute avec un haut niveau de droits sur l’infrastructure par le biais d’un compte à privilèges à droits élevés.
Quelles sont les solutions à mettre en place pour améliorer la sécurisation de ces comptes à privilèges ?
Déjà, le débat n’est pas de dire si on peut se passer des comptes à privilèges ou si on devrait s’en passer : on sait que nos logiciels doivent avoir des comptes pour pouvoir s’exécuter, on sait que nos bases de données doivent être administrées, on sait que nos postes de travail doivent être administrés, on sait que nos pointeuses doivent être administrées… donc on sait qu’on aura toujours besoin de comptes qui nous permettent ce niveau d’administration.
📑 1. L'inventaire détaillé des comptes à privilèges
Il faut néanmoins arriver à sécuriser les comptes à privilèges, et la première stratégie autour de cette sécurisation est celle de l’inventaire. On se rend compte que le drame, ce sont les comptes oubliés. Donc l’idée c’est vraiment d’aller réaliser un inventaire détaillé dans notre activité, sur nos postes de travail, sur nos logiciels, sur nos périphériques qui sont eux-mêmes périphériques à l’infrastructure, de tous les comptes à privilège de l’entreprise.
Les plus problématiques étant, je le répète, ceux qu’on a oublié, ceux qui ont été créés il y a des années et dont le mot de passe n’a jamais été changé, dont le niveau de droits n’a jamais été revu, et dont on finit par oublier jusqu’à l’existence, et qui un jour sont utilisés dans un contexte de piratage.
↘️ 2. Réduire l'empreinte des comptes à privilèges au strict minimum
Un des autres travaux prioritaires va être de réduire l’empreinte de ces comptes, de réduire leur capacité au strict minimum par de la segmentation, ou par des outils tiers que seraient LAPS ou GMSA. L’idée c’est qu’on compte qui va démarrer une base de données n’a peut-être pas besoin d’être administrateur du domaine : peut-être qu’on va juste pouvoir le rendre administrateur local de la machine sur laquelle il doit démarrer la base de données ; peut-être même qu’un compte utilisateur serait suffisant ! C’est l’inventaire précédent qui va nous permettre de travailler sur les droits de chaque compte, pour pouvoir les réduire au minimum.
🔒 3. Renforcer l'authentification aux comptes à privilèges
Pourtant, il faut bien un compte administrateur du domaine pour lequel nous n’allons pas pouvoir réduire les droits d’administration ! Dans ce cas, on va renforcer le processus d’authentification, avec par exemple la mise en place de l’authentification multifacteurs pour les comptes à privilège qui sont utilisés par des humains. Je m’authentifie sur une machine virtuelle avec un compte administrateur du domaine, et je dois à l’aide de mon smartphone valider l’authentification. Il s’agit d’un outil simple qui peut nous permettre de renforcer la robustesse de ses comptes et d’éviter qu’ils soient utilisés par des tiers.
💬 4. Sensibiliser les opérateurs & administrateurs amenés à manipuler les comptes à privilèges
Ce process de renforcement l’authentification va de paire avec la sensibilisation des opérateurs ou des administrateurs qui sont amenés à manipuler ces comptes à privilèges. On a évidemment en tête les administrateurs du domaine qui travaillent au sein de l’entreprise, l’équipe IT, l’équipe de la DSI, qui vont intervenir sur les machines ; mais n’oublions pas tous nos partenaires applicatifs à qui, à un moment ou un autre, on a donné des droits au sein de l’infrastructure pour administrer tel ou tel logiciel, solution de vidéosurveillance, outil de gestion du temps ou de gestion des alarmes, etc… et à qui il est possible qu’on ait créé des comptes qui bénéficient d’un haut niveau de privilèges. On a peut-être tendance à les oublier, mais on doit à nouveau traiter la sensibilisation de ces opérateurs dont l’administration des infrastructures informatiques n’est pas toujours le métier.
🔎 5. Surveiller les comptes à privilèges
Dernière mesure de gouvernance à mettre en place, et qui nous semble extrêmement importante, c’est cette notion de surveillance ! On sait qu’on ne peut pas abandonner l’usage de compte à privilèges, mais pour autant on peut en surveiller l’usage. En effet et si on se rend compte par exemple qu’un compte de service est utilisé pour tenter d’ouvrir une session interactive sur un serveur ou un poste de travail, nos outils de supervision ou d’alerting doivent se rendre compte de ce détournement de l’usage et alerter afin que l’on puisse faire une levée de doute autour de l’utilisation, ou du détournement de l’utilisation, d’un compte à privilèges qui aurait été créé pour un usage et qui est utilisé pour un autre. Cette surveillance et cet alerting vont nous permettre de pouvoir déterminer extrêmement rapidement qu’on fait potentiellement face au détournement de l’utilisation d’un compte à privilèges.
Donc ces solutions, qui sont extrêmement globales en cybersécurité, concernent une stratégie de gouvernance et ont un sens sur toutes nos infrastructures, dans toutes nos entreprises !
Ces solutions ne répondent de toute évidence pas aux deux cas de figure que je viens d’évoquer, pas complètement en tout cas, mais elles s’inscrivent néanmoins dans une stratégie de réponse. On va pouvoir renforcer cette stratégie de gouvernance par des actions qui sont plutôt des solutions techniques, ou technologiques.
Faisons un zoom sur 2 solutions techniques prioritaires
🔑 Microsoft LAPS
Pour rappel, notre premier cas d’étude était au tour de l’administration locale des postes de travail. Le constat étant qu’on se retrouve avec des infrastructures où on a un même compte administrateur qui a le même mot de passe d’administration locale sur les postes de travail.
Microsoft a bien pris en compte cette problématique et a sorti un produit qui s’appelle « LAPS« , pour Local Admin Password Solution, qui est une solution qui permet de mettre en place une rotation et une randomisation des mots de passe d’administrateur locaux des machines qui exploitent la solution. Ceci est valable pour l’ensemble des postes de travail, mais aussi pour l’ensemble des serveurs de nos infrastructures, qui eux aussi la plupart du temps ont un compte d’administration locale avant d’être intégrés dans le domaine.
Donc Microsoft LAPS va randomiser le mot de passe administrateur local, mettre en place une stratégie de rotation et des contraintes de complexité autour de ce mot de passe, et une fois que c’est fait, il va faire remonter l’information dans un attribut du poste de travail concerné dans l’Active Directory, qui ne sera lisible que par les administrateurs du domaine par exemple. Donc quand un administrateur va devoir administrer un poste de travail en utilisant un compte d’administration locale, il va d’abord ouvrir les attributs de l’objet concerné dans l’Active Directory pour récupérer le mot de passe, qui peut d’ailleurs être à usage unique, va faire son travail et quand il aura terminé cliquera sur « Régénérer » et le mot de passe va changer et l’attribut sera mis à jour dans l’AD. Donc par ce biais là, on traite la question de l’unicité des comptes d’administration locale sur nos infrastructures informatiques.
🔓 GMSA
Le deuxième cas d’étude était autour de la sauvegarde et notamment du traitement applicatif de nos machines virtuelles pendant le process de sauvegarde. Là encore une fois Microsoft à bien compris que la problématique des comptes à privilèges sur l’applicatif était à prendre en compte, et ils ont là aussi sorti un produit, disponible à partir de Windows 2012 R2, qui s’appelle « GMSA« , comme Group Managed Services Accounts.
Il s’agit d’un type d’utilisateur de l’Active Directory Microsoft qui a la particularité de ne pas avoir de mot de passe. On ne peut donc pas le pirater, mais son usage est restreint à une tâche précise. Par exemple, et c’est d’ailleurs pour ça que ça a été créé initialement, démarrer un service ou lancer une tâche planifiée. Du coup, plus besoin de créer des comptes à haut niveau de privilèges sur l’ensemble de l’infrastructure pour simplement démarrer par exemple Microsoft SQL ou le service applicatif de Sage, etc… On crée un GMSA qui ne va pouvoir être utilisé que pour cette tâche là, et donc notre GMSA ne pourra pas être utilisé pour ouvrir une session interactive sur un serveur ou un poste de travail, ni même pour ouvrir une session réseau. Donc si le compte pouvait être détourné de son usage premier, il ne permettrait pas à un pirate d’être utilisé pour se propager et se promener sur au sein de l’infrastructure.
On peut tirer avantage de cette solution sur la configuration du Guest Processing de notre outil de sauvegarde. Bien sûr, c’est un peu plus compliqué que de juste mettre un compte administrateur du domaine pour l’ensemble des VM. On va devoir créer un GMSA par VM, pour pouvoir faire en sorte que Veeam Backup, dans notre exemple, puisse gérer toute la partie applicative sur chaque VM avant de démarrer le process de sauvegarde. Ainsi on ne donnera plus un compte avec un haut niveau de privilèges du domaine, mais pour chaque VM un compte dédié à l’usage du Guest Processing, dont on n’a plus besoin de gérer de rotation de mot de passe pour qu’il reste sécurisé au fil du temps.
♾️ Bonus : la rotation de mot de passe !
Malgré tout, la rotation des mots de passe reste un sujet extrêmement important pour nos administrateurs humains. Rappelez-vous que même si on peut mettre en place de l’authentification multifacteurs quand ils vont démarrer une session, pour autant on va quand même les enjoindre à changer leur mot de passe de la manière la plus régulière possible. On va d’ailleurs exiger de nos administrateurs du domaine qu’ils aient un niveau de complexité dans leur mot de passe qui soit potentiellement plus élevé que les comptes de nos utilisateurs standards au sein du domaine Active Directory.
Pour cela, on peut mettre en place une PSO, donc une Password Setting Object, qui va différencier les stratégies de mot de passe au sein de notre Active Directory. Dans les grandes lignes, quand on fait un audit de notre AD aujourd’hui en 2023, on ne devrait plus retrouver des comptes à haut niveau de privilèges dont l’attribut Last Password Change dans l’AD dépasse l’année en cours. Et on se rend bien compte qu’aujourd’hui que c’est un sujet extrêmement important, car l’orsqu’on réalise des audits AD, on retrouve encore des comptes admin du domaine dont l’attribut Last Password Change dépasse les 8 ans. On se rend donc bien compte que ça c’est typiquement un compte oublié / abandonné et qui pourrait être utilisé dans un contexte de piratage.
En résumé
En résumé, la gestion des comptes à privilèges est un sujet qui est technologique on l’a vu, avec la réponse autour de LAPS, GMSA et de la rotation de mot de passe, mais c’est surtout un sujet de gouvernance, et je reviens là sur l’inventaire exhaustif de nos comptes à privilèges, de leur usage, de leur portée, de leur date de péremption.
Nous devons y consacrer un point dédié lors des comités de pilotage de la cybersécurité, et ce de manière récurrent, car ce sont des sujets extrêmement changeants, et avec de plus en plus de partenaires extérieurs qui demandent des accès à des comptes à haut niveau de privilèges.
On va donc potentiellement pouvoir créer des comptes juste pour un usage défini, mais ne les oublions pas et ne les abandonnent pas ! C’est en ça que traiter le sujet des comptes à privilèges au cours d’un COPIL va nous permettre de remettre du temps et de la mémoire sur le sujet.
FAQ
L’usage d’un bastion ne répond pas à l’ensemble de la problématique, mais vient en complément d’une stratégie de protection des comptes à privilèges. Le bastion va être utilisé pour nos partenaires applicatifs et pour nos administrateurs locaux. Mais pour autant, cela n’enlève en rien l’importance de la gestion des comptes à privilèges pour les process automatisés par exemple. Le bastion vient donc compléter cette protection, et nous avons évidemment tendance à penser que c’est un outil nécessaire.
Cette question ouvre le sujet de la segmentation, voire du tiering, des comptes administrateurs ou des comptes à privilèges. Effectivement, dans un contexte de mise en place de tiering sur les comptes, on va créer un compte d’administration (on parle ici des administrateurs physiques) pour chaque personne : un compte d’administration des postes de travail, un compte d’administration des serveurs, un compte d’administration des contrôleurs de domaine, et potentiellement un compte utilisateur pour simplement se connecter à l’infrastructure. Dans ce contexte-là, effectivement, un opérateur d’administration peut se retrouver avec un grand nombre de comptes d’administration pour gérer son travail au quotidien. Certes, cela complexifie la gestion et la connexion au sein de l’infrastructure, mais pour autant, on le sait tous, la cybersécurité ne rime pas avec confort ! Aujourd’hui, nous n’avons plus le choix de mettre en place ces process-là, et les entreprises qui font le choix du tiering font un grand pas vers une stratégie de sécurité qui est extrêmement robuste. Les administrateurs peuvent de toute évidence utiliser un gestionnaire de mots de passe, qui va leur permettre de mieux gérer leurs accès.
Il existe des outils qui vont permettre de nous aider sur l’inventaire des comptes à privilèges. Premièrement, on peut parler des outils comme PingCastle qui permettent de réaliser un état des lieux de la configuration de notre activité, et justement de dresser un inventaire des comptes qui n’auraient pas changé leur mot de passe sur un certain laps de temps, ou qui n’auraient pas des caractéristiques de robustesse suffisamment élevées. Cet outil permet donc de dresser un inventaire côté Active Directory, mais vous l’aurez compris, ce n’est pas suffisant. Certains équipements (par exemple les pointeuses, les copieurs, les machines à café connectées, etc…) vont devoir être adressés par un inventaire poste par poste, outils par outil, périphérique par périphérique. On va ensuite pourvoir augmenter le niveau et le nombre de logs de nos annuaires comme l’Active Directory, pour justement pouvoir voir quels sont les comptes qui s’y connectent, afin là aussi d’avoir une aide sur l’inventaire de ces sujets-là. Mais il n’y a pas d’outil magique qui va permettre d’adresser l’ensemble de l’infrastructure.
LAPS et GMSA sont des outils qui sont inclus dans les solutions Microsoft. Elles sont donc « gratuites« , mais leur déploiement, leur mise en oeuvre et leur suivi coûtera à minima du temps, de l’organisation et de la communication. Mais l’outil en tant que tel n’est pas facturé par Microsoft, il fait partie intégrante de Microsoft Active Directory.
