Active Directory Question

I am currently running 3 Openfire 3.4.3 servers and frankly I love the software. Runs very well for me.

I am using the ldap read into my win 2k3 ad network targetted at specific OU’s, my question is can I specify that the ldap configuration only look at a security group? Such as jabber1access. I’ve gotten some requests to block jabber access but because I have the ldap reads looking at the OU’s for my global offices I can’t move a US user to a UK OU, it would really affect productivity.

Basically I would be pointing the ldap read at a security group container instead reading at an OU, is this possible?

cbtl

You can restrict users based on a filter. the filter can include group membership. Search the community there are many examples of such filters. i would provide one but I suck at writng LDAP filters.

Not only is it possible, but I’d say it’s recommended. Here’s how I set mine up:

  • I have a “master” security group called JabberAccess. If you have different servers, you may want JabberAccessUS and JabberAccessUK and sort of duplicate some of what I do.

  • All users must be a member of the JabberAccess group in order to login.

  • I also add each user to a departmental security group such as JabberAccountingSec. This is used to build the roster groups on the fly.

  • Each roster security group must also be a member of JabberAccess.

  • My searchFilter ends up looking like this (although, I still haven’t gotten around to added a restriction against disabled users):

  • (&(objectCategory=Person)(memberOf=CN=JabberAccess,OU=Security Groups,OU=Groups,DC=example,DC=com))

  • My groupSearchFilter ends up looking like this:

  • (&(objectClass=group)(memberOf=CN=JabberAccess,OU=Security Groups,OU=Groups,DC=example,DC=com))

Then it’s just a matter of creating all the Jabber groups and adding everything to the JabberAccess group.

I have some information that may help you with this as well in my reply to the following post:

http://www.igniterealtime.org/community/thread/31280

If you use more than one filter (ie, you have an ‘&’ in the filter), there is a bug that was introduced around 3.4 in the XML parser that produces bad XML. I detail it in the post above.