Les services AD LDS (Active Directory Lightweight Directory Services), disponibles depuis Windows Server 2008 R2, offrent la capacité à mettre en œuvre des services LDAP v3 standards, à moindre effort dirions-nous.
Cet annuaire allégé est utilisable par les applications bâties pour dialoguer avec les services d’annuaire LDAP.
Les composants
Les composants à AD LDS assurent le rôle de fournisseur de services d’identité pour répondre à différents scénarios possibles. L’idée de départ reste un concept architectural pour distinguer des identités particulières de celles de l’entreprise.
Donc, sur le plan fonctionnel et technique, vous pouvez clairement choisir quels attributs sont à synchroniser depuis l’Active Directory de votre entreprise vers des serveur LDAP tiers.
C’est très intéressant !
Compatibilité
AD LDS pour nous est une forme d’implémentation sympathique de l’annuaire dans la mesure où il est compatible by design avec de nombreuses briques, comme AD FS ou AzMan.
Dans le cadre de ce style de cohabitation, vous n’auriez pas forcément à exposer directement l’entièreté de votre annuaire Active Directory, cela a du sens sur le plan sécuritaire, tout en laissant la possibilité d’appeler les service Active Directory pour authentifier les utilisateurs qui bénéficient du mécanisme d’authentification Windows.
Installation et normalisation
L’implémentation AD LDS est d’une facilité déconcertante et offre de nombreux avantages :
- Utilisation des mêmes technologies que celle d’Active Directory (Active Directory Domain Services),
- Installation et suppression à chaud du service AD LDS ne nécessitant aucun redémarrage,
- Possibilité de faire cohabiter plusieurs instances sur une même plateforme, dans laquelle la personnalisation est évidement de mise (des schémas différents entre les différentes instances, des ports d’accès distincts, différences possibles entre les schémas AD DS sources et AD LDS). C’est ce qui distingue nettement AD LDS d’ADAM (Active Directory Application Mode),
- Capacité à prendre en compte l’injection de fichier LDIF,
- Sauvegarde et restauration avec les outils classiques de Windows Server,
- Réponses adaptées face aux complexités de séparation des annuaires aux applications,
- Compatibilité avec le système de nommage X.500, avec le style de syntaxe comme suit : [X500:/C=CountryCode/O=Organization/OU=OrganizationUnit/CN=CommonName],
- Utilisation de la couche sécurité Windows pour le contrôle d’accès.
Bien que les deux solutions AD DS et AD LDS partagent les mêmes technologies, AD DS doit rester orienté services d’infrastructure selon nous, tandis qu’AD LDS peut rester une couche fonctionnelle ou applicative.
Le déploiement d’AD LDS peut se faire par ligne de commande (Add-WindowsFeature ADLDS, RSAT-ADLDS) ou par mode graphique (Server Manager -> Manage -> Add Roles and Features -> Next -> Rôle-based or feature-based installation -> Next -> Next -> Active Directory > Lightweigh Directory Services -> Next -> Next -> Next -> Install).
Point d’attention
Du fait de la normalisation exprimée ci-dessus, il découle quelques points d’attention importants dans l’implémentation :
- Bien que la cohabitation technique entre AD LDS et AD DS sur une même plateforme est faisable (à condition de personnaliser les ports d’écoute), nous ne recommandons absolument pas ce type d’implémentation,
- L’instance AD LDS peut être basée sur une machine jointe au domaine ou non. Cependant, la jonction au domaine reste le mode permettant une synchronisation avec une partition d’annuaire Active Directory (à l’aide de l’utilitaire ADAMSync),
- La structure de sécurité, au sens objets utilisateurs et groupes, devra rester à la charge des services d’infrastructure Active Directory,
- AD LDS n’a aucune adhérence avec les notions fondamentales Active Directory (Catalogue Global [GC], stratégie de groupes [GPo], fonctions relatives aux domaines et forêts). Donc, c’est vraiment un annuaire applicatif.
Configuration
Une fois les composants AD LDS installés, vous avez la possibilité d’installer la première instance, cf. menu « Installation d’une nouvelle instance AD LDS »
Les quelques étapes qui suivent sont vraiment intuitives. Une fois les paramètres validés, il vous faut valider l’emplacement des fichiers :
- *.dit : fichiers de données
- *.log : fichier de transaction
L’emplacement par défaut est dans le dossier « C:\Program Files\Microsoft ADAM\Instance1\data », mais il est tout à fait personnalisable.
La dernière étape pour une instance donnée consiste à définir le schéma d’annuaire par rapport aux besoins fonctionnels. Cette phase se fait par l’importation de fichiers LDIF.
Quelques exemples sont à disposition à la base. Par conséquent, il n’est pas forcément nécessaire d’importer tous les fichiers LDIF.
Une fois le schéma préparé, vous pouvez maintenant importer les données dans votre nouvelle/première instance AD LDS.
L’utilitaire LDIFDE crée, modifie et supprime des objets de l’annuaire. Vous pouvez donc utiliser cet utilitaire pour renseigner les services AD LDS. Le commandes PowerShell sont utilisable également (New-ADUser, Get-ADUser et cætera).
Vous pouvez néanmoins privilégier l’utilisation de LDIFDE dans certaines situations, comme : extension du schéma, export d’informations relatives aux utilisateurs et aux groupes vers ou venant d’autres applications ou services.
Tuto import/export
Voici quelques commandes simples et utiles pour importer et exporter des données dans AD LDS :
-
- Export :
ldifde -e -f %filename% -s %servername% :%port%
- Export :
-
- Import :
ldifde -i -f %filename% -s %servername% :%port% -m -a %username% %domain% *
- Import :
-
- Synchronisation :
adamsync /force -1 /FS %servername%:%port% « %partirion_DN% » /log (complet)
adamsync /force -1 %servername%:%port% « %partirion_DN% » /log (partiel)
- Synchronisation :
Le démarrage et l’arrêt des instances AD LDS peuvent être gérés à l’aide de l’utilitaire net :
-
- Démarrage :
net start %nstancename% - Arrêt :
net stop %instancename%
- Démarrage :
Gestion des services et instances
Il vous est possible de gérer le service AD LDS graphiquement depuis l’interface Server Manager. Voilà pourquoi la gestion est vraiment simple.
Pour des raisons évidentes de tolérance aux pannes, nous vous recommandons de construire des réplicas AD LDS, avec un accès chapeau assuré par un load balancer par exemple (une approche classique)
Maintenance de la base
Pour le reste, dsmgmt est à AD LDS ce que ntdsutil est AD DS.
Conclusion
Les services AD LDS comportent un aspect crucial de la gestion des identités.
Il facilite le stockage des données d’application et fournit un service d’annuaire pour les applications compatibles LDAP, sans exposer davantage l’Active Directory.
De ce fait, ils doivent être gérés avec soin afin de maintenir l’intégrité et la sécurité des données.
Par conséquent, des audits et des mises à jour réguliers sont essentiels pour garantir l’intégrité d’AD LDS.