<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Our IdP uses two different LDAP stores for both authN and attribute retrieval. This weekend the operators of one of them (AD) switched to use of SSL certificates from a private CA without notice to relying services, which broke the ability of the IdP to use that service. <div><br></div><div>The login module describes how to import a self-signed cert (or, presumably signed by a private CA)<br><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass</a> using keystone.</div><div><br></div><div>Three questions:</div><div><br></div><div>(1) Will this affect ONLY the login portion, or will this also enable use of the same LDAP in attribute resolution? </div><div><br></div><div>(2) The syntax of the statement is that the certificate itself is imported using keystone, not the CA certificate. I am told that part of the process of using these private CA certificates is to automatically create and put in place new certificates on a routine daily basis, so the IdP would need to import a new certificate every day to use this AD LDAP source.</div><div><br></div><div>(3) Logs show that the IdP successfully authenticates users against the other LDAP, and successfully retrieves users' attributes from that directory. However, the failure to bind to the AD LDAP during attribute resolution aborts the attribute resolution process, so that no attributes at all are encoded in the SAML assertion. Is there a way to configure the IdP attribute resolution to be less fragile - that is, to enable encoding and release of those attributes that can be resolved without the second AD LDAP?</div><div><br></div><div>David Bantz</div></body></html>