cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1627
Views
0
Helpful
4
Replies
Highlighted
Beginner

local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

We are migrating from NEC phones to a Cisco IP telephony environment.  Everything has been going fairly well, although there were a couple humps due to us having a .local domain environment, however with split dns and certificates everything has been pretty smooth until now.

Trying to get Jabber to work and users can't login situation is such:

Jabber Diagnostics

Discovery Outcome Failure: FAILED_UCM90_CREDENTIALS_NOT_SET
Domain Controller \\DC1.company.local
Edge Domain company.com
Edge Required No
Edge Visibility Not Visible
Excluded Services None
FIPS OFF
Internal Visibility Visible
Services Domain company.com
Services Domain Source Windows User Principal Name (UPN)
UPN Enabled: user@company.com
Voice Services Domain company.com
 

 

I am being told I need to rename the domain from .local in order to fix these issues. Can anyone verify this, this involves a lot more work and I will have to completely get rid of Exchange on Premises and rebuild it, because Exchange cannot take a domain name change.

1 ACCEPTED SOLUTION

Accepted Solutions
Beginner

Re: local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

Ok, sorry to get back here so late, but the issue was thus:

 

Even internal users could not connect, when cisco was running LDAP queries in order to authenticate, it was returning with 0 results no matter the user.

 

In this case company.com was using OUs to group users into locations and departments, which is a common practice, but all of them were residing at the top level of the domain company.local . The search base suggested by the company was to use the whole forest since it is a smaller <150 user company.  Search Base was entered as DC=company,DC=local .  This worked fine to import all AD users with 0 issues.  However when it came to LDAP authentication it did not and would not.  It was not resolved until at least a CN or OU was specified.  Once this was done, authentication happened without a hitch.

 

This had no bearing on ".local" vs ".com" because the split dns was indeed set up right, however it was due to Active Directory Structure and search base.

View solution in original post

4 REPLIES 4
Highlighted
Hall of Fame Cisco Employee

Re: local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

Are you syncing users from LDAP?

Or are they local users?

What's the JID for your deployment?

HTH

java

if this helps, please rate
Highlighted
Beginner

Re: local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

Are you syncing users from LDAP?

 

Yes

 

Or are they local users?

 

No they are being synced via LDAP from ADDS, parent domain is company.local. In order to get certs for CUCM and all the rest of the equipment, I incorporated split DNS for company.com.

 

Users are all set to login on company.local domain with the upn of @company.com

 

Highlighted
Hall of Fame Cisco Employee

Re: local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

So, what does their JID look like?

HTH

java

if this helps, please rate
Beginner

Re: local login to Jabber not working Failure: FAILED_UCM90_CREDENTIALS_NOT_SET

Ok, sorry to get back here so late, but the issue was thus:

 

Even internal users could not connect, when cisco was running LDAP queries in order to authenticate, it was returning with 0 results no matter the user.

 

In this case company.com was using OUs to group users into locations and departments, which is a common practice, but all of them were residing at the top level of the domain company.local . The search base suggested by the company was to use the whole forest since it is a smaller <150 user company.  Search Base was entered as DC=company,DC=local .  This worked fine to import all AD users with 0 issues.  However when it came to LDAP authentication it did not and would not.  It was not resolved until at least a CN or OU was specified.  Once this was done, authentication happened without a hitch.

 

This had no bearing on ".local" vs ".com" because the split dns was indeed set up right, however it was due to Active Directory Structure and search base.

View solution in original post

CreatePlease to create content