Environment
NetIQ Access Manager 3.2
PasswordFetch Class setup to perform user lookups Based on the UID attribute
uid is used for DN instead of CN, ex: dn: uid=1346154,ou=People,o=XXX
uid is used for DN instead of CN, ex: dn: uid=1346154,ou=People,o=XXX
Situation
PasswordFetch is being used to retrieve user and password from eDirectory in order to perform SingleSign on to a protected resource.
Getting the following error in the browser:
Error:Error while retrieving the password
The catalina.out log from the Identity Server shows the query the passwordFetch class is using is incorrect:
Example:
(&(objectClass=Person)(uid=uid=1346154,ou=People,o=XXX)), Scope: 2, Request Controls: null, UserId: xxxxxxxxxxxx</amLogEntry>
Notice "uid=uid=*", as a result the IDP displays no results:
<amLogEntry> 2013-01-21T18:46:28Z DEBUG NIDS Application:
Method: JNDILogEventListener.accept
Thread: http-bio-/151.155.215.107-8443-exec-3
Found 0 results! </amLogEntry>
Resolution
A solution to this problem would be to use a seperate attribute other than cn or uid to identify the user object.
In the passwordfetch class under properties, there are a couple choices that can be used.
1. Based on the CN of the user object
2.
For this solution we would use option 2 and could use an existing attribute such as "description" and populate the value so the passwordfetch ldap query can locate this object in the directory.
As an example say we have the following object in the userstore:
dn: uid=myuidtest,o=novell
objectClass: inetOrgPerson
cn: myuidtest
givenName: myuidtest
uid: myuidtest
sn: myuidtestlname
fullName: myuidtest myuidtestlname
userPassword: novell
You could populate the object with a description attribute with the following value:
description: uid=myuidtest, o=novell
**Note that the NAM code is expecting a space in between the containers, so if the user object was :
dn: uid=test1,ou=users,dc=testcompany,dc=com
The description attrbute value would need to look like this:
Description: uid=test1, ou=users, dc=testcompany, dc=com
If the spaces are not added, then the search won't find the object and the passwordfetch will fail.
You could use ldapmodify to add the avlues pretty quickly, example syntax:
Assming adddescription.ldif has the following:
dn: uid=myuidtest,o=novell
changetype: modify
replace: Description
Description: uid=myuidtest, o=novell
Example ldapmodify syntax:
/opt/novell/eDirectory/bin/ldapmodify -x -h <IP_ADDRESS_OF_USERSTORE> -p389 -D cn=admin,o=novell -w <password> -f adddescription.ldif -c
In the passwordfetch class under properties, there are a couple choices that can be used.
1. Based on the CN of the user object
2.
For this solution we would use option 2 and could use an existing attribute such as "description" and populate the value so the passwordfetch ldap query can locate this object in the directory.
As an example say we have the following object in the userstore:
dn: uid=myuidtest,o=novell
objectClass: inetOrgPerson
cn: myuidtest
givenName: myuidtest
uid: myuidtest
sn: myuidtestlname
fullName: myuidtest myuidtestlname
userPassword: novell
You could populate the object with a description attribute with the following value:
description: uid=myuidtest, o=novell
**Note that the NAM code is expecting a space in between the containers, so if the user object was :
dn: uid=test1,ou=users,dc=testcompany,dc=com
The description attrbute value would need to look like this:
Description: uid=test1, ou=users, dc=testcompany, dc=com
If the spaces are not added, then the search won't find the object and the passwordfetch will fail.
You could use ldapmodify to add the avlues pretty quickly, example syntax:
Assming adddescription.ldif has the following:
dn: uid=myuidtest,o=novell
changetype: modify
replace: Description
Description: uid=myuidtest, o=novell
Example ldapmodify syntax:
/opt/novell/eDirectory/bin/ldapmodify -x -h <IP_ADDRESS_OF_USERSTORE> -p389 -D cn=admin,o=novell -w <password> -f adddescription.ldif -c
Cause
When uid is used instead of cn= for the Distinguished Name (DN:) there is a bug in the code that assumes the uid=* is part of the actual value of the attribute. This is because the PasswordFetch class is assuming thte value will start with "dn: cn=*" and normally will strip out the dn: cn= to just get the value of the naming attribute. In this case the uid is being used for the naming attribute , e.g. "DN: uid=testuser,ou=users,o=test". Since there is no cn it is assuming the full value string is uid=testuser. This is why the query appears to be duplicating the uid=uid=testuser.
ieved properly.
Additional Information
I duplicated the setup in my 3.2sp1 environment.
1. imported user in my userstore to use uid:
dn: uid=myuidtest,o=novell
changetype: add
objectClass: inetOrgPerson
cn: myuidtest
givenName: myuidtest
uid: myuidtest
sn: myuidtestlname
fullName: myuidtest myuidtestlname
userPassword: novell
2. Created PasswordFetch Class and Method -> Specified to use uid for user lookup on the class.
3. Created a contract that uses the passwordfetch method as a secondary method.
4. Tested login with new contract using myuidtest,