Shibboleth Developers

[Dan McLaughlin <>]

Hi Daniel,

Sorry, you are right about it being a semantic issue. :)

I only have one alias that points to a single person object.  We are
searching from the base of the LDAP tree, so I don't care about
aliases and I don't want them or the object they point returned, ever.
If deferenceAlias = always then two users with (cn=joe-c) are
returned; the user that the alias references and the user.

This is one too many, so I get the exception:


found for user: jdoe-c using filter: filter=(cn={0}),filterArgs=[]
00:12:11.502 - 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)
~[vt-ldap-3.3.3.jar:na]
       at 
edu.vt.middleware.ldap.auth.Authenticator.getDn(Authenticator.java:106)

I agree the old properties are valid, but there is some bug that is
causing aliases to be dereference regardless.  I think you would agree
the following two configuration examples should NEVER dereference
aliases.  If  dereference aliases is set to never and I search the
entire tree and I have one alias that points to one user, then only
the one user should be returned.  Correct?

I still have the old config running on several 2.2.1 IdP's and it
works fine.  If I try and use the same old config settings below and
copy them to a 2.3.0 IdP get the exception
"javax.naming.NamingException: Found more than (1) DN for: jdoe-c".
If I simply change out the old properties for the new ones then
everything starts working again and the aliases are never deferenced.

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";
>

--

Thanks,

Dan McLaughlin


NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.


On Wed, Jun 8, 2011 at 11:07 AM, Daniel Fisher 
<>
 wrote:
>
> 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