Comment configurer l'intégration d'annuaires Unified Communications Manager dans un environnement multiforêt

Introduction

Ce document explique comment configurer l'intégration de répertoires de Cisco Unified Communication Manager (CUCM) dans un environnement multiforêt.   

Conditions préalables

Conditions requises

Cisco recommande que vous ayez :

1. Connaissance du déploiement et de la configuration de l'intégration des répertoires CUCM.
2. Connaissance du déploiement et de la configuration de Microsoft Active Directory Application Manager (ADAM) 2003 ou de Microsoft Lightweight Directory Services (AD LDS) 2008 ou 2012.
3. CUCM version 9.1(2) ou ultérieure.
4. Lorsque vous utilisez CUCM version 9.1(2) ou ultérieure, le filtre LDAP peut être modifié à l'aide de l'interface Web d'administration. 
5. Le nombre de comptes d'utilisateurs à synchroniser ne doit pas dépasser 60 000 comptes par serveur de publication CUCM. Lorsque plus de 60 000 comptes doivent être synchronisés, le kit de développement logiciel (SDK) des services téléphoniques IP doit être utilisé pour fournir un répertoire personnalisé. Reportez-vous au réseau des développeurs Cisco pour plus de détails. Lorsque vous utilisez Unified CM version 10.0(1) ou ultérieure, le nombre maximal de comptes d'utilisateurs pris en charge est de 160 000.
6. Microsoft ADAM 2003 ou LDS (Lightweight Directory Services) 2008 ou 2012.
7. La condition requise pour SSL lorsque vous utilisez la redirection de liaison ne doit pas être désactivée. Si elle est désactivée, le mot de passe d'un principal de sécurité Windows passe à l'ordinateur qui exécute ADAM sans chiffrement. Il ne doit donc être désactivé que dans un environnement de test.
8. L'ID utilisateur (sAMAccountName ) doit être unique dans toutes les forêts.
9. S'il existe une configuration AD LDS et si l'ID utilisateur CUCM mappé à sAMAccountName doit être utilisé, cet accord doit être configuré en tant qu'AD.
10. Lorsque vous configurez la relation d'approbation de domaine entre le domaine hôte de l'instance ADAM et le domaine hôte des comptes d'utilisateurs, le niveau fonctionnel du domaine et le niveau fonctionnel de la forêt doivent être de 2003 ou plus.
11. CUCM ne prend en charge qu'une seule partition d'annuaire d'applications dans AD LDS, la multipartition n'est pas prise en charge actuellement.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Préface

Microsoft AD LDS, anciennement connu sous le nom ADAM, peut être utilisé pour fournir des services d'annuaire pour les applications activées par répertoire. Au lieu d'utiliser la base de données AD DS (Active Directory Domain Service) de votre organisation pour stocker les données d'application activées par l'annuaire, AD LDS peut être utilisé pour stocker les données. Les services AD LDS peuvent être utilisés conjointement avec les services AD DS afin que vous puissiez disposer d'un emplacement central pour les comptes de sécurité (AD DS) et d'un autre emplacement afin de prendre en charge la configuration de l'application et les données du répertoire (AD LDS). Avec AD LDS, vous pouvez réduire la surcharge associée à la réplication AD, vous n'avez pas besoin d'étendre le schéma AD pour prendre en charge l'application, et vous pouvez partitionner la structure de répertoire de sorte que le service AD LDS soit déployé uniquement sur les serveurs qui doivent prendre en charge l'application activée par répertoire.

• Installation à partir de la génération de supports - Possibilité de créer des supports d'installation pour AD LDS avec Ntdsutil.exe ou Dsdbutil.exe.
• Audit : audit des valeurs modifiées dans le service d'annuaire.
• Outil de montage de base de données : permet d'afficher des données dans des instantanés des fichiers de base de données.
• Support des sites et services AD - Permet d'utiliser les sites et services AD afin de gérer la réplication des modifications des données AD LDS.
• Liste dynamique des fichiers LDIF : cette fonctionnalité vous permet d'associer des fichiers LDIF personnalisés aux fichiers LDIF par défaut actuels utilisés pour la configuration d'AD LDS sur un serveur.
• Requêtes récursives d'attributs liés - Les requêtes LDAP peuvent suivre des liens d'attributs imbriqués afin de déterminer des propriétés d'attributs supplémentaires, telles que l'appartenance à un groupe.

Il y a beaucoup de différences entre ADAM et AD, ADAM ne peut fournir qu'une partie des fonctions fournies par AD.

Aperçu

L'objectif de ce document est d'expliquer les mécanismes qui permettent à CUCM, ou à tout autre produit Cisco qui utilise le service d'intégration d'annuaire (DirSync), d'obtenir des informations utilisateur et d'effectuer l'authentification à partir de différents domaines AD qui peuvent exister dans différentes forêts. Pour atteindre cet objectif, ADAM est utilisé afin de synchroniser sa base de données utilisateur avec différents contrôleurs de domaine AD ou d'autres sources LDAP.

ADAM peut créer une base de données d'utilisateurs et stocker leurs informations. La fonctionnalité d'authentification unique (SSO) est souhaitée afin d'éviter que les utilisateurs finaux n'aient à conserver des jeux d'informations d'identification différents dans différents systèmes ; par conséquent, ADAM bind redirection est utilisé. ADAM bind redirection est une fonction spéciale pour les applications qui prennent en charge la liaison LDAP comme mécanisme d'authentification. Dans certains cas, le schéma spécial, ou contexte d'attribution de noms, peut vous forcer à éviter AD, ce qui fait d'ADAM un choix nécessaire. Cela évite aux utilisateurs de mémoriser plusieurs mots de passe en raison de l'utilisation d'un répertoire supplémentaire avec leur propre ID utilisateur et mot de passe.

Un objet proxy utilisateur spécial dans ADAM correspond à un compte utilisateur AD normal. Le proxy utilisateur ne possède pas de mot de passe réel stocké dans l'objet ADAM lui-même. Lorsque l'application effectue son opération de liaison normale, elle vérifie l'ID localement, mais vérifie le mot de passe par rapport à AD sous les couvertures comme illustré dans cette figure. L'application n'a pas besoin de connaître cette interaction AD.

La redirection de liaison ADAM doit être utilisée uniquement dans des cas spéciaux où une application peut exécuter une liaison LDAP simple à ADAM. Cependant, l'application doit toujours associer l'utilisateur à un principal de sécurité dans AD.

La redirection de liaison ADAM se produit lorsqu'une liaison à ADAM est tentée avec l'utilisation d'un objet spécial appelé objet proxy. Un objet proxy est un objet dans ADAM qui représente un principal de sécurité dans AD.  Chaque objet proxy dans ADAM contient le SID d'un utilisateur dans AD. Lorsqu'un utilisateur tente de se lier à un objet proxy, ADAM prend le SID stocké dans l'objet proxy, ainsi que le mot de passe fourni au moment de la liaison, et présente le SID et le mot de passe à AD pour l'authentification. Un objet proxy dans ADAM ne stocke pas de mot de passe et les utilisateurs ne peuvent pas modifier leurs mots de passe AD par le biais d'objets proxy ADAM.

Le mot de passe est présenté en texte clair à ADAM car la demande de liaison initiale est une simple demande de liaison LDAP. Pour cette raison, une connexion SSL est requise par défaut entre le client d'annuaire et ADAM. ADAM utilise des API de sécurité Windows afin de présenter le mot de passe à AD.

Vous pouvez obtenir plus d'informations sur la redirection de liaison dans Présentation de la redirection de liaison ADAM .

Scénario de prise en charge de plusieurs forêts Active Directory dans CUCM

Pour expliquer cette méthode, imaginez un scénario dans lequel Cisco Systems (Forest 2) a acquis deux autres sociétés : Tandberg (Forêt 3) et Webex (Forêt 1). Dans la phase de migration, intégrer la structure AD de chaque entreprise afin de permettre le déploiement d'un cluster Cisco Unified Communications unique.

Dans cet exemple, la société Cisco (Forest 2) a deux domaines, le domaine racine de la forêt appelé CISCO (dns cisco.com) et un sous-domaine appelé EMERG (dns emerg.cisco.com). Ces deux domaines ont un contrôleur de domaine qui est également un catalogue global et chacun est hébergé dans Windows 2008 Server SP2.

La société Tandberg (Forest 3) a un seul domaine avec un contrôleur de domaine qui est également un catalogue global et il est hébergé dans Windows 2008 Server SP2.

La société Webex (Forest 1) a un seul domaine avec un contrôleur de domaine qui est également un catalogue global et il est hébergé dans Windows 2003 R2 Server SP2.

AD LDS est installé dans le contrôleur de domaine pour le domaine CISCO ou peut être un ordinateur distinct ; en fait, il pourrait se trouver n'importe où dans l'une des trois forêts. L'infrastructure DNS doit être en place de sorte que les domaines d'une forêt puissent communiquer avec les domaines d'autres forêts et établir les relations de confiance appropriées et les validations entre les forêts.

Relation d'approbation de domaine

Pour que l'authentification des utilisateurs fonctionne, vous devez avoir une approbation entre le domaine où l'instance ADAM est hébergée et les autres domaines qui hébergent les comptes utilisateur. Cette approbation peut être une approbation unidirectionnelle si nécessaire (approbation sortante du domaine qui héberge l'instance ADAM vers le ou les domaines qui hébergent les comptes d'utilisateurs). De cette manière, l'instance ADAM pourra transférer les demandes d'authentification aux DC de ces domaines de compte.

En outre, vous devez disposer d'un compte d'utilisateur des deux domaines de compte qui a accès à tous les attributs de tous les comptes d'utilisateur du domaine. Ce compte est utilisé par ADAMSync afin de synchroniser les utilisateurs du domaine de compte avec ADAM.

Enfin et surtout, la machine qui exécute ADAM doit pouvoir trouver tous les domaines (DNS), trouver les contrôleurs de domaine dans les deux domaines (avec DNS) et se connecter à ces contrôleurs de domaine.

Complétez ces étapes afin de configurer les relations d'interdépendance :

1. Ouvrez Domaines et approbations Active Directory, cliquez avec le bouton droit sur le domaine qui héberge AD LDS, puis sélectionnez Propriétés.

   

2. Cliquez sur l'onglet Approbations, puis sur Nouvelle approbation.

   

3. Suivez l'Assistant et entrez le nom du domaine avec lequel vous voulez établir l'approbation. Cliquez sur Next (Suivant).

   

4. Cliquez sur la case d'option approbation de forêt. Cliquez sur Next (Suivant).

   

5. En direction de la confiance seulement 'à sens unique : sortant' est requis. Cliquez sur One-way : bouton radio sortant. Cliquez sur Next (Suivant).

   

6. Autoriser l'Assistant à configurer les deux domaines. Cliquez sur la case d'option Ce domaine et le domaine spécifié. Cliquez sur Next (Suivant).

   

7. Entrez les informations d'identification de l'autre domaine. Cliquez sur Next (Suivant).

   

8. Cliquez sur la case d'option Authentification à l'échelle de la forêt. Cliquez sur Next (Suivant).

   

9. Cliquez sur la case d'option Oui, confirmer l'approbation sortante. Cliquez sur Next (Suivant).

   

C'est le résultat que vous recevez après avoir exécuté ce processus pour les domaines Tandberg et Webex. Le domaine emerg est présent par défaut car il s'agit d'un domaine enfant. Click OK.

Installer AD LDS

Installer AD LDS en 2008

1. Ouvrez le Gestionnaire de serveur, cliquez sur Rôles, puis sur Ajouter des rôles.

   

2. Cochez la case Services AD LDS (Active Directory Lightweight Directory Services). Cliquez sur Next (Suivant).

   

3. La fenêtre Progression de l'installation des services AD LDS s'affiche.

   

Installer AD LDS en 2012

Complétez ces étapes afin de configurer AD LDS en 2012 :

1. Ouvrez le Gestionnaire de serveur et choisissez Ajouter des rôles et des fonctionnalités. Cliquez sur Suivant et cliquez sur Type d'installation afin de passer à la page Type d'installation.

   

2. Choisissez les options par défaut et cliquez sur Suivant.

   

3. Cliquez sur la case d'option Sélectionner un serveur dans le pool de serveurs afin de sélectionner le serveur par défaut. Cliquez sur Next (Suivant).

   

4. Cochez la case Services AD LDS (Active Directory Lightweight Directory Services) et cliquez sur Ajouter des fonctionnalités. Poursuivez l'installation.

   

5. Cliquez sur Suivant dans les pages suivantes.
6. Cochez la case Redémarrer le serveur de destination automatiquement si nécessaire et cliquez sur Installer afin d'installer la fonctionnalité.

   

7. Une fois l'installation terminée, cliquez sur Fermer afin de fermer l'Assistant.

   

Installer l'instance pour la prise en charge de plusieurs forêts

AD LDS peut exécuter différentes instances des services avec différents ports, ce qui permet d'exécuter différentes « applications » du répertoire utilisateur sur la même machine. Par défaut, AD LDS choisit les ports 389/LDAP et 636/LDAPS, mais si le système dispose déjà d'un type quelconque de services LDAP qui les exécutent, il utilisera les ports 50000/LDAP et 50001/LDAPS. Chaque instance possède une paire de ports qui s'incrémente en fonction des numéros précédents utilisés.

Dans certains cas, en raison d'un bogue Microsoft, les ports sont déjà utilisés par le serveur DNS Microsoft et l'assistant d'instance donne une erreur (qui n'est pas explicative). Cette erreur peut être corrigée lorsque vous réservez les ports dans la pile TCP/IP. Si vous trouvez ce problème, consultez Échec du démarrage du service AD LDS avec l'erreur « le programme d'installation n'a pas pu démarrer le service... » + code d'erreur 8007041d.

Support forestier multiple en 2008

1. Dans le gestionnaire de serveurs, sélectionnez Rôles, puis Services AD LDS (Active Directory Lightweight Directory Services).  Cliquez ici pour créer une instance AD LDS.

   

2. Cliquez sur la case d'option Une instance unique. Cliquez sur Next (Suivant).

   

3. Dans le champ Nom de l'instance, saisissez le nom de l'instance. C'est MultiForest dans cet exemple. Cliquez sur Next (Suivant).

   

4. Saisissez le numéro de port LDAP et le numéro de port SSL sélectionnés ou autorisez le système à les choisir pour vous. Cliquez sur Next (Suivant).

   

5. Note: CUCM ne prend en charge qu'une seule partition d'annuaire d'applications, la multipartition n'est pas prise en charge actuellement.
   
   Voir Étape 5 : Exercez-vous à utiliser les partitions d'annuaire d'applications pour obtenir des informations sur la création d'une partition d'annuaire d'applications. Le processus de création d'une partition d'annuaire pour chaque domaine que vous voulez synchroniser avec des travaux basés sur la référence LDAP (RFC 2251) et qui nécessite que le client LDAP (CUCM, CUP, etc.) prenne en charge les références.

   Cliquez sur la case d'option Oui, créer une partition de répertoire d'applications. Entrez le nom de la partition dans le champ Nom de la partition de l'instance. Ne fournissez pas de cn comme dans l'exemple de l'Assistant, car la plupart du temps cela crée une erreur dans les Schémas. Dans ce scénario, la même partition que le contrôleur de domaine AD qui héberge AD LDS (dc=Cisco, dc=com) a été entrée. Cliquez sur Next (Suivant).

   

6. Cliquez sur la case d'option Ce compte. Entrez un nom d'utilisateur et un mot de passe afin de démarrer le serveur. Cliquez sur Next (Suivant).

   

7. Cliquez sur la case d'option Utilisateur actuellement connecté. Saisissez le nom de l'utilisateur disposant d'autorisations administratives. Cliquez sur Next (Suivant).

   

8. Importez les fichiers LDIF par défaut mis en surbrillance afin de créer le schéma. Cliquez sur Next (Suivant).

   

Note: Si ADAM est installé sur un serveur Windows 2003, l'écran précédent ne comporte que quatre options :  MS-AZMan.LDF, MS-InetOrgPerson.LDF, MS-User.LDF et MS-UserProxy.LDF. À partir de ces quatre, cochez uniquement les cases MS-User.LDF et MS-InetOrgPerson.LDF.

Support forestier multiple en 2012

1. Ouvrez les outils d'administration et double-cliquez sur Assistant de configuration des services AD LDS (Active Directory Lightweight Directory Services).

   

2. Cliquez sur Next (Suivant).

   

3. Cochez la case d'option Une instance unique. Cliquez sur Next (Suivant).

   

4. Entrez un nom et une description d'instance pour l'instance. Le nom « MultiForest » est entré ici. Cliquez sur Next (Suivant).

   

5. Saisissez les numéros de port LDAP et SSL. Les ports préférés sont respectivement 389 et 636. Si le serveur de domaine est un serveur enfant et si le domaine parent utilise ces ports, différents numéros de port seront renseignés par défaut. Dans ce cas, ne les modifiez pas et poursuivez l'installation. Cliquez sur Next (Suivant).

   

6. Ici, par défaut, d'autres numéros de port ont été renseignés. Cliquez sur Next (Suivant).

   

7. Note: CUCM ne prend en charge qu'une seule partition d'annuaire d'applications, la multipartition n'est pas prise en charge actuellement.
   
   Voir Étape 5 : Exercez-vous à utiliser les partitions d'annuaire d'applications pour obtenir des informations sur la création d'une partition d'annuaire d'applications. Le processus de création d'une partition d'annuaire pour chaque domaine que vous voulez synchroniser avec des travaux basés sur la référence LDAP (RFC 2251) et qui nécessite que le client LDAP (CUCM, CUP, etc.) prenne en charge les références. Voir Support Microsoft pour plus d'informations.

   Cliquez sur la case d'option Oui, créer une partition de répertoire d'applications. Saisissez le nom de la partition. Créez la partition pour LDS en tant que cisco.com. Toute valeur appropriée peut être fournie. Cliquez sur Next (Suivant).

   

8. Choisissez les options par défaut dans les pages suivantes et continuez.

   

   

   

9. Cochez les cases MS-InetOrgPerson.LDF, MS-User.LDF, MS-UserProxy.LDF et MS-UserProxyFull.LDF. Cliquez sur Next (Suivant).

   

   

10. Cliquez sur Suivant pour démarrer l'installation.

    

    

11. L'installation est terminée. Cliquez sur Finish.

    

Configurer ADAM Schema Analyzer

Si les ID utilisateur (sAMAccountNames) sont uniques dans différents domaines et qu'il n'y a pas plusieurs utilisateurs avec le même ID dans différents domaines de forêts différentes, alors les utilisateurs peuvent être synchronisés de l'AD vers les forêts respectives sur le LDS AD, qui peuvent tous exister sur une seule partition sur le LDS AD dans une configuration multi-forêts. Par exemple, considérez la figure dans la section Scénario de support de forêt multiple Active Directory dans CUCM, et si un ID utilisateur 'alice' n'existe que dans l'un des trois domaines, la configuration dans ce scénario serait la suivante :

PARTITION     FORÊT             DN

P1 cisco.com DC=cisco,DC=com

                       webex.com DC=webex, DC=cisco, DC=com

                       tandberg.com DC=Tandberg, DC=cisco, DC=com

Afin de configurer CUCM avec AD LDS, l'ID utilisateur (sAMAccountName) doit être unique dans toutes les forêts. CUCM ne prend actuellement en charge qu'une seule partition dans AD LDS.

Si les sAMAccountNames ne sont pas uniques, envisagez d'utiliser l'un de ces attributs s'ils identifient de manière unique un compte d'utilisateur : e-mail, phoneNumber, EmployeeNumber, uid ou userPrincipalName.

1. Copiez le schéma du domaine vers ADAM.
2. Ouvrez l'analyseur de schéma AD DS/LDS (ADSchemaAnalyzer.exe) dans le répertoire c:\windows\adam.
3. Choisissez Fichier > Charger le schéma cible.

   

4. Fournissez les informations d'identification du contrôleur de domaine AD source à partir duquel vous voulez importer. Cliquez sur OK.

   

5. Choisissez Fichier > Charger le schéma de base.

   

6. Spécifiez le AD LDS auquel vous voulez vous connecter et étendre le schéma. Cliquez sur OK.

   

7. Choisissez Schéma > Marquer tous les éléments non présents comme inclus.

   

8. Choisissez Fichier > Créer un fichier LDIF.  Dans cet exemple, le fichier créé via cette étape est diff-schema.ldf. Afin de simplifier le processus, le fichier doit être créé dans c:\windows\adam.

   

   Une option disponible pour aider à organiser les fichiers qui doivent être générés est de créer un répertoire séparé afin de permettre que ces fichiers soient séparés de l'c:\windows\adam directory principal. Ouvrez une invite de commande et créez un répertoire de journal dans c:\windows\adam.

   cd \windows\adam
   mkdir logs

9. Importez le schéma ldif, créé avec ADSchema Analyzer, dans AD LDS.

   ldifde -i -s localhost:50000 -c CN=Configuration,DC=X
    #ConfigurationNamingContext -f diff-schema.ldf -j c:\windows\adam\logs
   

   Reportez-vous à Utilisation de LDIFDE pour importer et exporter des objets de répertoire vers Active Directory pour obtenir des options ldifde supplémentaires et des formats de commande.

   

Étendre le schéma AD LDS avec les objets User-Proxy

L'objet pour l'authentification proxy doit être créé et la classe d'objet 'user' ne sera pas utilisée. La classe d'objet créée, userProxy, est ce qui permet la redirection de liaison. Le détail de la classe d'objet doit être créé dans un fichier ldif. Le fichier est la création d'un nouveau fichier, qui dans cet exemple est MS-UserProxy-Cisco.ldf.  Ce nouveau fichier est généré à partir du MS-UserProxy.ldf d'origine et modifié, utilisez un programme de modification de texte, pour avoir ce contenu :

#==================================================================
# @@UI-Description: AD LDS simple userProxy class.
#
# This file contains user extensions for default ADAM schema.
# It should be imported with the following command:
#   ldifde -i -f MS-UserProxy.ldf -s server:port -b username domain password -k -j . -c 
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
#
#==================================================================

dn: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: top
objectClass: classSchema
cn: User-Proxy
subClassOf: top
governsID: 1.2.840.113556.1.5.246
schemaIDGUID:: bxjWYLbzmEiwrWU1r8B2IA==
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: User-Proxy
adminDescription: Sample class for bind proxy implementation.
objectClassCategory: 1
lDAPDisplayName: userProxy
systemOnly: FALSE
possSuperiors: domainDNS
possSuperiors: organizationalUnit
possSuperiors: container
possSuperiors: organization
defaultSecurityDescriptor:
 D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)S:
defaultHidingValue: TRUE
defaultObjectCategory: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
systemAuxiliaryClass: msDS-BindProxy
systemMayContain: userPrincipalName
systemMayContain: givenName
systemMayContain: middleName
systemMayContain: sn
systemMayContain: manager
systemMayContain: department
systemMayContain: telephoneNumber
systemMayContain: mail
systemMayContain: title
systemMayContain: homephone
systemMayContain: mobile
systemMayContain: pager
systemMayContain: msDS-UserAccountDisabled
systemMayContain: samAccountName
systemMayContain: employeeNumber
systemMayContain: initials
systemMayContain: ipPhone
systemMayContain: displayName 
systemMayContain: msRTCSIP-primaryuseraddress
systemMayContain: uid

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

Enregistrez le fichier MS-UserProxy-Cisco.ldf dans C:\windows\adam.

Importer la nouvelle classe d'objet dans AD LDS.

ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f
 MS-UserProxy-Cisco.ldf -j c:\windows\adam\logs

Importer les utilisateurs du DC AD vers AD LDS

L'utilisateur de chaque domaine doit maintenant être importé dans AD LDS. Cette étape doit être répétée pour chaque domaine à synchroniser. Cet exemple montre uniquement le processus par rapport à l'un des domaines. Commencez par MS-AdamSyncConf.xml d'origine et créez un fichier XML pour chaque domaine qui doit être synchronisé et modifiez le fichier avec les détails spécifiques à chaque domaine pour avoir ce contenu :

<?xml version="1.0"?>
<doc> 
 <configuration>  
  <description>Adam-Sync1</description>  
  <security-mode>object</security-mode>         
  <source-ad-name>ad2k8-1</source-ad-name>  
  <source-ad-partition>dc=cisco,dc=com</source-ad-partition>
  <source-ad-account></source-ad-account>               
  <account-domain></account-domain>
  <target-dn>dc=cisco,dc=com</target-dn>  
  <query>   
   <base-dn>dc=cisco,dc=com</base-dn>
    <object-filter>
(&#124;(&amp;(!cn=Administrator)(!cn=Guest) (!cn=ASPNET)
(!cn=krbtgt)(sAMAccountType=805306368))(&amp;(objectClass=user)(isDeleted=TRUE)))
    </object-filter>
   <attributes>
    <include>objectSID</include>
    <include>mail</include> 
    <include>userPrincipalName</include>
    <include>middleName</include> 
    <include>manager</include> 
    <include>givenName</include> 
    <include>sn</include> 
    <include>department</include> 
    <include>telephoneNumber</include> 
    <include>title</include> 
    <include>homephone</include> 
    <include>mobile</include> 
    <include>pager</include> 
    <include>msDS-UserAccountDisabled</include>
    <include>samAccountName</include>
    <include>employeeNumber</include>
    <include>initials</include>
    <include>ipPhone</include>
    <include> displayName</include> 
    <include> msRTCSIP-primaryuseraddress</include>
    <include>uid</include>
    <exclude></exclude>
   </attributes>  
  </query>
 <user-proxy>
    <source-object-class>user</source-object-class>
    <target-object-class>userProxy</target-object-class>
  </user-proxy>  
  <schedule>   
   <aging>    
    <frequency>0</frequency>    
    <num-objects>0</num-objects>   
   </aging>   
   <schtasks-cmd></schtasks-cmd>  
  </schedule> 
 </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>

Dans ce fichier, ces balises doivent être remplacées pour correspondre au domaine :

• <source-ad-name> : utilisez le nom d'hôte du domaine.
• <source-ad-partition> - Utilisez la partition racine du contrôleur de domaine Active Directory source à partir duquel vous voulez importer (par exemple, dc=Cisco, dc=com ou dc=Tandberg, dc=com ).
• <base-dn> : choisissez le conteneur à partir duquel importer. Par exemple, si tous les utilisateurs du domaine sont requis, cela doit être identique à <source-ad-partition>, mais si les utilisateurs proviennent d'une unité d'organisation spécifique (telle que l'unité d'organisation financière), cela doit être similaire à OU=Finance, DC=Cisco, DC=com. 

Référez-vous à Syntaxe du filtre de recherche pour plus d'informations sur la création d'un <filtre-objet>.

Enregistrez le nouveau fichier XML dans C:\windows\adam.

Ouvrez une fenêtre de commande, cd \windows\adam.

Entrez la commande ADAMSync /install localhost : 50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log.

Vérifiez que le fichier AdamSyncConf1.xml est le fichier XML nouvellement créé.

Synchronisez les utilisateurs avec la commande ADAMSync /sync localhost : 50000 « dc=cisco, dc=com » /log c:\windows\adam\logs\sync.log.

Le résultat doit être similaire à :

Afin de terminer une synchronisation automatique d'AD à ADAM , utilisez le planificateur de tâches dans Windows.

Créez un fichier .bat contenant ce contenu : 

"C:\Windows\ADAM\ADAMSync" /install localhost : 50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log

"C:\Windows\ADAM\ADAMSync" /sync localhost : 50000 « dc=cisco, dc=com » /log c:\windows\adam\logs\syn.log

Planifiez la tâche pour exécuter le fichier .bat selon les besoins. Cela prend en charge les ajouts, les modifications et les suppressions qui se produisent dans AD pour être également répercutés dans ADAM.

Vous pouvez créer un autre fichier .bat et le planifier pour terminer une synchronisation automatique à partir de l'autre forêt.

Créer un utilisateur dans AD LDS pour la synchronisation et l'authentification CUCM

1. Ouvrez ADSI Edit à partir des outils Administrateur du menu Démarrage.
2. Choisissez Fichier > Connexion (ou Action > Se connecter à).
3. Connectez-vous au dn de base de l'arborescence AD LDS (DC=Cisco, DC=com) et spécifiez l'hôte et le port où il est hébergé (localhost:50000). Click OK.

   

4. Cliquez avec le bouton droit sur le DN de base et choisissez Nouveau > Objet.

   

5. Choisissez utilisateur. Cliquez sur Next (Suivant).

   

6. Dans le champ Valeur, saisissez le nom de l'objet sélectionné. Dans cet exemple, « root » est le nom choisi (n'importe quel nom peut être choisi ici). Cliquez sur Next (Suivant).

   

7. Afin de fournir un mot de passe au nouvel utilisateur, cliquez avec le bouton droit de la souris sur l'utilisateur et choisissez Réinitialiser le mot de passe.

   

8. Le nouvel utilisateur est désactivé par défaut. Afin d'activer le nouvel utilisateur, cliquez avec le bouton droit sur l'utilisateur et sélectionnez Propriétés.

   

9. Accédez à l'attribut msDS-UserAccountDisabled et cliquez sur Modifier.

   

10. Cliquez sur la case d'option False afin d'activer le compte utilisateur. Click OK.

    

11. Cliquez sur la case d'option True afin de vous assurer que le mot de passe n'expirera jamais. Click OK.

    

12. Le nouvel utilisateur doit être ajouté à un groupe disposant d'une autorisation de lecture sur le service AD LDS, qui a été choisi dans cet exemple Administrateurs. Accédez à CN=Rôles > CN=Administrateurs. Cliquez avec le bouton droit sur CN=Administrateurs et sélectionnez Propriétés.

    

13. Choisissez le membre d'attribut et cliquez sur Modifier.

    

14. Entrez le nouveau DN créé précédemment, cn=root, dc=Cisco, dc=com, pour ce groupe. Click OK.

    

15. Choisissez Mettre à jour le schéma maintenant et redémarrez AD LDS.

    

    

Configurer la redirection de liaison

Par défaut, la liaison à ADAM avec la redirection de liaison nécessite une connexion SSL. SSL nécessite l'installation et l'utilisation de certificats sur l'ordinateur qui exécute ADAM et sur l'ordinateur qui se connecte à ADAM en tant que client. Si les certificats ne sont pas installés dans votre environnement de test ADAM, vous pouvez désactiver la condition requise pour SSL comme alternative.

Par défaut, SSL est activé. Pour que le protocole LDAPS fonctionne dans ADAM/LDS, vous devez générer un certificat.

Dans cet exemple, le serveur de l'Autorité de certification Microsoft est utilisé pour émettre le certificat. Pour demander un certificat, accédez à la page Web de l'autorité de certification Microsoft - http://<nom d'hôte de l'autorité de certification MSFT>/certsrv et complétez ces étapes :

1. Cliquez sur Demander un certificat.
2. Cliquez sur Advanced certificate request (requête de certificat avancée).
3. Cliquez sur Créer et envoyer une demande à cette autorité de certification.
4. Dans la zone de texte Nom, saisissez le nom DNS complet du serveur ADAM/AD LDS.
5. Assurez-vous que le type de certificat est le certificat d'authentification du serveur.
6. Pour le format, sélectionnez PCKS10.
7. Sélectionnez Marquer les clés comme exportables.
8. Si vous le souhaitez, renseignez les autres informations.
9. Dans la zone de texte Nom convivial, saisissez le nom dns complet du serveur ADAM/AD LDS.
10. Cliquez sur Submit.

Revenez à l'interface de l'autorité de certification et cliquez sur le dossier Certificats en attente. Cliquez avec le bouton droit sur la demande de certificat effectuée par l'ordinateur ADAM/AD-LDS et émettez le certificat.

Le certificat a été créé et réside dans le dossier « Certificats émis ». Ensuite, vous devez télécharger et installer le certificat :

1. Ouvrez http://<nom d'hôte de l'autorité de certification MSFT>/certsrv.
2. Cliquez sur Afficher l'état d'une demande de certificat en attente.
3. Cliquez sur la demande de certificat.
4. Cliquez sur le certificat afin de l'installer.

Pour permettre au service ADAM d'utiliser le certificat, vous devez placer le certificat dans le magasin personnel du service ADAM :

1. Dans le menu Démarrer, sélectionnez Exécuter. Tapez mmc. La console de gestion s'ouvre.
2. Cliquez sur Fichier \ Ajouter/Supprimer le composant logiciel enfichable.
3. Cliquez sur Ajouter et sélectionnez Certificats.
4. Sélectionnez Compte de service.
5. Choisissez Ordinateur local.
6. Sélectionnez votre service d'instance ADAM.
7. Ajoutez un nouveau composant logiciel enfichable Certificat, mais cette fois, choisissez Mon compte d'utilisateur au lieu du compte de service.
8. Cliquez sur Fermer et sur OK.
9. Dans l'arborescence Certificates - Current user, ouvrez le dossier Personal.
10. Sélectionnez le certificat et copiez-le dans le même emplacement sous « Certificats - nom d'instance d'adam« .

Afin d'accorder l'autorisation de lecture sur le certificat d'authentification du serveur au compte de service réseau, procédez comme suit :

1. Accédez à ce répertoire par défaut où sont stockés les certificats installés ou importés - C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
2. Cliquez avec le bouton droit sur le certificat d'authentification du serveur approprié. Cliquez sur Properties.
3. Cliquez sur l'onglet Security. Cliquez sur Edit.
4. Dans la boîte de dialogue Autorisations, cliquez sur Ajouter.
5. Dans la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs ou des groupes, saisissez Service réseau. Click OK.
6. Redémarrez votre instance ADAM.

Vous trouverez plus de renseignements à l'annexe A : Configuration des conditions LDAP sur SSL pour AD LDS.

Ensuite, téléchargez le certificat de l'autorité de certification qui a émis le certificat sur l'ordinateur ADAM/AD LDS en tant qu'approbation de répertoire CUCM.

Reportez-vous au Guide d'administration de Cisco Unified Communications Operations System pour plus de détails.

Activez la case à cocher afin d'utiliser SSL dans la page Annuaire LDAP et la page Authentification LDAP.

Saisissez 50001 (dans cet exemple) pour le port LDAP, qui est le numéro de port SSL indiqué lors de l'installation de l'instance ADAM/AD LDS.

Afin de désactiver la condition SSL pour la redirection de liaison, complétez ces étapes :

1. Cliquez sur Démarrer, pointez sur Outils d'administration, puis cliquez sur Modifier ADSI.
2. Dans le menu Action, sélectionnez Se connecter à.
3. Dans le champ Ordinateur, saisissez localhost:50000 (il s'agit de l'hôte et du port ADAM).
4. Dans la section Point de connexion, cliquez sur la case d'option Sélectionner un contexte de nom connu. Dans la liste déroulante, sélectionnez Configuration. Click OK.
5. Dans l'arborescence de la console, accédez à cet objet conteneur dans la partition de configuration : CN=Service d'annuaire, CN=Windows NT, CN=Services.
6. Cliquez avec le bouton droit sur CN=Service d'annuaire et sélectionnez Propriétés.
7. Dans Attributs, cliquez sur msDS-Other-Settings. Cliquez sur Edit.
8. Dans Valeurs, cliquez sur RequireSecureProxyBind=1, puis sur Supprimer.
9. Dans Valeur à ajouter, saisissez RequireSecureProxyBind=0, cliquez sur Ajouter, puis sur OK.
10. Redémarrez AD LDS pour que les modifications prennent effet.

  

Configurer CUCM

La synchronisation et l'authentification ADAM/AD LDS sont prises en charge dans CUCM version 9.1(2) et ultérieure.

1. Choisissez System > LDAP > LDAP System.
2. Sélectionnez Microsoft ADAM ou Lightweight Directory Services.
3. Vous pouvez choisir l'un des attributs d'ID utilisateur LDAP suivants : courrier, numéro d'employé ou numéro de téléphone.

   uid est utilisé uniquement avec les LDS ADAM/AD autonomes et non avec la prise en charge multiforêt AD.

   

   Actuellement, pour le type de serveur LDAP « Microsoft ADAM ou Lightweight Directory Services », samAccountName n'est pas inclus dans la liste déroulante Attribut LDAP pour Userid . La raison est qu'il ne s'agit pas d'un attribut pris en charge par ADAM/AD LDS autonome.  Si l'ID utilisateur CUCM mappé à sAMAccountName doit être utilisé, cet accord doit être configuré en tant qu'AD.

   

4. Configurez la synchronisation LDAP avec les informations d'identification de l'utilisateur créé dans AD LDS.

   

5. Configurez l'authentification LDAP avec les informations d'identification de l'utilisateur créées dans AD LDS.

   

Filtres LDAP dans CUCM

L'utilisateur de classe d'objet n'est plus utilisé. Par conséquent, le filtre LDAP doit être modifié pour utiliser userProxy au lieu de User.

Le filtre par défaut est :
(&(objectclass=user)(!(objectclass=Ordinateur))(!(msDS-UserAccountDisabled=TRUE))

Afin de modifier ce filtre, connectez-vous à CCMAdmin à l'aide d'un navigateur Web et choisissez l'option de filtre personnalisé LDAP dans le menu de configuration LDAP.

Ce filtre est utilisé dans la page d'annuaire LDAP lors de la configuration de LDAP de l'accord de synchronisation, comme illustré dans la figure précédente.