Highlighted
Absent Member.
Absent Member.
676 views

LDAP search unable to find all expected results


Hi,

I'm developing an LDAP user-authentication connector for our
application (in Java). Through testing with Apache Directory,
I know for a fact that in the LDAP directory for a search string such
as "(&(objectclass=*)(cn=<user_login>))" for a certain user,
two entries are found (identical, that is: same dn's, same attributes,
same values), whereas for other users only one entry will be recovered.
This is correct (verified with the LDAP administrator).

The login procedure for the former cases consists in performing a seach
for the specified user login, and in those cases where
more than one entry is retrieved, several successive connects (with the
obtained user's DN and his passwd) should be attempted; if
the first connect attempt fails, the second DN should be attempted,
etc.

My problem consists in that, for the case of the 'repeated' entries,
the search performed through Novell's own API only retrieves
one, and not both, results.

The code-extracts look like this:

// Finding the user(s) for a particular login
Collection<LDAPEntry> entries = new ArrayList<LDAPEntry>();
LDAPConnection con = connect(); // Connect as LDAP administrator
String searchFilter = "(&(objectclass=*)(cn=<user_name>))"
String attrs[] = getSearchLDAPAttrs();
if (con != null) {
try {
//Only ever retrieves 1 result, should in some cases return 2
//LDAPUsersOU="o=<base>", LDAPScope=2
LDAPSearchResults searchResults = con.search(LDAPUsersOU, LDAPScope,
searchFilter, attrs, false);
while (searchResults.hasMore()) {
entries.add(searchResults.next());
}
} catch (LDAPException e) {
log.error("Error trying to find entries for login: " + login, e);
}
}
disconnect(con);
return entries;

// Trying to obtain bound connections
Collection userEntries = . . . //SEE ABOVE
for (Iterator<LDAPEntry> it = userEntries.iterator(); it.hasNext();
) {
LDAPEntry userEntry = it.next();
String dn = userEntry.getDN();
// Try to obtain a bound connection for this user and verify this
way login and password
LDAPConnection con = connect(dn, password);
if (con != null) {
// If the connection is != null then it's valid (checked inside
connect(login,passwd))
}
disconnect(con);
}

// connect(login,passwd)
LDAPConnection con = null;
try {
// use PoolManager
con = pool.getBoundConnection(login,
password.getBytes("UTF-8"));
} catch (LDAPException e) {
log.error("Unable to connect or wrong password for user with
login " + login);
} catch (Exception e) {
log.error("Exception trying to login: ", e);
}
if (con != null && con.isConnected() && con.isBound()) {
LDAPSearchConstraints sc = new LDAPSearchConstraints(new
LDAPConstraints(LDAPConnectionValue, false, null, 0));
sc.setBatchSize(0);
con.setConstraints(sc);
if (isDebug) log.debug("Obtained shared bound connection from
pool for login " + login + ".");
return con;
}

I've changed the constraints from the 'normal' LDAPConstraints to
LDAPSearchConstraints in order to set the batchsize to 0, but
without changes.
If anyone has any suggestions or ideas, they'll be greatly
appreciated!!
Thnx!!


--
polymita_jan
------------------------------------------------------------------------
polymita_jan's Profile: http://forums.novell.com/member.php?userid=100920
View this thread: http://forums.novell.com/showthread.php?t=428269

Labels (1)
0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results

Could there be Alias objects (for containers or users) that cause the
multiple matches?

Check also setReferralFollowing() on
http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPConstraints.html
By default, Novell JLDAP does NOT follow referrals


Why are you using "(objectclass=*)" in your filter? It won't have any
effect, and you might rather use "(objectclass='organizationalPerson')"

Wolfgang

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results


Hi Wolfgang,

W/ respect to your answer:

>Could there be Alias objects (for containers or users) that cause the
>multiple matches?


I'm not 100% sure, although according to what I've googled so far, an
alias should have at least these attributes "objectclass: alias" and
"objectclass: extensibleObject", which is not my case. The strange thing
is that both entries are exactly identical (no idea why this is)

>Check also setReferralFollowing() on
>'LDAPConstraints (LDAP Classes)'

(http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPConstraints.html)
>By default, Novell JLDAP does NOT follow referrals


I'll definitely look into this.

>Why are you using "(objectclass=*)" in your filter? It won't have any
>effect, and you might rather use

"(objectclass='organizationalPerson')"

I've tried with organizationalPerson and inetOrgPerson, but with the
same results

Jan


--
polymita_jan
------------------------------------------------------------------------
polymita_jan's Profile: http://forums.novell.com/member.php?userid=100920
View this thread: http://forums.novell.com/showthread.php?t=428269

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The objectclass query is needless as a '*' since every object will match
(no possible performance increase) but matching on a user/inetorgperson
class, if you have a Value Index on the objectClass attribute, could give
you a performance increase which is always nice. If you already have an
index on the 'cn' attribute then having another condition on objectClass
may also be needless but could help if you have other objects of a
different class with the same name

With regard to your original issue, alias dereferencing, as Wolfgang,
mentions, is probably the culprit. You can set dereferencing to be
'never' from the client side of your LDAP connection which I think (but am
not sure) will trump the server's default setting.

ldapsearch -h serverHere -p 389 -D cn=admin,ou=context,o=goes,dc=here -x
- -a never '(&(objectclass=inetorgperson)(cn=<user_login>))' dn

The '-a never' says to never dereference.

Good luck.





On 12/16/2010 10:36 AM, polymita jan wrote:
>
> Hi Wolfgang,
>
> W/ respect to your answer:
>
>> Could there be Alias objects (for containers or users) that cause the
>> multiple matches?

>
> I'm not 100% sure, although according to what I've googled so far, an
> alias should have at least these attributes "objectclass: alias" and
> "objectclass: extensibleObject", which is not my case. The strange thing
> is that both entries are exactly identical (no idea why this is)
>
>> Check also setReferralFollowing() on
>> 'LDAPConstraints (LDAP Classes)'

> (http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPConstraints.html)
>> By default, Novell JLDAP does NOT follow referrals

>
> I'll definitely look into this.
>
>> Why are you using "(objectclass=*)" in your filter? It won't have any
>> effect, and you might rather use

> "(objectclass='organizationalPerson')"
>
> I've tried with organizationalPerson and inetOrgPerson, but with the
> same results
>
> Jan
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNClEJAAoJEF+XTK08PnB59M0P/R/4weJ6P8Z2Alr8Qf1rThGf
5E6Om1JfgEUcIbOKNYvsZyFbaFv+zZq7LKkuo2VsXsLzU4gkwEQSWYHVKXMBOd9U
gBYM2jlMCe8t6eP/5RnySsTsfLYmrCCn+e0w4GGuJymbxl5+mh0kXDanONgB9Ki+
a84TYHNGJ431fnZ4zYVjZ0yQEzyePp03240NMiyvzk5sOvnyhrCwuWcjU+1nGdIk
dTUFRxARujn5myply1a9rNoDyTP5zSqfnxkE3DUvyp2w5o+08qwwjiDHNcToMLxi
x9w0522BqzogcD5Fo8LPGh7lNohbU3T81Q6SlVg6i42CpKcAKFLA8GE+pBVuJPsh
Cnz0J5rGZYWpQILJ+vEsBoREckyUeZk1wjF2JiAIS/VArRq7rAJjTDK10N1hyZ9J
b/HCHpxgojrRRrSrc+RpxcCuPv2HcVrpEZ9Y0hjAwMH/K82ue4kIo2ygPn5ZWe+O
50H9Qr7SzLs8FhtsB3lCA1xdXzHedwp7XyrmUNXQFCpvk9N+9cMEV2O82PGw0Wei
YQR7PrYmyYtEgak1fly+wmfgkCdAEsC37TyLKYrlWLMRt+aKHC7iZeVSfEQTZdRC
Xw5gyNafgCTC2kafbLrgZkmJQbiRInBWZuxyfne6lr3BF4+iZjSR5LnX3Yd0tN5V
p+7eNNGLcAkdcrxy5fiJ
=KKn9
-----END PGP SIGNATURE-----
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results


Hi,

Since Wolfgang mentioned that NOVELL by default never dereferences (the
concept of dereferencing is b.t.w. a tad obscure to me 😐 ), I tried
putting it to ALWAYS, doing

LDAPSearchConstraints sc = new
LDAPSearchConstraints(new LDAPConstraints(LDAPConnectionValue, false,
null, 0));
sc.setBatchSize(0);
sc.setDereference(LDAPSearchConstraints.DEREF_ALWAYS);
con.setConstraints(sc);

This achieved that I now recover 2 entries, as I was supposed to, but
since they're completely identical, my subsequent attempts to obtain a
bound connection with both recovered DN's (logically) fail, since the DN
is the same.
Anyone know what the point is of having two entries in anLDAP with the
same DN, if any?

Thanks for your help guys!
Jan.
ab@novell.com;2057454 Wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The objectclass query is needless as a '*' since every object will
> match
> (no possible performance increase) but matching on a
> user/inetorgperson
> class, if you have a Value Index on the objectClass attribute, could
> give
> you a performance increase which is always nice. If you already have
> an
> index on the 'cn' attribute then having another condition on
> objectClass
> may also be needless but could help if you have other objects of a
> different class with the same name
>
> With regard to your original issue, alias dereferencing, as Wolfgang,
> mentions, is probably the culprit. You can set dereferencing to be
> 'never' from the client side of your LDAP connection which I think (but
> am
> not sure) will trump the server's default setting.
>
> ldapsearch -h serverHere -p 389 -D cn=admin,ou=context,o=goes,dc=here
> -x
> - -a never '(&(objectclass=inetorgperson)(cn=<user_login>))' dn
>
> The '-a never' says to never dereference.
>
> Good luck.



--
polymita_jan
------------------------------------------------------------------------
polymita_jan's Profile: http://forums.novell.com/member.php?userid=100920
View this thread: http://forums.novell.com/showthread.php?t=428269

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results

The second entry is probably an alias - dereferencing means, that the alias
is not treated as alias, but just like the aliased object - hence the
duplicates

Wolfgang

"polymita jan" wrote in message
news:polymita_jan.4m2u43@no-mx.forums.novell.com...


Hi,

Since Wolfgang mentioned that NOVELL by default never dereferences (the
concept of dereferencing is b.t.w. a tad obscure to me 😐 ), I tried
putting it to ALWAYS, doing

LDAPSearchConstraints sc = new
LDAPSearchConstraints(new LDAPConstraints(LDAPConnectionValue, false,
null, 0));
sc.setBatchSize(0);
sc.setDereference(LDAPSearchConstraints.DEREF_ALWAYS);
con.setConstraints(sc);

This achieved that I now recover 2 entries, as I was supposed to, but
since they're completely identical, my subsequent attempts to obtain a
bound connection with both recovered DN's (logically) fail, since the DN
is the same.
Anyone know what the point is of having two entries in anLDAP with the
same DN, if any?

Thanks for your help guys!
Jan.
ab@novell.com;2057454 Wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The objectclass query is needless as a '*' since every object will
> match
> (no possible performance increase) but matching on a
> user/inetorgperson
> class, if you have a Value Index on the objectClass attribute, could
> give
> you a performance increase which is always nice. If you already have
> an
> index on the 'cn' attribute then having another condition on
> objectClass
> may also be needless but could help if you have other objects of a
> different class with the same name
>
> With regard to your original issue, alias dereferencing, as Wolfgang,
> mentions, is probably the culprit. You can set dereferencing to be
> 'never' from the client side of your LDAP connection which I think (but
> am
> not sure) will trump the server's default setting.
>
> ldapsearch -h serverHere -p 389 -D cn=admin,ou=context,o=goes,dc=here
> -x
> - -a never '(&(objectclass=inetorgperson)(cn=<user_login>))' dn
>
> The '-a never' says to never dereference.
>
> Good luck.



--
polymita_jan
------------------------------------------------------------------------
polymita_jan's Profile: http://forums.novell.com/member.php?userid=100920
View this thread: http://forums.novell.com/showthread.php?t=428269

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP search unable to find all expected results


Thanks Wolfgang!


--
polymita_jan
------------------------------------------------------------------------
polymita_jan's Profile: http://forums.novell.com/member.php?userid=100920
View this thread: http://forums.novell.com/showthread.php?t=428269

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.