ldap IdP data connector issue

[IAM David Bantz]

HA! Scott's hint didn't do the trick but eventually led me to what I
believe is the root cause:
AD team rotating the private certs being presented, and me not having the
current ones.

Replacing StartTLSTrustCredential with

trustFile="/opt/shibboleth-idp/credentials/UA_AD_CA.pem"

invalidated the data connector configuration:

> Error creating bean with name 'uaADLDAP': Invocation of init method
> failed; nested exception is
> net.shibboleth.utilities.java.support.component.ComponentInitia
> lizationException: Data Connector 'uaADLDAP': Invalid connector
> configuration
> ...
> Caused by: net.shibboleth.idp.attribute.resolver.dc.ValidationException:
> [org.ldaptive.provider.ConnectionException at 1397767450::resultCode=null,
> matchedDn=null, responseControls=null, referralURLs=null, messageId=-1,
> message=javax.net.ssl.SSLHandshakeException: sun.security.valid
> ator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target,
> providerException=javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path
>  building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]


That's pretty much the process error I was seeing with prior valid but
non-functional data connector config. So that made me question validity of
the certs I refer to. Back to the directory browser to uncover the cert
being presented, and whaddayaknow: new certs being presented. I exported
and added those new certs into the .pem file and TLS connections restored.
(Leaving the mystery of why my directory browser and the jaas
authentication had continued to work...some weird long-lived cached trust?)

Of course if actually had the private CA that signs these revolving AD
certs life would run smoother, as the Shibb wiki wisely warns:

Assuming ldap-over-TLS (ldaps) or StartTLS is used, you SHOULD (and, in a
> future version of the software, MUST) configure the rules for validating
> the LDAP server's TLS key within the connector. It is possible to leave
> this to the Java runtime by relying on default behavior, but this will
> result in warnings as of V3.3.2 and will cease to function in V4.0, as this
> advisory <https://shibboleth.net/community/advisories/secadv_20171004.txt>
>  outlines.

There are generally two ways to do this:


>    - Reference a CA (Certificate Authority) that has signed the
>       certificate chain presented by the LDAP server.
>
>
>    - Reference the LDAP server's certificate explicitly.
>
> The latter provides better security but likely will require constant
> updating and coordination with the LDAP server's operational staff unless
> it relies on a longer-lived certificate.

https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector


but I've been unable so far to pry that CA cert from our AD team.

David Bantz


On Mon, Mar 25, 2019 at 11:43 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> I would have to guess you have to be mistaken about them using the same
> certificate on different ports; but FWIW you should use the simple
> trustFile="..." syntax in place of all that extra XML from the security
> namespace to just reference a certificate file.
>
> I have no problems making the same CA work for both scenarios in my
> configuration now. If trustFile works and the old syntax doesn't, then
> possibly there's a bug there.
>
> -- Scott
>
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190325/507ad25a/attachment.html>