OpenFire doesn't work with a specific user over GC LDAP

Openfire Openfire Support
1

Hello friends!

I’m having a very strange problem here, I’m using openfire 3.6.4 and Windows 2003 AD, as we have multiple domains we’re using the global catalog to quey the AD through 3268 port.

Everything works very fine, except for one user called “cdp” who is under a child domain.

We have the following structure:

domain.intra+

-------------------office1.domain.intra

-------------------office2.domain.intra

-------------------office3.domain.intra

-------------------office4.domain.intra

-------------------office5.domain.intra

I have built an OU under domain.intra where I created Universal Groups that holds the users and the rooster groups, like this:

Openfire_Users => This is an universal group that holds all the users allowed to login to Openfire, so I used the followinf as ldap.searchFilter:

(&(objectClass=organizationalPerson)(memberOf=CN=Openfire_Users,OU=Openfire,DC=d omain,DC=intra))

So, the user can be in any sub domain, but must be a member of this group to be able to login.

After this we created a group that holds the groups used to fill up the rosters:

Openfire_Groups => This is an universal group that holds other universal groups that acctualy has the members of the various departments, the the members of Openfire_Groups would be like the following groups:

Dept1_Users => This universal group is a member of Openfire_Groups and holds the users from department 1

Dept2_Users => This universal group is a member of **Openfire_Groups **and holds the users from department 2

Dept3_Users => This universal group is a member of Openfire_Groups and holds the users from department 3

Dept4_Users => This universal group is a member of Openfire_Groups and holds the users from department 4

So we have this as** ldap.groupSearchFilter**:

(&(objectClass=group)(memberOf=CN=Openfire_Groups,OU=Openfire,DC=domain,DC=intra ))

This way, only the users that are members from Openfire_Users and Groups that are members from Openfire_Groups are shown on the Administration Console, making things clear.

Well, like I said, everythings works well, but it seens impossible to get a user called cdp working on this scene, when I check the contents of the Dept1_Users (where the user cdp is located) I can see all users , but the user “cdp” looks like:

cn=cdp,ou=user_accounts,dc=domain,dc=intra@openfireserver.domain.intra*

*Remote users must accept presence subscription automatically

The strangest thing is that if I go to AD and rename “cdp” to anything alse, like “cdpi”, it works with no problem. Then if I reneme it back to “cdp” it stops working again.

This behaviour only occours when using the global catalog port (3268), using 389 the things works as they should.

I have built a test environment with a complete new AD 2003 server and Openfire (Red hat Linux) and it has shown the same strange behaviour.

Would it be a bug?

Thanks for any help, sorry for the long text.

2

Hello,

Maybe there is multiple “cdp” users in your forest…

I have this problem : I can 't have two user with the same loginname in 2 differents domains… OpenFire logs write something like “to many user for johnDoe”.

3

The users are unique forest wide, in fact created a test user account just to be sure.

4

Hello again!

Well, I have created a new environment from strach just to be sure that everything is fine. There are no other object named “cdp” anywhere in the forest.

I have really installed a new single domain in a new forest (for testing purposes) , set up Openfire to look up for users through the global catalog port, created few users for testing, everything was fine, but if I create an user named “cdp” or even if I rename a working user to “cdp” it stops working. If I use the default LDAP port (389) it works fine, but it will be impossible in our production environment as we have several domains in our AD forest.

I’m not sure but it looks like Openfire somehow doesn’t like the username “cdp”

I don’t know what to do!

5

cdp is the name of the CN used by AD for the CRL Distribution Point. It cannot be used as a username for a person.