LDAP Searches For Wrong Name

Openfire Openfire Support
1

Using the 7/28/05 night build.

I have been experimenting with the new ldap groups support. Here’‘s the problem that I’'ve run into. When JM is parsing the users in a group for displaying the group summary, it all of the sudden begins searching for the wrong username. Hopefully, my debug logs will do a better job explaining what I mean. First, from the debug log is my startup parameters:

+++++++++++++++++++++++++++++++

2005.07.28 14:57:53 host: 10.100.10.1

2005.07.28 14:57:53 port: 389

2005.07.28 14:57:53 usernamefield: nGWObjectID

2005.07.28 14:57:53 baseDN: o=acs

2005.07.28 14:57:53 alternateBaseDN: null

2005.07.28 14:57:53 nameField: fullName

2005.07.28 14:57:53 emailField: mail

2005.07.28 14:57:53 adminDN: cn=holtsclawb,ou=annex,o=acs

2005.07.28 14:57:53 adminPassword: test

2005.07.28 14:57:53 searchFilter: (&(nGWObjectID=)(objectClass=inetOrgPerson))

2005.07.28 14:57:53 ldapDebugEnabled: false

2005.07.28 14:57:53 sslEnabled: false

2005.07.28 14:57:53 initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory

2005.07.28 14:57:53 connectionPoolEnabled: true

2005.07.28 14:57:53 autoFollowReferrals: false

+++++++++++++++++++++++++++++++

As shown, the username is set to nGWObjectID. This is a user’'s groupwise username. Now, the part of the log file that shows my problem:

+++++++++++++++++++++++++++++++

2005.07.28 14:44:09 Trying to find a user’'s DN based on their username. nGWObjectID: mikesholar, Base DN: o=acs…

2005.07.28 14:44:09 Creating a DirContext in LdapManager.getContext()…

2005.07.28 14:44:09 Created hashtable with context values, attempting to create context…

2005.07.28 14:44:09 … context created successfully, returning.

2005.07.28 14:44:09 Starting LDAP search…

2005.07.28 14:44:09 … search finished

2005.07.28 14:44:09 Creating a DirContext in LdapManager.getContext()…

2005.07.28 14:44:09 Created hashtable with context values, attempting to create context…

2005.07.28 14:44:09 … context created successfully, returning.

2005.07.28 14:44:09 Trying to find a user’'s DN based on their username. nGWObjectID: donpowers, Base DN: o=acs…

2005.07.28 14:44:09 Creating a DirContext in LdapManager.getContext()…

2005.07.28 14:44:09 Created hashtable with context values, attempting to create context…

2005.07.28 14:44:09 … context created successfully, returning.

2005.07.28 14:44:09 Starting LDAP search…

2005.07.28 14:44:09 … search finished

2005.07.28 14:44:09 Creating a DirContext in LdapManager.getContext()…

2005.07.28 14:44:09 Created hashtable with context values, attempting to create context…

2005.07.28 14:44:09 … context created successfully, returning.

2005.07.28 14:44:09 Trying to find a user’'s DN based on their username. nGWObjectID: cn=carverj,ou=users,ou=ces,o=acs, Base DN: o=acs…

2005.07.28 14:44:09 Creating a DirContext in LdapManager.getContext()…

2005.07.28 14:44:09 Created hashtable with context values, attempting to create context…

2005.07.28 14:44:09 … context created successfully, returning.

2005.07.28 14:44:09 Starting LDAP search…

2005.07.28 14:44:09 … search finished

2005.07.28 14:44:09 User DN based on username ‘‘cn=carverj,ou=users,ou=ces,o=acs’’ not found.

2005.07.28 14:44:09 Exception thrown when searching for userDN based on username ‘‘cn=carverj,ou=users,ou=ces,o=acs’’

org.jivesoftware.messenger.user.UserNotFoundException: Username cn=carverj,ou=users,ou=ces,o=acs not found

+++++++++++++++++++++++++++++++

The two users, mikesholar and donpowers, work fine. So do quite a few other users before these. However, when it gets to joshcarver, it thinks his nGWObjectID is cn=carverj,ou=users,ou=ces,o=acs. Where does that come from?? It’'s as if JM forgets its usernamefield. I have done an ldif extract to make sure the attribute on that user object is set correctly.

Please let me know what other information I might be able to provide to shed more light on the problem.

Thanks.

2

The log message is a little misleading. It says:

org.jivesoftware.messenger.user.UserNotFoundException: Username cn=carverj,ou=users,ou=ces,o=acs not found[/code]

but it should actually be searching for the username carverj[/b]. The string that is logged in the debug log is the group’‘s member[/b] value, which is the full DN for that user. I tried to get Greg to change that but he didn’'t.

Is his username carverj[/b] or joshcarver[/b]?

3

Can you post your XML file?

Which LDAP server are you using?

Thanks,

Greg

4

I cannot find a way to attach a file using this forum, so I will post the contents of my xml config file.

5

Using Novell’'s eDirectory on Netware as the LDAP server.

6

After talking with Greg and looking at the code, I see my original comment was wrong. The group code is looking for the full DN as the username as the original poster suggested.

If you haven’'t already sent it to Greg, could you post the LDIF data for this group?

7

Also, make sure the user isn’'t excluded by your search filter.

searchFilter: (&(nGWObjectID=)(objectClass=inetOrgPerson))

Looking at your debug logs, this could be the case. What is happening is that your group has the user in it but your searchFilter excludes the user.

This is a possiblity, let me know.

Greg

8

Can these users login to JM? If not, it sounds like the user objects may have some problems.

9

User JoshCarver logs into our live JM server running 2.1.3 everyday. I’'m using the exact same user search string there – just no ldap groups. Here is the ldif file that is generated if I search for (&(objectclass=inetOrgPerson)(nGWObjectID=JoshCarver))

#This LDIF file was generated by Novell’'s ICE and the LDIF destination handler.

version: 1

dn: cn=CarverJ,ou=Users,ou=CES,o=ACS

changetype: add

nGWVisibility: 2

nGWObjectID: JoshCarver

nGWPostOffice: cn=ACS-PO,ou=Annex,o=ACS

nGWFileID: 2dw

nGWGroupWiseID: ACS-DOM.ACS-PO.JoshCarver1DC781B0-078C-0000-B13E-1CD01200

0000

mail: JoshCarver@avery.k12.nc.us

givenName: Josh

fullName: Josh Carver

messageServer: cn=LEAVE3161,ou=CES,o=ACS

groupMembership: cn=Grp-Faculty,ou=Groups,ou=CES,o=ACS

groupMembership: cn=Grp-Tech,ou=Groups,ou=CES,o=ACS

groupMembership: cn=Grp-TagTrackerAdmin,ou=Annex,o=ACS

groupMembership: cn=Grp-CESJabberUsers,ou=Groups,ou=CES,o=ACS

title: CES Technician

telephoneNumber: 828.766.2145

sn: Carver

securityEquals: cn=Grp-Faculty,ou=Groups,ou=CES,o=ACS

securityEquals: cn=Grp-Tech,ou=Groups,ou=CES,o=ACS

securityEquals: cn=Grp-TagTrackerAdmin,ou=Annex,o=ACS

securityEquals: cn=Grp-CESJabberUsers,ou=Groups,ou=CES,o=ACS

passwordUniqueRequired: TRUE

passwordRequired: TRUE

passwordMinimumLength: 5

passwordExpirationTime: 20051004142603Z

passwordExpirationInterval: 15552000

passwordAllowChange: TRUE

ou: x

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: Person

objectClass: Top

objectClass: ndsLoginProperties

networkAddress:: MSMKdA8L

eMailAddress: 7#JoshCarver@ACS-DOM.ACS-PO

loginTime: 20050728203655Z

loginGraceRemaining: 6

loginGraceLimit: 6

loginDisabled: FALSE

l: 316 Crossnore Elementary School

ndsHomeDirectory: cn=LEAVE3161_VOL1,ou=CES,o=ACS#0#Users\Staff\CarverJ

facsimileTelephoneNumber: 828.733.0826

description: Temporary

cn: CarverJ

ACL: 2#subtree#cn=CarverJ,ou=Users,ou=CES,o=ACS#[All Attributes Rights]

ACL: 6#entry#cn=CarverJ,ou=Users,ou=CES,o=ACS#loginScript

ACL: 2#entry#[Public]#messageServer

ACL: 2#entry#[Root]#groupMembership

ACL: 6#entry#cn=CarverJ,ou=Users,ou=CES,o=ACS#printJobConfiguration

ACL: 2#entry#[Root]#networkAddress

10

If you do a manual ldap search for cn=carverj[/b], does it find that user?

11

If I do a complete subtree search for cn=carverj[/b] using the organization as the base, I am returned two user objects:

dn: cn=CarverJ,ou=Users,ou=CMSFTES,o=ACS

…and all of its attributes, of which nGWObjectID is not one

dn: cn=CarverJ,ou=Users,ou=CES,o=ACS

…and all of its attributes, of which nGWObjectID is JoshCarver

12

Can you provide an ldif extract of a user that does work?

Thanks,

Greg

13

This is user MikeSholar, listed in the first post. His username seems to work fine for the group summary listing.

#This LDIF file was generated by Novell’'s ICE and the LDIF destination handler.

version: 1

dn: cn=SholarM,ou=Annex,o=ACS

changetype: add

nGWVisibility: 2

nGWObjectID: MikeSholar

nGWPostOffice: cn=ACS-PO,ou=Annex,o=ACS

nGWFileID: akz

nGWGroupWiseID: ACS-DOM.ACS-PO.MikeSholar1DC781B0-078C-0000-B13E-1CD01200

0000

mail: MikeSholar@avery.k12.nc.us

uid: SholarM

givenName: Mike

fullName: Mike Sholar

Language: ENGLISH

messageServer: cn=LEAVE3181,ou=AMS,o=ACS

groupMembership: cn=AnnexFolks,ou=Annex,o=ACS

groupMembership: cn=Grp-TechSupport,ou=Annex,o=ACS

groupMembership: cn=Grp-TagTrackerAdmin,ou=Annex,o=ACS

groupMembership: cn=Grp-AnnexJabberUsers,ou=Annex,o=ACS

title: Technician

sn: Sholar

securityEquals: cn=AnnexFolks,ou=Annex,o=ACS

securityEquals: cn=Grp-TechSupport,ou=Annex,o=ACS

securityEquals: cn=Grp-TagTrackerAdmin,ou=Annex,o=ACS

securityEquals: cn=Grp-AnnexJabberUsers,ou=Annex,o=ACS

passwordUniqueRequired: TRUE

passwordRequired: TRUE

passwordMinimumLength: 5

passwordExpirationTime: 20051102120117Z

passwordExpirationInterval: 10368000

passwordAllowChange: TRUE

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: Person

objectClass: Top

objectClass: ndsLoginProperties

eMailAddress: 7#MikeSholar@ACS-DOM.ACS-PO

loginTime: 20050722155127Z

loginMaximumSimultaneous: 2

loginGraceRemaining: 6

loginGraceLimit: 6

loginDisabled: FALSE

l: ACS Annex

ndsHomeDirectory: cn=LEAVE3181_VOL1,ou=AMS,o=ACS#0#Users\Annex\SholarM

cn: SholarM

ACL: 6#entry#cn=SholarM,ou=Annex,o=ACS#loginScript

ACL: 6#entry#cn=SholarM,ou=Annex,o=ACS#printJobConfiguration

14

I know the problem now. The problem is related to the fact that two user objects are found with the same cn.

The way I have the program now is that it will take the first search result and try to populate the username.

dn: cn=CarverJ,ou=Users,ou=CMSFTES,o=ACS

…and all of its attributes, of which nGWObjectID is not one

So because this object is the first and it has no nGWObjectID it fails to populate the username.

I will build a fix for this problem and it will hopefully make the monday release.

Greg

15

Super! Thanks for your diligence in tracking down the problem. Let me know if I can be of additional assistance in testing the fix.

Looking forward to the Monday release,

Ben