I'm trying to integrate a CUCM 11.5 with an LDAP like this:
- One forest
- Multiple domains connected to the forest (for example, avvid.com and voice.com)
- Each domain has UPN suffixes, applied to the users, for example:
John Doe's UPN is email@example.com, the sAMAccountName is jdoe and it is located in the domain avvid.com
Phil Doe's UPN is firstname.lastname@example.org, the sAMAccountName is phil.doe and it is located in the domain avvid.com
Jane Doe's UPN is email@example.com, the sAMAccountName is jdoe2 and it is located in the domain voice.com
Mary Doe's UPN is firstname.lastname@example.org, the sAMAccountName is mdoe and it is located in the domain voice.com
With this scenario only the users with an UPN suffix that equals the domain can login. That means that Phil and Mary can login, but John and Jane can't. It is as expected according to the SRND because the CUCM sends the bind to the LDAP based on the UPN and, as long as DC=lab,DC=com or DC=test,DC=com do not exist, it fails. How can this AD be integrated? Could AD/LDS help?
This will work by default when you integrate CUCM with MS AD (for example). CUCM will forward login requests to AD for authentication. Since you are using 'LDAP Attribute for User ID' as userPrincipleName, CUCM will expect UPN user ID in login requests. If your user ID isn't in UPN forward email@example.com then CUCM won't accept authentication. If your user ID is in UPN format, CUCM will take the request and forward it to AD server. Now AD should be ready to read the user ID and based on the domain-suffix lookup in the right structure.
Best practice is to have Global Catalog server which reads the correct suffix and locate the domain accordingly to authenticate the user.
I'm using Global Catalog in fact, but it can't authenticate users with an UPN suffix that is different from the root domain.
I've reproduced the issue in my lab, the root domain is collab.es and there is an UPN alias aliascollab.es so there is one user like this:
UPN -> firstname.lastname@example.org
sAmaccountName -> collab1s
When CUCM tries to authenticate it tries to "connect" to: dc=aliascollab, dc=es, but this is not a valid domain and I suppose that this is the reason why it fails.
Understood. You are right that its not working because the suffix is different from root domain.
In this case you need ADAM/AD LDS to act as proxy and forward CUCM authentication requests correctly based on the suffix to respective server/forest.
Here is a very good document explains how that works and how to configure it.
After reading this thread, I believe your problem is that you're specifying the root of a single Tree within the Forest instead the root of the Forest. The LDAP Searce Base should be "DC=com" not "DC=lab,DC=com".
When the LDAP integration is based on UPN, you can't specify the LDAP search base, the CUCM automatically uses the UPN suffix of the user as search base. For example, there is an user with UPN email@example.com that belongs to domain.com, when CUCM performs the LDAP binding, it performs the request to DC=suffix, DC=com.
Fair enough. Then what do you mean by this statement?
It is as expected according to the SRND because the CUCM sends the bind to the LDAP based on the UPN and, as long as DC=lab,DC=com or DC=test,DC=com do not exist, it fails.
How can the suffix not exist if it's in the same AD Forest and you're pointing at a Global Catalog server/port?
The UPN suffix exists, it has been created in AD Domain and Trusts but, when CUCM tries to authenticate for example firstname.lastname@example.org where lab.com is an UPN suffix, the search request is sent from CUCM to GC using dc=lab,dc=com as base DN and the GC answers with error 10 because that is not a valid/real domain, it's just an UPN suffix.
I had this problem too, it cannot be done, AD won't find users when searched through an UPN suffix, only through their real domain.
I had to put an openLDAP proxy inbetween to rewrite domains
This worked! We had a multi-domain setup and could not use UPN due to O365 using the UPN attribute. By setting LDAP sync to mail and then setting up the LDAP directory’s, that enabled LDAP sync. Authentication we were trying what we thought was the root of DC=example, DC=local but it would not authenticate outside of the directory. By removing the DC=example and just going with DC=local, that fixed our issue. Looks funny but it works and that is all that matters. Thanks for the post!
An update to this post. It also worked for sAMAccountName as well.