Issues with CUCM Admin login using LDAP

[vinaykumar8143]

Hello,
I'm having an issue with user authentication when end user account accounts are synced using LDAP . Hope someone would be able to help.

AD Setup:
Single forest with multiple onpremise child domains (ad.example.com, ap.example.com, eu.example.com)

I have configured 3 LDAP directories in CUCM and pointed to respective controllers of each child domain. Using filters, accounts are synched to CUCM and Im able to see the accounts in CUCM End users. All good so far.

Have configured LDAP Authentication but only one Authentication can be configured as its CUCM design restriction. If I mention user search base DC=ad,DC=example,DC=com and pointed to controller of this child domain, all the users fetched from this child domain are able to login and working fine but User accounts synced from other child domains are unable to login this might be expected as per SRND.

Can someone help what could be solution here ?
I have tried pointing to a GC (Global Catalog) server with user search space modified to DC=example,DC=com, it did not work. None of the users are able to login irrespective of the domain.

[Carlo Poggiarelli]

Hi,

If your LDAP acts as Global Catalog using just Example.com should do the trick.

Please let me know 

Regards

Carlo

[yasodasanjel]

You can try a workaround by creating a separate LDAP authentication source for each child domain in CUCM. This way, you can configure multiple sources, each pointing to the respective child domain controller. Users from different child domains should be able to log in by selecting the appropriate LDAP source during login.

This approach should allow you to accommodate users from multiple child domains while working within CUCM's limitations.

[Roger Kallberg]

You cannot have multiple LDAP authentication configurations in CM. So I don’t see how your suggestion would work. Can you please elaborate?

[Nithin Eluvathingal]

DC=example,DC=com must work if it's another domain in the same forest. 

If they are separate forest the below should work for you. 

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-80/111979-ucm-multi-forest-00.html

[Jonathan Schulenberg]

Which attribute are you mapping as the username? A multi-domain forest should be User Principal Name, not samAccountName. The former is unique across the forest while the latter is only unique per-domain. If you’re following current Microsoft recommendations that should be the same as their email address. That should allow the Global Catalog to uniquely match the correct account.

Another possibility, although I would have expected this to impact the sync as well, is that the Domain Controller is requiring TLS to bind/authenticate. See KB4520412. If using TLS the DC self-signed certificate (which only last a year) or the issuing CA chain must be uploaded to Tomcat-trust.

[vinaykumar8143]

Thanks for the responses.
I have tried both samAccountName and UPN with LDAP Authentication pointing to a Global Catalog on port 3268. Im not using Secured as the certificate is not imported yet, wanted to test without SSL first and later move to SSL based auth.
Post my login attempt, I've verified Tomcat security logs and below is the error I'm seeing

2023-10-29 14:23:21,922 ERROR [http-nio-1025-exec-88] impl.AuthenticationLDAP - searchUserDn: CommunicationException
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-03152EB5, problem 2001 (NO_OBJECT), data 0, best match of: ];

[Maren Mahoney]

Do you have trust relationships configured between the domain you are pointing LDAP Authentication to and the child domains? And, as @Jonathan Schulenberg mentioned, you will need to map UPN as the alias. Also, in your LDAP Authentication are you referring to the root of the forest or the root of the tree?

Maren

[Roger Kallberg]

If you have multiple domains you need to use AD LDS as outlined in the document that @Nithin Eluvathingal linked to in an earlier response.

[Jonathan Schulenberg]

You only need AD LDS if there are multiple forests. Multiple domains, even multiple trees, within the same forest is supported without LDS. You have to use UPN as the username attribute though. M365 best practices call for the UPN to be the same as the user’s email address, so it shouldn’t be a cryptic thing users don’t know anymore.