IdP Connection to Active Directory

[Nate Keegan]

Thank you for the response, very much appreciated.

Thinking out loud while going through your response...

Our AD is a single forest and domain so referrals aren't needed versus
having a couple of different AD domains crammed in a single forest.

I have seen tutorials/references that use bindSearchAuthenticator with AD
and some that use the adAuthenticator. I'm pretty sure in testing we have
tried both ways with the resulting adjustments to the bind username format.

I will check out idp.authn.LDAP.returnAttributes as that might be part of
the problem maybe...

I have been playing the latest KRS-One mixtape with Kid Capri non-stop all
week so I'm good with dedicating brain bandwidth to old school hip hop.
Wanted a dummy password and that is at the front of my mind currently.

I'm pretty sure I provided a sanitized example for vanilla LDAP but we are
actually using StartTLS, will verify that as the data connector I showed
with the config here is a mismatch. Will verify that to make sure I didn't
mix and match methods improperly as far as the options.

Will also track down the ReturnAttributes tag to make sure that is correct.

Once I square all of that away I will run some tests with tcpdump with
ldapsearch vs Shibboleth to see if there is some difference in what is
going out over the wire to AD, might help isolate down something nuanced
which I'm missing in formatting an option in ldap.properties.


On Wed, Apr 29, 2020 at 12:16 PM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Nate Keegan <nate.keegan at gmail.com> [2020-04-29 19:25]:
> > our users will access a web service provided by company X, will use
> > SAML/Shibboleth to login and authenticate against our Active
> > Directory
> [...]
> > [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
>
> No need for Google (or other web searches), result code 49 means
> "invalidCredentials", straight from the LDAP specification:
> https://tools.ietf.org/html/rfc4511#section-4.1.9
>
> The rest of that message /may/ give some additional details, though,
> you'd have to either search for those or use the MS-AD documentation.
>
> > running tests using the same base info via ldapsearch works across
> > methods - vanilla LDAP, StartTLS, LDAPS, etc.
>
> Java seemingly behaves differently than the OS's ldapsearch.
> That happens, e.g. when referrals are involved. Is the MS-AD a single
> system? Or part of a larger "forrest" or whatever they call it?
>
> But start by lookup up those weird codes MS-AD returned with the
> invalidCredentials response. Those may or may not include more info.
>
> > idp.authn.LDAP.authenticator = bindSearchAuthenticator
>
> Why not use the adAuthenticator when using MS-AD?
> Just wondering.
>
> > idp.authn.LDAP.returnAttributes = employeeNumber
>
> Don't change that. This doesn't do what you think it does.
>
> > idp.authn.LDAP.bindDNCredential = KRSOne
>
> A fan of old-school hip hop?
>
> >  <!-- 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}">
>
> Funny. Do you notice the comment on top that says:
>   Remember to remove "trustFile" and "useStartTLS" if you use plain
>   LDAP connection
> That's there so that you remember to remove the lines with "trustFile"
> and "useStartTLS" (still there above) if you use plain LDAP
> connections.
>
> >     <ReturnAttributes>*</ReturnAttributes>
>
> If employeeNumber is literally the only thing this IDP will ever
> return from LDAP that's where you'd put it. Then LDAP will only ever
> be asked for that and nothing else.
>
> Since you're not using any form of transport security it should be
> easy to make out the difference when using ldapsearch vs using Java,
> e.g. using tcpdump and then feeding that into a wireshark GUI.
> You can also add more command line options to ldapsearch, d.g. -d-1
> which will tell you pretty much everything tcpdump would, though not
> in a form that's easily comparable with what Java does.
>
> -peter
> --
> 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/20200429/fd5c9aa0/attachment.html>