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

Question

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 [email protected], 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

Answer 1

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 [email protected] 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.