LDAP referrals and StartTLS

[Douglas E Engert]

On 1/5/2015 9:52 PM, Wessel, Keith wrote:
> Hi, all,
>
> Wondering if anyone has seen the IDP's LDAP data connector work when using startTLS and encountering a referral. We've got a connector querying our Active Directory with a search base of the root DN.
> Microsoft surely has what they think is a good reason why queries against the root DN result in several referrals to various subtrees that the client can try.
> We've got the IDP set up to follow referrals and, when we're using LDAPS, everything works as designed. When we switch to LDAP with StartTLS, the query fails.
>
> I'm guessing that it only does StartTLS on the initial connection and, because our AD instance won't allow authentication over clear-text LDAP, the authentication to the referred connection fails. Just a theory; I've got nothing in the logs to prove that, even with the LDAP logging turned up to DEBUG, other than the fact that the AD data connector is failing. When I set this same connector's search base to something more specific than the root DN, StartTLS works fine.
>
> Is this a bug in the LDAP library? Or is there something I'm overlooking?

Sounds like a bug.

But do you really need to search the other domains in the forests?
If not you can add to the dataConnector:

     <!-- With AD DC, we throw referrals, so as not to pick up sub-domains in the forest.
         See: http://code.google.com/p/vt-middleware/wiki/vtldapAD -->
     <dc:LDAPProperty name="edu.vt.middleware.ldap.referral" value="throw"/>
     <dc:LDAPProperty name="edu.vt.middleware.ldap.handlerIgnoreExceptions" value="javax.naming.LimitExceededException,javax.naming.ReferralException"/>

If you do need info from subdomains, maybe you can use the Global catalog instead, but it only has selected attributes from the subdomains.)
In our case all user were in top level domain, and subdomains were administrated by other admins then the the top level domain. Two reasons not
to search subdomains.)

>
> Thanks,
> Keith
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>