IdP Connection to Active Directory

[Nate Keegan]

Environment:

Debian Stretch, latest security update x64 VM
Shibboleth 3.4.6 as a WAR file in Jetty 9
Amazon Corretto 1.8.0 JDK

We are tasked with providing IdP services for a service provider with the
idea being that our users will access a web service provided by company X,
will use SAML/Shibboleth to login and authenticate against our Active
Directory, and return the employeeNumber attribute back to the SP.

>From an IT perspective we are strong on Active Directory, strong on Linux,
but new to SSO via something like Shibboleth as this sort of thing (SSO via
SAML) is not used much in our vertical segment in my experience.

At this point I think I have everything correct in terms of
attribute-resolver.xml, attribute-filter.xml, idp.properties, etc
configured for this type of use.

When I restart Jetty I see the following in the idp-process.log:

[LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 52e, v1db1

Google work shows this type of error is related to LDAP credentials but
running tests using the same base info via ldapsearch works across methods
- vanilla LDAP, StartTLS, LDAPS, etc.

My ldap.properties file looks like this (values changed from defaults are
shown for clarity)

# Begin ldap.properties
idp.authn.LDAP.authenticator = bindSearchAuthenticator
idp.authn.LDAP.ldapURL = ldap://some.fqhn:389
idp.authn.LDAP.useStartTLS = false
idp.authn.LDAP.useSSL = false
idp.authn.LDAP.sslConfig = certificateTrust
idp.authn.LDAP.returnAttributes = employeeNumber
idp.authn.LDAP.baseDN = CN=Users,DC=acme,DC=com
idp.authn.LDAP.subtreeSearch = true
idp.authn.LDAP.bindDN = CN=idpuser,CN=Users,DC=acme,DC=com
idp.authn.LDAP.bindDNCredential = KRSOne
idp.authn.LDAP.userFilter = (sAMAccountName={user})
...
# No change when we use StartTLS above vs LDAP for this line
idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true}
# End ldap.properties

And attribute-resolver.xml as far as the Data Connector:

# Begin attribute-resolver.xml
 <!-- Remember to remove "trustFile" and "useStartTLS" if you use plain
LDAP connection -->
  <DataConnector
    id="myLDAP"
    xsi:type="LDAPDirectory"
    ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
    baseDN="%{idp.attribute.resolver.LDAP.baseDN}"
    useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
    trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}"
    principal="%{idp.attribute.resolver.LDAP.bindDN}"
    principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}">
    <FilterTemplate>
      <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
    </FilterTemplate>
    <ConnectionPool
        minPoolSize="%{idp.pool.LDAP.minSize:3}"
        maxPoolSize="%{idp.pool.LDAP.maxSize:10}"
        blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}"
        validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}"
        validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}"
        expirationTime="%{idp.pool.LDAP.idleTime:PT10M}"
        failFastInitialize="%{idp.pool.LDAP.failFastInitialize:false}" />

    <ReturnAttributes>*</ReturnAttributes>
  </DataConnector>
#End attribute-resolver.xml

In summary I'm missing something here but it isn't clear to me what is off.

The LDAP info is correct and we aren't using an external CAS so in theory
Shibboleth should be the middle person between the SP and Active Directory.

The usual gremlins have been identified and checked out - firewalls, LDAP
credentials, OS, stack, etc and I have to be missing something but as this
is our first go round with Shibboleth I'm not sure exactly what that might
be.

Any advice or direction anyone can provide would be very appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200429/71917676/attachment.html>