powered by Jive Software

Active Directory Setup - Connection Works, can't find users

I’m setting up a fresh copy of Openfire 3.6.4 and I want to connect it to a Windows Server 2003 x64 server. It is a completely default setup on the Windows server with a single domain.

When I put in the following LDAP lines it passes the connection test:



However, it fails all subsequent tests on User Mapping - it complains that it doesn’t return any users. The above match the AD listings from ADSI Edit as well, so I’m not sure what the problem is.

Any hints?

i use a Free LDAP Browser.


I already used the ADSI Edit program to view AD. It’s all correct as far as I can tell.

Are your user objects under the default User OU?

OU=Users,OU=User Groups,DC=,DC=com

When I run ADSI Edit, I see this under domain:



Then all the users.

I’ve attached a screenshot.

But are your users in the default CN called Users? or do you have them in other OUs you created?

If they are elseware in the tree, you will nee to change your baseDN to match. Sometimes it is just easier to use the root of the domain for the baseDN, dc=domain,dc=local.

All users are in the base CN Users. This is a completely box-stock install with no changes to AD unless Exchange or some other service made changes.

the following should be correct.


/not sure if it’s a typo,in your original post, you have: CN=Users**;**DC=,DC=com

(semicolon between Users and DC)

Yes, once I changed it to comma it starts working. Thanks.

Note that:

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ldap-gui de.html

uses a semi-colon in the example. Someone should edit that!

Are changes to the structure of AD possible? If they are I would highly recommend taking the time to do so now. I would move the Users to a new OU. That OU can have sub OUs for Users, Security Groups and other items you may want to use with LDAP applications. This will allow you to crewate specific Groups that will only be used for LDAP apps etc. You then make your BaseDN this new OU, OU=nameofOU,dc=domain,dc=local.

Otherwise you will need to add filters to remove system level accounts and groups from openfire.

I really don’t want to mess with the Exchange server if I can avoid it, since even 2 minutes of downtime creates a torrent of questions as to why people can’t see their email or whatnot.

I’d rather just put filters in. Can you recommend some for a stock AD setup?

what version of AD are you on? (exchange server)

You can easily test this by adding a new OU


  • user groups

– TestOU

put yourself in it.

Then you can query try to query against: OU=TestOU,OU=User Groups,DC=,DC=com

The default “User” container can contain more object than your regular users. As Todd said, creating a new OU makes for easier querying later on.

However, if you have any group policies in place on the default container, these will not apply. I’d start small with just yourself and a few other folks that you can guinea pig with. Making AD structure changes itself isn’t that bad in this case, but there are pitfalls such as group policies that can be lost moving folks around.

/test first before doing anything large scale.

Basically all I want to do is have any newly created Exchange accounts also get Openfire access. Moving objects around in AD seems like a recipe for disaster to me.

I’m running Exchange 2007.

I really can’t because you are going to need to exclude a ton of things with your config. Is this your only domain controller? You can create OUs on the fly without effecting Exchange. You can move accounts too. No need to reboot the server. When you move account it only affects policies you may have in play in AD but considering they are all in the Users CN you can only have root level policies that will not be affect by moving users to an OU.

Is there a HOWTO or guide for this somewhere I can look at?

I logged into my now functioning Openfire config screen and other than a few admin users, the list just seems to be valid accounts. I should be able to filter out the admin accounts pretty easily - surely there is something I can set in the user info for them to filter on?

Much of what you do through AD Users and groups is “organizing” for the us soft bodied humans. Unless you have assigned group policies or the like to the “User” container, creating a new OU and moving folks into it is for the human’s over seeing it.

If you create a new OU and move only known “human users objects” into it, then point Openfire to read that OU for user list, it’s fairly uncomplicated.

The only real gotchas you’ll have to remember is to create new users in that newly created OU in the future.

Try it out on your user object, you’ll find it’s not as “disastrous” as you think.

/i suspect my organization is much larger than yours but we move people from one OU to another as people’s roles in the organization change, without any ill effect.