18 August 2015 | Written by Nicolas Michel | Published in Unified Communications
One of my customer told me that one of its end user was not appearing in its CUCM database. I think it is worth to make a blogpost about it.
There are already plenty of resources on the subject (Example) but I will mainly focus on the troubleshooting section here.
There are 2 ways to configure your users on a Cisco CUCM, you can either configure them statically or you can synchronise your CUCM with your Active Directory Domain.
If you want to make sure that your AD – CUCM synchronization is working, you first need to check that the DirSync Service is activated on the CUCM Publisher:
Then you need to select which AD Attributes will be used as the USERID field within the CUCM. The best logical choice to me is the sAMAccountName since it will be used by the users to authenticate themselves. (Browse to System => LDAP => LDAP System)
Now you need the following:
I would advise you to use the AD “mail” field as the Directory URI CUCM field. This will be used by as a SIP URI that will be linked to the user extension. You can change this on the go if you are running 10.5.2. Otherwise you have to create a duplicate LDAP sync and then remove the old and obsolete one.
Now I can check if my users are created but I noticed that indeed, one of them was missing and I would like to understand (and fix) why !
If I want to troubleshoot this, I need to activate the debugs into the CUCM serviceability menu.
From here you have 2 options : RTMT or CLI.
I’m not an RTMT fan so I will show you the CLI way to find DirSync logs into CUCM.
The logs are located into /cm/trace/dirsync/log4j
admin:file list activelog /cm/trace/dirsync/log4j * date det
28 Mar,2015 16:28:56 0 DirSyncThreadDump.log
14 Aug,2015 14:45:55 36 dirsync_err.bin
14 Aug,2015 15:09:16 36 dirsync.bin
14 Aug,2015 16:46:43 69,418 dirsync00002.log
==== We will look at dirsync00002.log which is the only log file available ====
==== .After you type the next command, go back to the LDAP directory menu and click on "Perform Full Sync Now". ====
==== This will trigger the Sync and we will see the logs ====
==== I will simplify the logs for the sake of clarity ====
file tail activelog /cm/trace/dirsync/log4j/dirsync00002.log
[DSLDAPSyncImpl] Manager DN=cn=cucmservice,ou=Service Accounts,dc=customer,dc=local
[DSLDAPMain] security.Log4jEncLogger (Log4jEncLogger.java:29) - Entering decryptPassword
[DSLDAPMain] security.Log4jEncLogger (Log4jEncLogger.java:29) - Use Dkey to decrypt data
[DSLDAPMain] security.Log4jEncLogger (Log4jEncLogger.java:29) - CCMENC::ERROR : Dkey decryption failed. Use recovery mechanism to decrypt data.
[DSLDAPMain] security.Log4jEncLogger (Log4jEncLogger.java:29) - Using static key to decrypt data
[DSLDAPMain] security.Log4jEncLogger (Log4jEncLogger.java:29) - decryptPassword was successful
[DSLDAPMain] ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:236) - LDAPSync(97c6023b-f0fb-c14b-2a35-9d924020123c)[DSLDAPSyncImpl] Directory type=1
2015-08-14 15:10:28,911 INFO [DSLDAPMain] ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:2252) - [createDBAttrVector] DB attribute names= uniqueidentifier,userid,firstname,middlename,lastname,manager,department,telephonenumber,mailid,title,homephone,mobile,pager,ocsprimaryuseraddress,directoryuri,discoveryuseridentity,
==== You can see above what are the synchronised field ====
Now you have to search for “roy” into your debugs to find why the user is being rejected:
DSDBInterface.updateUserInfo For User :roy DB ERROR: MailID entered for EndUser already exists.
DSDBInterface.updateUserInfo LDAP data discarded: Missing LDAP attribute: Attribute Count=5 AgreementId=97c6023b-f0fb-c14b-2a35-9d924020123c
[userid, firstname, mailid, uniqueidentifier, discoveryuseridentity]
DSDBInterface.setUserInactive Found 0 users in database needing update
ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:433) - LDAPSync(97c6023b-f0fb-c14b-2a35-9d924020123c)[Run] Successfully completed full sync
You can see that there is another EndUser that has the same MailID field so the CUCM does reject the synchronisation for the real user named “Roy”.
There are many other reason why the CUCM can reject a user from the synchronisation process. The most common one is when you do not enter one of the mandatory field: FirstName of LastName.
Also I recommend to read some really important LDAP Design considerations from the Cisco 10.x SRND Design Document
If you have any comments or questions, do not hesitate to post a comment.