topic Re: The UPN suffix exists, it has in IP Telephony and Phones

CUCM 11.5 authentication with LDAP - Single forest, multiple domains and UPN suffixes

fjlopezderego — Sun, 17 Mar 2019 16:25:35 GMT

Hi,

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 john.doe@lab.com, the sAMAccountName is jdoe and it is located in the domain avvid.com

Phil Doe's UPN is phil.doe@avvid.com, the sAMAccountName is phil.doe and it is located in the domain avvid.com

Jane Doe's UPN is jane.doe@test.com, the sAMAccountName is jdoe2 and it is located in the domain voice.com

Mary Doe's UPN is mary.doe@voice.com, 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?

Regards,

This will work by default

Mohammed al Baqari — Sat, 04 Feb 2017 12:51:51 GMT

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 xxx@yyyy.z 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.

Hi,

fjlopezderego — Sat, 04 Feb 2017 15:26:47 GMT

Hi,

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 -> collab1@aliascollab.es

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.

Regards

Understood. You are right

Mohammed al Baqari — Sun, 05 Feb 2017 05:12:29 GMT

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.

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

After reading this thread, I

Jonathan Schulenberg — Sun, 05 Feb 2017 20:04:17 GMT

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".

Hi Jonathan,

fjlopezderego — Mon, 06 Feb 2017 14:00:29 GMT

Hi Jonathan,

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 usuario@suffix.com that belongs to domain.com, when CUCM performs the LDAP binding, it performs the request to DC=suffix, DC=com.

Regards.

Fair enough. Then what do you

Jonathan Schulenberg — Mon, 06 Feb 2017 14:09:01 GMT

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

fjlopezderego — Mon, 06 Feb 2017 15:51:57 GMT

The UPN suffix exists, it has been created in AD Domain and Trusts but, when CUCM tries to authenticate for example user1@lab.com 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.

Re: The UPN suffix exists, it has

federico.tabbo — Mon, 30 Oct 2017 14:36:33 GMT

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

Re: The UPN suffix exists, it has

CONNECT-PS Technical — Fri, 10 Nov 2017 00:10:42 GMT

does any one solve the problem or we should use ADAM for multi forest?

Re: The UPN suffix exists, it has

anshar.ali — Fri, 24 Nov 2017 04:25:13 GMT

i tried to use adam and ldap service in cucm-->ldap

the users wont get imported to cucm for some reason

It Works!

Anthony W. — Fri, 11 Jan 2019 20:58:52 GMT

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.

Re: It Works!

franciscofossa — Wed, 04 Sep 2019 22:06:46 GMT

spaces also inside OU/DN statements will throw you aside too.