nks,
>
> -Ryan
>
>
> --
> From: philip.wale...@polycom.com
> To: ryanh...@outlook.com
> CC: ealeather...@gmail.com; cisco-voip@puck.nether.net
> Date: Mon, 5 Oct 2015 06:23:49 -0700
>
> Subject: Re: [cisco-voip] ldaps authentication
>
> Going
C: ealeather...@gmail.com; cisco-voip@puck.nether.net
Date: Mon, 5 Oct 2015 06:23:49 -0700
Subject: Re: [cisco-voip] ldaps authentication
Going beyond putting the CN in the SAN, based on many experiences, wildcards
(while technically legal in a csr or signed cert) cause all kinds of havoc
exactly l
on, 5 Oct 2015 09:03:08 -0400
Subject: Re: [cisco-voip] ldaps authentication
From: ealeather...@gmail.com<mailto:ealeather...@gmail.com>
To: ryanh...@outlook.com<mailto:ryanh...@outlook.com>
CC: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Thanks Ryan those are good su
pecially if the cert on the
directory server has recently changed; would be the equivalent of a "ipconfig
/flushdns" in the windows world, although a bit more impactful ;).
Thanks,
-R
Date: Mon, 5 Oct 2015 09:03:08 -0400
Subject: Re: [cisco-voip] ldaps authentication
From: ealeath
Thanks Ryan those are good suggestions.
CN is not in the cert, that much I can see from the trace files:
impl.Certificates - getCNs :
impl.LDAPHostnameVerifier - check : cns = [*.wvu.edu]
impl.Certificates - getDNSSubjectAlts :
impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu, wvu.edu]
Ed,
You may need to make sure that the common name of the ldap server also appears
in the subject alternative name (SAN) of the certificate.
ldap dirsync will come from the cucm publisher node but ldap auth could
potentially come from any cucm node.
My other thoughts besides a cert issue would
Hello!
We turned up directory sync on cucm yesterday, and ran into some issues
with authentication; I ran out of maintenance window so we ended up
converting the small number of end users that were synced back into local
accounts for now.
Our LDAP is front-ended by a load balancer that uses a wil
