Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Intégrer AD avec CUAC et importer des utilisateurs à partir d'AD

Fonctionnalité LDAP entre CUAC et AD

Résumé du processus LDAP

Détails du processus LDAP

Introduction

Ce document décrit le fonctionnement du protocole LDAP (Lightweight Directory Access Protocol) entre Cisco Unified Attendant Console (CUAC) et Microsoft Active Directory (AD) et les procédures utilisées pour intégrer les deux systèmes.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- CUCM

- CUAC

- LDAP

- AD

Components Used

Les informations de ce document sont basées sur la version CUAC 10.x.

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.

Informations générales

Dans les versions CUAC antérieures, le serveur obtient les utilisateurs directement à partir de Cisco Unified Communications Manager (CUCM) via des requêtes et des filtres prédéfinis. Avec CUAC Premium Edition (CUACPE), les administrateurs sont autorisés à intégrer et importer des utilisateurs directement à partir d'AD. Les administrateurs peuvent ainsi mettre en oeuvre des attributs et des filtres de leur choix et de leurs besoins.

Note: Le CUACPE a été remplacé par l'édition avancée du CUAC pour les versions 10 et ultérieures.

Intégrer AD avec CUAC et importer des utilisateurs à partir d'AD

Complétez ces étapes afin d'intégrer le CUAC à la AD et d'importer des utilisateurs à partir de la AD :

1. Activez la synchronisation d'annuaires pour AD sur CUAC.

2. Sélectionnez Microsoft Active Directory et cochez la case Activer la synchronisation :

3. Entrez les détails de configuration du serveur Active Directory :

Pour cet exemple, administrator@aloksin.lab est utilisé pour l'authentification :

4. Dans la section Paramètres de propriété, entrez les détails de configuration de la propriété Unique, qui s'affiche une fois que vous avez entré les autres détails et cliquez sur Enregistrer.

Note: Il s'agit d'une valeur unique pour chaque entrée de la distance administrative. S'il y a des valeurs en double, le CUAC n'extrait qu'une seule entrée.

5. Dans la section Conteneur, entrez les détails de configuration du DN de base, qui est l'étendue de recherche de l'utilisateur dans l'AD.

Le champ de classe Object est utilisé par AD afin de déterminer l'étendue de recherche demandée. Par défaut, il est défini sur contact, ce qui signifie que le service AD recherche des contacts (et non des utilisateurs) dans la base de recherche demandée. Afin d'importer des utilisateurs sur CUAC, modifiez le paramètre de classe Object en utilisateur :

6. Enregistrez les paramètres, cliquez sur Mappages de champs de répertoire et configurez tous les attributs que vous souhaitez importer pour n'importe quel utilisateur. Voici la configuration utilisée dans cet exemple :

7. Accédez à la page source du répertoire et cliquez sur Règles du répertoire :

8. Cliquez sur Ajouter nouveau et créez une règle. Lorsque vous ajoutez une règle de répertoire, un filtre de règle apparaît par défaut.

Note: Il n'est pas nécessaire de modifier le filtre de règle. Il importe tous les utilisateurs dont le numéro de téléphone est configuré.

9. Afin de configurer la synchronisation automatique avec AD, cliquez sur l'onglet Synchronisation d'annuaire.

10. La configuration est maintenant terminée. Accédez à Engineering > Service Management et redémarrez le plug-in LDAP afin de démarrer la synchronisation manuellement.

Fonctionnalité LDAP entre CUAC et AD

Résumé du processus LDAP

Voici un résumé du processus LDAP entre CUAC et AD :

1. Une session TCP est établie entre les deux serveurs (CUAC et AD).

2. Le CUAC envoie une requête BIND à l'AD et s'authentifie via l'utilisateur configuré dans les paramètres d'authentification.

3. Une fois que l'AD a réussi à authentifier l'utilisateur, il envoie une notification de réussite BIND au CUACPE.

4. Le CUAC envoie une requête SEARCH à l'AD, qui dispose des informations de portée de recherche, des filtres de recherche et des attributs pour tout utilisateur filtré.

5. La fonction AD recherche l'objet demandé (configuré dans les paramètres de la classe d'objet) dans la base de recherche. Il filtre les objets qui correspondent aux critères (filtre) détaillés dans le message de demande SEARCH.

6. La distance administrative répond au CUAC avec les résultats de la recherche.

Voici une capture de renifleur qui illustre ces étapes :

Détails du processus LDAP

Une fois la configuration du CUAC terminée et le plug-in LDAP redémarré, le serveur CUAC configure une session TCP avec l'AD.

Le CUAC envoie ensuite une requête BIND afin de s'authentifier auprès du serveur AD. Si l'authentification réussit, la distance administrative envoie une réponse de réussite BIND au CUAC. Avec cela, les deux serveurs tentent de configurer une session sur le port 389 afin de synchroniser les utilisateurs et leurs informations.

Voici la configuration sur le serveur qui définit le nom distinctif, qui est utilisé pour l'authentification dans la transaction BIND :

Ces messages apparaissent dans les captures de paquets :

- Voici la connexion TCP, suivie de la requête BIND :

- Voici l'extension de la requête BIND :

- Voici l'extension de la réponse BIND, qui indique une authentification réussie de l'utilisateur (administrateur dans cet exemple) :

En cas de liaison réussie, le serveur envoie une requête SEARCH à l'AD afin d'importer des utilisateurs. Cette requête SEARCH contient le filtre et les attributs utilisés par AD. L'AD recherche ensuite les utilisateurs dans la base de recherche définie (comme indiqué dans le message de demande SEARCH), qui répond aux critères du filtre et à la vérification des attributs.

Voici un exemple de requête SEARCH envoyée par CUCM :

Lightweight Directory Access Protocol

LDAPMessage searchRequest(2) "dc=aloksin,dc=lab" wholeSubtree

messageID: 2

protocolOp: searchRequest (3)

searchRequest

baseObject: dc=aloksin,dc=lab

scope: wholeSubtree (2)

derefAliases: derefAlways (3)

sizeLimit: 0

timeLimit: 0

typesOnly: False

Filter: (&(&(objectclass=user)(!(objectclass=Computer)))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

filter: and (0)

and: (&(&(objectclass=user)(!(objectclass=Computer)))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

and: 3 items

Filter: (objectclass=user)

and item: equalityMatch (3)

equalityMatch

attributeDesc: objectclass

assertionValue: user

Filter: (!(objectclass=Computer))

and item: not (2)

Filter: (objectclass=Computer)

not: equalityMatch (3)

equalityMatch

attributeDesc: objectclass

assertionValue: Computer

Filter: (!(UserAccountControl:1.2.840.113556.1.4.

803:=2))

and item: not (2)

Filter: (UserAccountControl:1.2.840.113556

.1.4.803:=2)

not: extensibleMatch (9)

extensibleMatch UserAccountControl

matchingRule: 1.2.840.113556.

1.4.803

type: UserAccountControl

matchValue: 2

dnAttributes: False

attributes: 15 items

AttributeDescription: objectguid

AttributeDescription: samaccountname

AttributeDescription: givenname

AttributeDescription: middlename

AttributeDescription: sn

AttributeDescription: manager

AttributeDescription: department

AttributeDescription: telephonenumber

AttributeDescription: mail

AttributeDescription: title

AttributeDescription: homephone

AttributeDescription: mobile

AttributeDescription: pager

AttributeDescription: msrtcsip-primaryuseraddress

AttributeDescription: msrtcsip-primaryuseraddress

[Response In: 103]

controls: 1 item

Control

controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)

criticality: True

SearchControlValue

size: 250

cookie: <MISSING>

Lorsque l'AD reçoit cette requête de CUCM, il recherche des utilisateurs dans l'objet base : dc=aloksin,dc=lab, qui satisfait le filtre. Tout utilisateur qui ne remplit pas les conditions détaillées par le filtre est laissé de côté. La commande AD répond au CUCM avec tous les utilisateurs filtrés et envoie les valeurs des attributs demandés.

Note: Les objets ne peuvent pas être importés. Seuls les utilisateurs sont importés. En effet, le filtre envoyé dans le message de demande SEARCH inclut objectclass=user. Par conséquent, la fonction AD recherche uniquement les utilisateurs et non les contacts. CUCM possède tous ces mappages et un filtre par défaut.

Le CUAC n'est pas configuré par défaut ; aucun détail de mappage n'est configuré pour importer des attributs pour les utilisateurs. vous devez donc entrer ces détails manuellement. Afin de créer ces mappages, accédez à Configuration système > Gestion des sources d'annuaire > Active Directory > Mappage des champs d'annuaire.

Les administrateurs sont autorisés à mapper des champs en fonction de leurs propres besoins. Voici un exemple :

Les informations du champ source sont envoyées à l'AD dans le message de demande SEARCH. Lorsque l'AD envoie le message de réponse SEARCH, ces valeurs sont stockées dans les champs de destination du CUACPE.

Notez que la classe d'objet CUAC par défaut est définie sur contacts. Si ce paramètre par défaut est utilisé, le filtre envoyé à la distance administrative apparaît comme indiqué ici :

Filter: (&(&(objectclass=contact)(  ............

Avec ce filtre, la fonction AD ne retourne jamais d'utilisateurs à CUACPE, car elle recherche des contacts dans la base de recherche, et non des utilisateurs. Pour cette raison, vous devez modifier la classe Objet en utilisateur :

Jusqu'à présent, ces paramètres ont été configurés sur CUAC :

- Détails des connexions

- Authentification (utilisateur unique pour la liaison)

- Paramètres du conteneur

- Mappage de répertoire

Dans cet exemple, la propriété Unique est configurée en tant que sAMAccountName. Si vous redémarrez le plug-in LDAP sur CUAC et vérifiez le message de demande SEARCH, il ne contient aucun attribut ou filtre à l'exception de ObjectClass=user :

Lightweight Directory Access Protocol

LDAPMessage searchRequest(224) "dc=aloksin,dc=lab" wholeSubtree

messageID: 224

protocolOp: searchRequest (3)

searchRequest

baseObject: dc=aloksin,dc=lab

scope: wholeSubtree (2)

derefAliases: neverDerefAliases (0)

sizeLimit: 1

timeLimit: 0

typesOnly: True

Filter: (ObjectClass=user)

filter: equalityMatch (3)

equalityMatch

attributeDesc: ObjectClass

assertionValue: user

attributes: 0 items

[Response In: 43]

Notez que la règle Répertoire est absente ici. Pour synchroniser les contacts avec la distance administrative, vous devez créer une règle. Par défaut, aucune règle de répertoire n'est configurée. Dès sa création, un filtre est déjà présent. Il n'est pas nécessaire de modifier le filtre, car vous devez importer tous les utilisateurs qui ont un numéro de téléphone.

Redémarrez le plug-in LDAP afin d'initier une synchronisation avec l'AD et d'importer les utilisateurs. Voici la demande SEARCH du CUAC :

Lightweight Directory Access Protocol

LDAPMessage searchRequest(4) "dc=aloksin,dc=lab" wholeSubtree

messageID: 4

protocolOp: searchRequest (3)

searchRequest

baseObject: dc=aloksin,dc=lab

scope: wholeSubtree (2)

derefAliases: neverDerefAliases (0)

sizeLimit: 0

timeLimit: 15

typesOnly: False

Filter: (&(&(objectclass=user)(telephoneNumber=*))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

filter: and (0)

and: (&(&(objectclass=user)(telephoneNumber=*))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

and: 3 items

Filter: (objectclass=user)

and item: equalityMatch (3)

equalityMatch

attributeDesc: objectclass

assertionValue: user

Filter: (telephoneNumber=*)

and item: present (7)

present: telephoneNumber

Filter: (!(UserAccountControl:1.2.840.113556.

1.4.803:=2))

and item: not (2)

Filter: (UserAccountControl:1.2.840.113556.

1.4.803:=2)

not: extensibleMatch (9)

extensibleMatch UserAccountControl

matchingRule: 1.2.840.113556.1.

4.803

type: UserAccountControl

matchValue: 2

dnAttributes: False

attributes: 10 items

AttributeDescription: TELEPHONENUMBER

AttributeDescription: MAIL

AttributeDescription: GIVENNAME

AttributeDescription: SN

AttributeDescription: sAMAccountName

AttributeDescription: ObjectClass

AttributeDescription: whenCreated

AttributeDescription: whenChanged

AttributeDescription: uSNCreated

AttributeDescription: uSNChanged

[Response In: 11405]

controls: 1 item

Control

controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)

SearchControlValue

size: 500

cookie: <MISSING>

Si AD trouve des utilisateurs qui correspondent aux critères détaillés dans le message de demande SEARCH, il envoie un message SearchResEntry qui contient les informations utilisateur.

Voici le message SearchResEntry :

Lightweight Directory Access Protocol

LDAPMessage searchResEntry(4) "CN=Suhail Angi,CN=Users,DC=aloksin,DC=lab" [4 results]

messageID: 4

protocolOp: searchResEntry (4)

searchResEntry

objectName: CN=Suhail Angi,CN=Users,DC=aloksin,DC=lab

attributes: 9 items

PartialAttributeList item objectClass

type: objectClass

vals: 4 items

top

person

organizationalPerson

user

PartialAttributeList item sn

type: sn

vals: 1 item

Angi

PartialAttributeList item telephoneNumber

type: telephoneNumber

vals: 1 item

1002

PartialAttributeList item givenName

type: givenName

vals: 1 item

Suhail

PartialAttributeList item whenCreated

type: whenCreated

vals: 1 item

20131222000850.0Z

PartialAttributeList item whenChanged

type: whenChanged

vals: 1 item

20131222023413.0Z

PartialAttributeList item uSNCreated

type: uSNCreated

vals: 1 item

12802

PartialAttributeList item uSNChanged

type: uSNChanged

vals: 1 item

12843

PartialAttributeList item sAMAccountName

type: sAMAccountName

vals: 1 item

sangi

[Response To: 11404]

[Time: 0.001565000 seconds]

Lightweight Directory Access Protocol

LDAPMessage searchResEntry(4) "CN=Pragathi NS,CN=Users,DC=aloksin,DC=lab" [5 results]

messageID: 4

protocolOp: searchResEntry (4)

searchResEntry

objectName: CN=Pragathi NS,CN=Users,DC=aloksin,DC=lab

attributes: 9 items

PartialAttributeList item objectClass

type: objectClass

vals: 4 items

top

person

organizationalPerson

user

PartialAttributeList item sn

type: sn

vals: 1 item

NS

PartialAttributeList item telephoneNumber

type: telephoneNumber

vals: 1 item

1000

.......

....{message truncated}..........

.....

Note: Il n'y a aucun message dans la réponse, même si cet attribut est demandé. Ceci est dû au fait que l'ID de MESSAGERIE n'a pas été configuré pour les utilisateurs de la Active Directory.

Une fois ces valeurs reçues par le CUAC, elles sont stockées dans la table SQL (Structured Query Language). Vous pouvez ensuite vous connecter à la console et la console récupère la liste des utilisateurs à partir de cette table SQL sur le serveur CUACPE.