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:
cn=Users;dc=domain,dc=local
cn=Administrator,cn=Users,dc=domain,dc=local
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.
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.
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.
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?
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.
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 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.
