powered by Jive Software

Search quirk with Active Directory

Hello all,

we have an interesting problem with Openfire and shared groups.

Our environment:

Active Directory

Oracle 9i

OpenFire 3.3.2

Repro:

Using Active Directory management tools:

we created an AD group “Group A”.

In this group we added some users “User A”, “User B”, “User C”.

Of note:

User A has a DN of CN=“User A”,OU=“user here”, DC=“this”, DC=“that” and a sAMAccountName of “userA” - Call this User A-1

however in AD in another group (listed earlier in the structure) we have

User A has a DN of CN=“User A”, OU=“not the user here”, DC=“this”, DC=“that” and a sAMAccountName of “notUserA” - call this User A - 2

In the OpenFire web admin console view the Group A and see the user’s listed as members.

User A - 2, User B, User C

Expected:

User A - 1, User B, User C

The Issue:

In the OpenFire web admin under the Groups summary tab User A - 2 is listed as being a member of Group A, not the User A - 1 that is actually listed as a member in Group A as configured in ActiveDirectory.

Essentially, it appears as though the user searching code matches on the CN and not the full DN which results in the wrong User A being listed as a member of the Group in OpenFire. In this case, it seems to find the first matching CN (User A) and returns that even though the full DN and sAMAccountName is different.

Please let me know if you have any questions - I will monitor this thread.

Thanks!

E/.

I can confirm this. The same situation with groups. For example:

cn=GroupA,ou=Dep1,dc=domain

and

cn=GroupA,ou=Dep2,dc=domain

will not handled properly. Or:

cn=GroupA,dc=subdomain1,dc=domain

and

cn=GroupA,dc=subdomain2,dc=domain

if search AD tree via port 3268

The much better will be to use userPrincipalName in AD instead of sAMAccountName, but this now impossible because it contain ‘@’ symbol.