Shib / ldap search base

[David Gersic]

>>> On 10/7/2014 at 12:25 PM, Dave Vernon <dvernon at loyalistcollege.com> wrote: 
> Hello again,
> 
> As you know, yesterday was an exciting day for me, getting my first 
> Shibboleth project running in my dev environment.  My users are held in a 
> Microsoft Active Directory (2008 R2 DC's, 2003 functional level).  I was 
> aware that the default search base is CN=Users so I had put my test user 
> there.

If you specify the base DN to search, then the default shouldn't matter.


> Today I went to expand that and I've run into issues.  I'd like to be able 
> to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca , so I edited 
> my attribute-resolver.xml file on my IdP, restarted the service, and tested. 

That should work. If you use something like OpenLDAP's 'ldapsearch' to replicate the search, using that search base and the same filter you're using for Shib, what do you get back?

 
> I found that it wasn't working - users NOT in the cn=users container were 
> rejected by Shib, and my test user in the cn=users container was 
> authenticated by Shib but rejected by the resource I'm protecting 
> (remote_user not set)

Rejected how? What message(s)?


> I checked the documentation I see the common cause seems to revolve around 
> refers.  The docs say that I need to set <LDAPProperty 
> name="java.naming.referral" value="follow"/> , as it is 'ignore' by default.  
> I think that's actually old information because I can verify that in my 
> instance it was set to 'follow' by default.

If you're binding to a DC, searching from the domain root, then you shouldn't be hitting any referrals anyway.


> The other fix is to search a GC instead - which is not a problem for me 
> ("horus" is a GC).  I changed my ldapURL to use port 3268 (plain old) but I'm 
> still getting the same results.  If I move a user into the cn=users container 
> they work, but if they aren't there, they won't authenticate.

Sorry,  no idea about GCs here. I just bind to a DC, specify a search base and filter, and away we go.


> Here is my attribute-resolver.xml
> 
>     <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" 
> xmlns="urn:mace:shibboleth:2.0:resolver:dc"
>         useStartTLS="false"
>         ldapURL="ldap://horus.ADS.LOYALISTCOLLEGE.CA:3268" 
> baseDN="DC=ads,DC=loyalistcollege,DC=ca" 
> principal="ldapqsvc at ads.loyalistcollege.ca"
>         principalCredential="password removed for post">
>         <FilterTemplate>
>             <![CDATA[
>                 (sAMAccountName=$requestContext.principalName)
>             ]]>
>         </FilterTemplate>
> 
>         <!-- We rely on the uniqueness of the objectSid.  But it is binary so 
> we *must* make it so -->
>         <LDAPProperty name="java.naming.ldap.attributes.binary" 
> value="objectSid"/>
>         <!-- If we are following from the GC we need thus on -->
>         <LDAPProperty name="java.naming.referral" value="follow"/>
> 
>     </resolver:DataConnector>
> 
> 
> 
> 
> And a snip from my idp-process.log
> 
> javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn


IIRC, you can turn the logging level up on the LDAP resolutions to see what's going on. See logging.xml. Crank it up to INFO or DEBUG, then look in the log file. If you're getting "Cannot authenticate dn, invalid dn" it would be helpful to know what DN the resolver is trying to use.


> Any thoughts?  I also read that I could stack multiple searches, which would 
> also work for me ( I only have 3 or 4 OUs where users are) so I tried 
> changing the base path to a specific OU where a user is, but I was also 
> unable to authenticate.

I think I read that, too, but I wouldn't bother with it. If the search from the domain root does what you want, then building something else would be suboptimal for you anyway.