MAC LDAP Search

[larrymetzger]

I am using CUP 8.6(4) with CUCM 8.6(2a) and MS AD. I have CUCM configured to sync the database and authenticate using LDAP. The AD account provided by the AD team is a service account for UC and works fine for CUCM database access as well as Jabber for Windows. When I use the same account for Jabber on MAC or iPad, the user sees Invalid Credentials. If I use my AD account (which is configured with the same access on AD), the LDAP search works and no problems. I'm using the UPN user name in CUP LDAP profile and I'm using the DN in CUCM. Windows jabber-config.xml uses the userID directly.

Can anyone offer options on what could cause an account not to work on MAC/iPad? (it works on Windows)

Why does a different account work perfectly (same settings)?

Is there a Log on MAC that can provide more details on the "Invalid Credentials" message?

Thanks in advance for any assistance.

[JayGrimes1]

Enable detailed Logging under Help. Log out and then back in. Go back to help and "Report a Problem". That should give you some detailed logs to look through.

[Bo Gao]

Please double check your LDAP Profile settings, making sure your Bind Distinguished Name (DN) and password are correct.  According to the SRND of CUPS, you need to use the format of username@domain.com for Distinguished Name.

[Paul McGurn]

Were you able to resolve this?  I'm getting the same behavior.  In the Mac Jabber log, it's noting LDAP error 49.  We've tried:

• LDAP username with A-Z characters only
• Weaker LDAP password
• LDAP username configured as user@domain.tld

[Aaron Harrison]

Could be unrelated, but here's some stuff that doesn't seem to work nice on macs:

- Using TCP 389 on some OSX vers seems hit and miss. Switching to 3268 for the GC works more consistently.

- Having an LDAP filter embeeded in the LDAP profile (on the search base) seems to break some of the Jabber mobile clients and mac.

- I use DN to bind in CUPS... not UPN.

Aaron

[Paul McGurn]

Hi,

Thanks for the reply.

Using 3268/Global Catalog

Using UPN, per Cisco SRND for CUPS.  DN was used in the beginning, but neither had a positive impact either way.

[larrymetzger]

I opened a TAC case and the engineer found this bug CSCuc06732. It talked about the & character causing issues with the login. I subsequently found it was more than just the & that caused issues with Jabber for MAC authentication. We also found < or > caused the failure as well. I would try a password with just basic alphanumeric and see if it works. Then you can adjust.

You do need UPN (user@domain) for authentication. I was using Global Catalog 3268.

[Paul McGurn]

I must be hitting some other bug.  I'll have to open a TAC case as well.  We've tried UPN with an overly weak password to rule that out.

[emikelso]

I had the same issue described here. As soon as I removed the & from the password everything was fine. (the bug was filed after my case so I wonder if I helped find it.)

Then, I switched to LDAPS on both CCM and CUPS. It broke again.

First, the CUP directions for installing the certificate are incorrect.

description:

CM 8.6.2(a)SU2

CUP 8.6(4)SU2

CM configured for AD integration over 636 SSL

CUP configured for AD integration over 636 TLS

All certs are signed by CA

I can log in and authenticate to the admin page to both systems via AD

I can log in to Jabber for MAC, but the directory search says 'invalid credentials'

I can log in to Jabber for Windows and search just fine, but the protocol says LDAP, so it probably fails back to unsecure when it can't connect?

Again, This works without LDAPS for MAC, but not with it enabled.

This is what I followed for the CUPS cert install.

1. Get the Root CA certificate and upload to CUCM as Tomcat-Trust. Restart Tomcat service on CUCM
2. Get the Root CA certificate and upload to CUPS as Tomcat-Trust. Restart Tomcat service on CUPS
3. Generate tomcat CSR from CUCM. Copy the entire string including the hashes and get it signed by CA for web server
4. upload it back to CUCM as Tomcat and Restart Tomcat service on CUCM
5. Generate tomcat CSR from CUPS. Copy the entire string including the hashes and get it signed by CA
6. Upload it back to CUPS as Tomcat and restart Tomcat service on CUPS

Not sure if this is the issue or if it is still special characters in my password. I have validated that none of the following are in my AD bind password:

&, <, >, /, \