Active Directory synchronization working, authentication not on CUBM BE5000 8.6(1a)

[Chad Elder]

I successfully set up Active Directory synchronization between my CUCM BE5000 appliance running 8.6(1a) and our Windows 2008 Server Active Directory.  Users are replicating successfully, but authentication is not working even though I am using the same LDAP manager distinguished name and password for both.  I have a suspicion to the cause of this problem but for the record, the following is my relevant configuration:

System/LDAP/LDAP System:

LDAP Server Type Microsoft Active Directory iPlanet or Sun ONE LDAP Server OpenLDAP Microsoft Active Directory Application Mode
LDAP Attribute for User ID userPrincipalName sAMAccountName mail employeeNumber telephoneNumber

LDAP Server Type: Microsoft Active Directory
LDAP Attribute for User ID: userPrincipalName

System/LDAP/LDAP Directory:

LDAP Configuration Name: bgctnv.local
LDAP Manager Distinguished Name: CN=cm.sync,OU=BGCTNV Users,DC=bgctnv,DC=local
LDAP User Search Base: DC=bgctnv,DC=local

LDAP Server Information: bgctnv.local, port 389 (to query any domain controller in DNS; I have also tried specific IP addresses)

System/LDAP/LDAP Authentication:

LDAP Manager Distinguished Name: CN=cm.sync,OU=BGCTNV Users,DC=bgctnv,DC=local

LDAP User Search Base: LDAP user search base is formed using the User ID information (pre-populated, I cannot change this)

LDAP Server Information: bgctnv.local, port 3268

All of my Active Directory users are now populated and active under End Users.  However, I am not able to log into /ccmuser among other things using my valid domain credentials.  I am a super user as well as a standard end user.

Curiously, invalid usernames (userPrincipalName in my case) return the error "Log on failed - Invalid User ID or Password" while a valid username, with or without the correct password, returns only "Log on failed."  That seems to imply that some part of the authentication or LDAP bind is taking place.

Here's the catch.  The base domain here is bgctnv.local while we use bgctnv.org as a valid and acceptable alternative UPN suffix in Active Directory.  Every Microsoft and every third-party program I have used will accept username@bgctnv.org, but I'm beginning to think that CM will not, or is having some sort of translation issue.  I read that alternative suffixes can cause problems in Active Directory forests with multiple trees, but this is a vanilla, single domain environment.

I don't even know where to look to debug this issue.  Has anyone seen this before or can anyone tell me where to look for logs?

Thanks,

John

[Chad Elder]

I found some logs, and I think this may prove the theory:

2011-07-06 16:42:11,701 DEBUG [http-8443-5] impl.AuthenticationLDAP - searchUserDn: performing search with userBase=dc=bgctnv, dc=org, filter=(&(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))(userPrincipalName=username@bgctnv.org)), constraints=javax.naming.directory.SearchControls@1a0ef3e

2011-07-06 16:42:12,099 ERROR [http-8443-5] impl.AuthenticationLDAP - searchUserDn: CommunicationException

javax.naming.CommunicationException: bgctnv.org:389 [Root exception is java.net.ConnectException: Connection refused]

This doesn't seem like the correct way to handle the UPN. CM seems to be making as assumption based on everything after the @.  Why can't I modify the "LDAP User Search Base," and what exactly does "LDAP user search base is formed using the User ID information" mean?

[Chad Elder]

Here is the full log that shows four connection attemps (>MAX_TRIES) and subsequent failure.

[Chad Elder]

I found the following:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/directry.html

As mentioned in the section on LDAP Synchronization, in order to support synchronization with an AD forest that has multiple trees, the UserPrincipalName (UPN) attribute must be used as the user ID within Unified CM. When the user ID is the UPN, the LDAP authentication configuration page within Unified CM Administration does not allow you to enter the LDAP Search Base field, but instead it displays the note, "LDAP user search base is formed using userid information."

This may help in some situations where there are multiple trees in an AD forest, but it is definitely not the solution.  Even with multiple trees, it is common to use alternative UPN suffixes.  Nothing in AD requires or even recommends that you exclusively use your AD domain root as the UPN suffix.

For example, company.local may use company.com as an alternative but primary UPN suffix to provide simplicity for users.  Users can then achieve more broad SSO capabilities by using their familiar email credentials when authenticating for company.local services.

When using UserPrincipalName as the LDAP synchronization attribute for the CM User ID, the configuration requires that the search base for authentication be derived from the UPN suffix, regardless of whether it is a single domain or multiple trees within a forest.  This makes it impossible to authenticate by UPN unless your UPN is explicitly your root domain name.  From the example above, CM would try to bind username@company.com against DC=company,DC=com instead of the correct DC=company,DC=local.

The logical solution would be to allow the administrator the option.  Why not have a choice of whether to generate the user search base from the userid (UPN) information, or be able to specify the search base as well like it allows with any other synchronization attribute?

Would this be a feature request, bug report, or neither?  I'd really appreciate it if Cisco considered this but I don't know the proper channel.

[Jaime Valencia]

Most likely that would be a feature request (PER) however that needs to be done via your account team.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[kif]

John, did you ever find a resolution to your problem?  I am having the same issue.

[Chad Elder]

From what I was able to determine, the behavior is by design but hopefully Cisco will take my comments into consideration in future releases.

My workaround was to use the "mail" LDAP attribute for User ID instead of "userPrincipalName."  This was synonymous for most of my Active Directory users, and I manually entered the data for objects without the attribute defined or without Exchange mailboxes.

John

[derekdinehart]

I just want to bump this post.  I am also having this issue.  CUCM and Unity Cxn can't handle alternate UPN suffixes.  The ONLY reason I need to use one at all is in an attempt to get around a RIDICULOUS 32 character limitation in the CCX Agent User ID login field.

[dshumake]

Has anyone come up a better solution.  I tried everything with no success.