Shibboleth Developers

[Daniel Fisher <>]

On Wed, Jun 8, 2011 at 1:36 AM, Dan McLaughlin
<>
 wrote:
> Everything I'm reading on dereferencing of aliases stats that to
> "deference" means "To access the thing to which a pointer points, i.e.
> to follow the pointer."

Yes, if you follow the pointer the alias is not returned. Whatever
entry it points to is returned.

> I don't want aliases to be followed or
> searches will return the alias and the person (which is too many
> results).

No, if aliases are followed they are not returned. Based on your
comments below we seem to have a semantic issue. When you say 'alias'
I assume you mean the entry with objectClass=alias. What you really
mean is the entry the alias points to?

> (BTW... countLimit=1 is another workaround I've found).

That could produce indeterminate results since LDAP result sets are
not ordered. You couldn't guarantee which entry you are getting.
(unless eDir has some support for ordering)

> So a search for with dereference alias=always for
> (&(cn=jdoe-c)(objectclass=person)) will return both the person that
> the alias jdoe-c points to and the actual person jdoe-c.
>

Ok, I think I'm starting to understand your schema. jdoe-c actually
has (3) entries in your directory. The one you want, an alias to one
you don't want, and the one you don't want. Could you post the LDIF
for the two entries with objectclass=person just so I'm clear on this?

> This returns more than one result an the following error occurs:
>
> 23:10:40.458 - DEBUG
> [edu.vt.middleware.ldap.auth.SearchDnResolver:151] - Multiple results
> found for user: jdoe-c using filter:
> filter=(&(cn={0})(objectclass=person)),filterArgs=[]
> 23:10:40.465 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164]
> - Error occured attempting authentication
> javax.naming.NamingException: Found more than (1) DN for: jdoe-c
>        at 
> edu.vt.middleware.ldap.auth.SearchDnResolver.resolve(SearchDnResolver.java:156)
>

Ok, this makes sense now. The alias was followed and you got back the
entry you want and the entry you don't want. I've been working under
the assumption that the alias pointed to the entry you want.

> Once I go back and set dereference aliasing back to never, then the
> aliases no longer return and login is successful...
>

Yes, the aliasedObject is not dereferenced. We may actually be on the
same page now.

>
> But here is the odd thing, which is what originally caused me to post
> to this thread...
>
> Simply reverting the ldap properties in the login config so they match
> the example, has the same affect as if I had set dereference aliases
> to always.
>
> New way works...
>
>   edu.vt.middleware.ldap.jaas.LdapLoginModule required
>     ldapUrl="ldap://ldap01:636";
>     ssl="true"
>     baseDn="T=MYBASEDN"
>     subtreeSearch="true"
>     derefAliases="never"
>     userFilter="(&(cn={0})(objectclass=person))";
>
> Old way doesn't work...
>
>  edu.vt.middleware.ldap.jaas.LdapLoginModule required
>      host="ldap://ldap01:636";
>      port="636"
>      base="T=MYBASDN"
>      ssl="true"
>      userField="cn"
>      subtreeSearch="true"
>      derefAliases="never";
>
> Note that in both cases I have derefAliases = never, but using the old
> parameters fails because the alias is followed and I get 2 results.

This alias isn't followed since you've set derefAliases to never. The
only difference here is the (objectclass=person) filter. So in this
case you are getting the entry you want and the alias entry, since the
filter doesn't exclude it. Based on what I know about your schema, I
can't think of any reason this would have worked in 2.2.1. Do you mean
2.1.x? Do your LDAP logs shed any light on this?

> The exact same properties work just fine with the old version of
> vt-ldap that shipped in IdP 2.2.1.  I still haven't been able to
> explain this behavior, but like I stated earlier, I'm not sure this is
> even valid since the old properties aren't even mentioned in the docs
> anymore.

The properties are valid, they are just deprecated.

--Daniel Fisher