Introduction ¶
Active Directory est une solution couramment utilisée dans le monde professionnel pour authentifier / autoriser les utilisateurs dans une infrastructure dont les postes de travail fonctionnent majoritairement sous Windows.
Il fournit une base centralisée (un annuaire LDAP en fait) qui permet de stocker les utilisateurs, les groupes, les privilèges, les comptes d’ordinateurs (permettant d’attacher des stations de travail au domaine), les stratégies de groupes (les fameuses GPO), les certificats, et bien d’autres choses encore.
Il arrive fréquemment que l’on souhaite authentifier des applications métier depuis cette base centralisée, afin de bénéficier des comptes utilisateurs déjà définis dedans. C’est facile à faire car il suffit d’un connecteur LDAP pour y parvenir.
Il peut arriver également que l’on souhaite authentifier des utilisateurs extérieurs à l’entreprise dans ces applications métier, et ajouter ces utilisateurs dans Active Directory n’est pas satisfaisant. En effet, on ne veut pas que ces utilisateurs existent sur le réseau, ni qu’ils puissent se logger sur les stations de travail, ni qu’ils aient des droits sur les partages de fichiers, etc…
Microsoft fournit pour cela LDS qui est un annuaire LDAP autonome, sans lien avec ActiveDirectory.
Reste alors à construire une réplication de Active Directory dans LDS, afin de bénéficier du meilleur des deux produits: les collaborateurs de l’entreprise dans Active Directory, et les utilisateurs externes (prestas, clients, …) dans une instance LDS.
Nous allons voir dans ce document comment construire une telle architecture.
Mise en oeuvre de la réplication AD => LDS ¶
L’environnement choisi est un contrôleur de domaine déjà déployé, sur un serveur windows 2008 R2. A l’aide du gestionnaire de serveur, on ajoute le rôle Services AD LDS
Puis on crée une instance, grâce à l’assistant de création d’instance LDS disponible dans Menu Démarrer / Outils d’administration.
L’instance sera unique (non répliquée) et utilisera par défaut les ports 50000 et 50001 (les ports 389 et 636 étant déjà occupés par Active Directory).
Quand l’assistant le demande, il faut créer une partition d’application, qui sera référencée par la suite dans cet article par “la partition”. Il est impératif ici d’utiliser un conteneur de type DC (surtout pas OU ou CN, contrairement à ce qu’indique l’assistant de Microsoft). Le plus simple est de reprendre le DN de la partition d’Active Directory).
Ensuite, il faut spécifier un compte ayant les droits Admins du domaine, puis veiller à n’importer aucun fichier LDIF.
A partir de ce stade, on est censé suivre la doc de Microsoft, disponible ici:
//technet.microsoft.com/fr-fr/library/cc770408.aspx
La doc de microsoft est malheureusement:
- mal traduite (merci la traduction mot à mot)
- peu claire (comme souvent chez eux)
- fausse ! (même en la suivant pas à pas, la réplication foire)
Il faut en fait suivre une doc plus poussée, rédigée par les membres de la team DS de Microsoft:
//blogs.technet.com/b/askds/archive/2012/11/12/adamsync-101.aspx
Ou l’on apprend que: il ne faut pas jouer l’upgrade de schéma automatique, mais bien analyser les différences entre le schéma DS et le schéma LDS, avant d’importer les modifs. Puis qu’il faut ajouter le support userProxy si l’on veut pouvoir se binder dans l’instance LDS avec un compte AD (c’est un peu le but quand même ….) et enfin qu’il faut être très restrictif dans le filtre de réplication si l’on veut avoir une chance que la réplication fonctionne.
Récapitulons.
Différences de schéma ¶
D’abord, on analyse les différences de schéma. Pour cela on lance c:\windows\adam\adschemaanalyzer.exe.
On charge d’abord le schéma cible (menu fichier / charger le schéma cible). On renseigne localhost:389 pour charger le schéma de l’AD.
On charge ensuite le schéma de base (menu fichier / charger le schéma de base). On renseigne localhost:50000 pour charger le schéma de l’instance LDS.
L’outil analyse les différences puis les affiche. On peut filtrer les éléments présents (menu schéma / masquer les éléments présents). Quoi qu’il en soit, on coche surtout menu schéma / marquer tous les éléments non présents en tant qu’éléments inclus, puis on génére le fichier LDF correspondant via menu fichier / créer un fichier LDIF, et on le nomme par exemple c:\windows\adam\ADAM-schema-upgrade.LDF.
On va ensuite jouer plusieurs fichiers LDIF sur le schéma de l’instance LDS. Pour cela, on lance une fenêtre cmd, et on se positionne dans c:\windows\adam:
cd c:\windowd\adam
On joue d’abord le fichier LDIF créé prédédemment:
c:\Windows\ADAM>ldifde -i -u -f ADAM-schema-ugrade.LDF -s localhost:50000 -b username domain password -j . -c "cn=Configuration,dc=X" #configurationNamingContext Connexion à « localhost:50000 » en cours Connexion en cours en tant que « username » dans le domaine « domain » en utilisant SSPI Importation de l'annuaire à partir du fichier « ADAM-schema-upgrade.LDF » Chargement des entrées.......................................................... ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ................................................................................ .................................................... 1309 entrées modifiées. La commande s'est terminée correctement
Puis l’on insère les métadonnées qui vont permettre de stocker la configuration de réplication dans l’instance LDS:
c:\Windows\ADAM>ldifde -i -f MS-AdamSyncMetadata.LDF -s localhost:50000 -b username domain password -j . -c "cn=Configuration,dc=X" #configurationNamingC ontext Connexion à « localhost:50000 » en cours Connexion en cours en tant que « username » dans le domaine « domain » en utilisant SSPI Importation de l'annuaire à partir du fichier « MS-AdamSyncMetadata.LDF » Chargement des entrées.......... 9 entrées modifiées. La commande s'est terminée correctement
Puis l’on va jouer 2 fichiers: MS-UserProxyFull.LDF qui va permettre de transformer les objets de la classe User en objets de la classe UserProxyFull, autorisant ainsi le bind LDAP dans l’instance LDS d’utilisateurs définis au préalable dans Active Directory. La classe UserProxyFull dépend de la classe User, on va donc jouer également ce LDIF:
c:\Windows\ADAM>ldifde -i -f MS-User.ldf -s localhost:50000 -b username domain password -k -j . -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext Connexion à « localhost:50000 » en cours Connexion en cours en tant que « username » dans le domaine « domain » en utilisant SSPI Importation de l'annuaire à partir du fichier « MS-User.ldf » Chargement des entrées.......................................................... ......... 66 entrées modifiées. La commande s'est terminée correctement c:\Windows\ADAM>ldifde -i -f MS-UserProxyFull.ldf -s localhost:50000 -b username domain password -k -j . -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext Connexion à « localhost:50000 » en cours Connexion en cours en tant que « username » dans le domaine « domain » en utilisant SSPI Importation de l'annuaire à partir du fichier « MS-UserProxyFull.ldf » Chargement des entrées... 2 entrées modifiées. La commande s'est terminée correctement
Préparer la configuration de réplication ¶
Il reste maintenant à préparer le fichier XML qui servira à décrire la configuration de réplication. Microsoft fournit un exemple dans c:\windows\adam\MS-AdamSyncConf.XML, qui malheureusement ne fonctionne pas en l’état.
On va suivre les recommendations de l’article cité plus haut:
- filtre de recherche d’objets limité aux utilisateurs et groupes
- exclusion de tous les attributs sauf ceux inclus explicitement
- ajout d’une transformation des objets User en objet UserProxyFull (la classe UserProxy ne contient pas assez d’attributs et provoque des violations de containtes d’objet lors de la première réplication).
On obtient le fichier XML suivant:
<?xml version="1.0"?>
<doc>
<configuration>
<description>ADAMsync from AD to LDS MonInstance</description>
<security-mode>object</security-mode>
<source-ad-name>fqdn.domain.controller.domain</source-ad-name>
<source-ad-partition>DC=MaPartition</source-ad-partition>
<source-ad-account></source-ad-account>
<account-domain></account-domain>
<target-dn>DC=MaPartition</target-dn>
<query>
<base-dn>DC=MaPartition</base-dn>
<object-filter>(|(objectCategory=Person)(objectCategory=OrganizationalUnit)(objectClass=Group))</object-filter>
<attributes>
<include>objectSID</include>
<include>userPrincipalName</include>
<include>displayName</include>
<include>givenName</include>
<include>sn</include>
<include>physicalDeliveryOfficeName</include>
<include>telephoneNumber</include>
<include>mail</include>
<include>title</include>
<include>department</include>
<include>manager</include>
<include>mobile</include>
<include>ipPhone</include>
<exclude></exclude>
</attributes>
</query>
<schedule>
<aging>
<frequency>0</frequency>
<num-objects>0</num-objects>
</aging>
<schtasks-cmd></schtasks-cmd>
</schedule>
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>userProxyFull</target-object-class>
</user-proxy>
</configuration>
<synchronizer-state>
<dirsync-cookie></dirsync-cookie>
<status></status>
<authoritative-adam-instance></authoritative-adam-instance>
<configuration-file-guid></configuration-file-guid>
<last-sync-attempt-time></last-sync-attempt-time>
<last-sync-success-time></last-sync-success-time>
<last-sync-error-time></last-sync-error-time>
<last-sync-error-string></last-sync-error-string>
<consecutive-sync-failures></consecutive-sync-failures>
<user-credentials></user-credentials>
<runs-since-last-object-update></runs-since-last-object-update>
<runs-since-last-full-sync></runs-since-last-full-sync>
</synchronizer-state>
</doc>
On installe ensuite cette configuration de réplication dans l’instance LDS:
c:\Windows\ADAM>adamsync.exe /list localhost:50000 Liste des fichiers de configuration : ------------------------------------- Terminé. c:\Windows\ADAM>adamsync.exe /install localhost:50000 MS-AdamSyncConfMaPartition.xml Terminé. c:\Windows\ADAM>adamsync.exe /list localhost:50000 Liste des fichiers de configuration : ------------------------------------- |-> « DC=MaPartition » : ADAMsync from AD to LDS MonInstance Terminé. c:\Windows\ADAM>adamsync.exe /sync localhost:50000 DC=MaPartition /log sync.log c:\Windows\ADAM>notepad sync.log
Si tout s’est bien passé, la fin de sync.log doit ressembler à ca:
[...] Mise à jour du cookie DirSync du fichier de configuration. Début du traitement des références de DN reportées. Fin du traitement des références de DN reportées. La passe de synchronisation est terminée. Nombre d'entrées traitées par DirSync: 54 Nombre d'entrées traitées par LDAP: 2 Le traitement a duré 0 secondes (0, 0). Nombre d'ajouts d'objets: 55 Nombre de modifications d'objets: 1 Nombre de suppressions d'objets: 0 Nombre d'objets renommés: 0 Nombre de références traitées/perdues: 0, 0 Nombre maximal d'attributs vus sur un seul objet: 9 Nombre maximal de valeurs récupérées par syntaxe d'étendue: 0 Début de la passe de vieillissement. Vieillissement demandé toutes les 0 passes. Le dernier vieillissement date de 1 passes. Enregistrement du fichier de configuration sur DC=MaPartition Le fichier de configuration a été enregistré.
Reste maintenant à créer une tâche dans le scheduler windows pour relancer cette replication de manière récurrente.
Désactiver le recours à SSL pour le bind LDAP dans LDS ¶
Désactiver le recours à SSL pour le bind LDAP dans LDS
Il faut lancer ADSIEdit, puis ouvrir l’instance LDS dans le contexte Configuration (pas le contexte de la partition).
Ensuite il faut chercher l’objet CN=Directory Service,CN=Windows NT,CN=Services. Modifier ses propriétés, et chercher l’attribut msDS-Other-Settings.
Supprimer la valeur RequireSecureProxyBind=1 et la ré-ajouter avec la valeur 0.
Ensuite, il faut relancer l’instance LDS.
Permettre le bind LDAP avec un SecurityPrincipal LDS (et non AD) ¶
Arrivés à ce stade, vous pouvez vous binder dans l’instance LDS en utilisant un compte répliqué depuis AD, mais pas depuis un compte créé directement dans LDS.
Il faut utiliser ADSIEdit, ouvrir l’instance dans le contexte de schéma (pas le contexte de la partition), et modifier la classe cn=User. Dans la liste des attributs, rechercher auxiliaryClass, qui doit contenir par défaut posixAccount et shadowAccount.
Ajouter la valeur msDS-BindableObject, sauvegarder, puis relancer l’instance LDS.
Ensuite, toujours avec ADSIEdit, mais dans le contexte de la partition ce coup-ci (dc=MaPartition), ajouter un object de type user, puis faire un reset de son mot de passe dans ADSIEdit.
Charger les propriétés de l’objet, et chercher l’attribut msDS-userAccountDisabled, qui doit être à VRAI par défaut. Le passer à FALSE, le bind doit maintenant être possible avec cet utilisateur.
Modifier les droits pour que les utilisateurs bindés dans LDS voient les objets ¶
Par défaut, les utilisateurs qui se bindent dans une instance LDS ne voient que les DNs des objets, car ils ont le rôle cn=Users,cn=Roles qui par défaut n’a aucun droit sur l’annuaire. Au contraire du rôle cn=Readers,cn=roles qui peut lire tous les attributs de tous les objets de l’annuaire, mais qui ne correspond à aucun utilisateur.
Plusieurs solutions ici:
ajouter le compte “utilisateurs authentifiés” dans le rôle “cn=Readers” ¶
Dans ADSIEdit, ouvrir l’instance LDS, dans le contexte de la partition. Chercher le rôle cn=Readers,cn=Roles,dc=MaPartition puis modifier l’attribut member. Il faut ajouter l’utilisateur windows correspondant à “Utilisateurs authentifiés”
ajouter le rôle “cn=Users” dans le rôle “cn=Readers” ¶
C’est une deuxième solution: faire en sorte que les utilisateurs qui se bindent, et qui ont donc le rôle User, aient également le rôle Reader. Pour ce faire, lancer ADSIEdit, ouvrir l’instance LDS dans le contexte de la partition, puis modifier l’objet cn=Readers,,cn=Roles,dc=MaPartition. Modifier l’attribut member et ajouter le DN cn=Users,cn=Roles,dc=MaPartition.
3ème solution: modifier finement les droits avec ldp.exe ¶
C’est une 3ème solution. Utiliser l’éditeur ACE de LDP.exe pour régler finement les droits sur la partition, ou sur une sous-arborescence de celle-ci.
