Some advice for a new Active Directory (LDAP) integration, Please

Openfire Openfire Support
1

Hello, we’ve been using OpenFire for a while now within a small group of users (~25). I installed on an old desktop PC with Linux and setup a small server. Some others have seen it and we have slowly been adding accounts, but now everyone wants to use it. That’s cool and all, but the problem is that’s about 300 people! I have a much more powerful Win2k3 server available that I can install OpenFire and I would like to set it up to use our existing Active Directory domain, but I could use some advice regarding the initial setup.

Our problem is that our current AD setup is a little haphazard as it has been just hacked together over the years, and, unfortunately, we no longer have the resources available to remedy that. The biggest headache that I see is that we have multiple OUs (some not necessary but are being used) and multiple groups that have unnecessary users (ie a supervisors group with non-supervisors in it etc.). I would like to be able to add a group like “IM_Supervisors”, add users that are actually supervisors to that group in AD, and then only have those users show up under that group in the IM client (Spark). All IM groups should be visible to all users in the client, just to keep it simple … hopefully.

My first thought was to create an OU and call it “IM” and then add the IM_Admin user to allow OpenFire access to AD and then put the “IM_*” groups under that. Then, as I was reading through the forums, I found other solutions using “security groups” etc. I’m not as familiar with AD as I would like to be, I admit, so I don’t quite grasp all of it, yet. If anyone else has run into a similar situation, or if maybe I’m approaching this all wrong, I would appreciate any and all advice.

Thank You, in advance!

Jason

2

A new ou with the groups for openfire is a good solution. you can then filter based on the groups and use only those groups for auto roster population. you do not need to move users if you use that method.

3

OK then, I’ll do that. Thanks for the prompt response! Glad to know I wasn’t completely off the mark.

4

I figured I’d give an update in case anyone else wants to do this same thing:

I decided upon this structure in AD:

OU=IM

User=IM Admin (purely for LDAP Binding)

Groups= IM_Users, IM_Helpdesk, IM_Customer_Service, IM_Testing, etc using the same “IM_GroupName” model

(I chose the “IM_*” model just so it would be easier to know what group a user is in)

Method to add user to IM:

Add user to the “IM_Users” group so that they can login to OpenFire. Then add them to any other “IM_*” group to have them in that group in IM.

(I had to do this as I can’t rely on the data for department that is in our AD plus I can add users to multiple IM groups this way. … for some reason )

BaseDN: DC=COMPANY,DC=LOCAL

AdminDN: CN=IM Admin,OU=IM,DC=COMPANY,DC=LOCAL

User Name Field: sAMAccountName (default)

Advanced Filter (ldap.searchFilter): (&(objectClass=organizationalPerson) (memberof=CN=IM_Users,OU=IM,DC=COMPANY,DC=LOCAL))

Group fields are default (cn,member,description)

Group Search Filter (ldap.groupSearchFilter): (&(objectClass=group) (CN=IM_) (!(cn=IM_Users)))

And I just used our IT users’ names for the admins.

Those filters gave me some headaches BUT a little advice for anyone new to AD & LDAP, check out this page: http://www.computerperformance.co.uk/w2k3/utilities/ldp.htm Really helped out as it will let me do searches and return the entire field set. Great for finally getting a working solution.

I’m still in the implementation phase, so if anybody sees some horrible planning or organization mistake I’ve made, I wouldn’t mind you pointing it out to me.

Cheers!