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.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
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.
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.
Complétez ces étapes afin d'intégrer le CUAC à la AD et d'importer des utilisateurs à partir de la AD :
Voici un résumé du processus LDAP entre CUAC et AD :
Voici une capture de renifleur qui illustre ces étapes :
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 :
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.
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 :
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}..........
.....
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.