LDAP - Limit Active Directory Groups by OU?

Openfire Version: 3.6.3
OS: Ubuntu [Server] 8.04 (the Hardy Heron)
Java Version: 1.6.0_07

Hi.
I would like to limit the groups which Openfire uses from the active directory to those which are in a specific OU.

So as to not duplicate all of the past conversations, jeffreyvsmith posted something that seems like it will do what I’m looking for in this thread…

Specifically, it’s the one where he says this at the end of the post…
“So now I have it so that users are only those who are a member of my openfire security group,
and the groups are only those that are also members of that openfire security group.”

However, I’m not sure I understand the syntax of his cofiguration.

Basically, I know how to edit ‘System Properties’.
I’ve edited my ldap.baseDN to have the widest view of the campus active directory (because my users and groups are not all within the same OU).
I’ve also edited my ldap.searchFilter to only get users from a certain group within my department’s OU (so that I don’t have 100,000 user accounts in my Openfire setup).

However, I also want to have only my department’s groups to show up in the groups section of Openfire.
I think that what jeffreyvsmith posted in that thread will do this for me, but I’m just not sure I understand.

Anyone out there willing to do a little hand-holding for a few minutes?

Thanks.
steven

Unfortunately you cannot filter by OU other than the Base and Admin DNs. You need to make a complex filter listing the groups you wish to use or make sure they all have a common prefix for the name:

common prefix filter:

(&(objectClass=group)(cn=LDAPGroup*))

group list filter:

(&(objectClass=group)(|(cn=LDAPGroup1,ou=accounts,dc=domain,dc=com)(cn=LDAPGroup2,ou=SecondaryAccounts,dc=domain,dc=com)))

Cool. This is very helpful. Thanks.

So, with either of these, do I change the line to read like that, or add a second line?

Sorry, this is all a bit new for me still.

either/or depending on your LDAP group naming. No second lines. The second filter just keep extending inside the parenthesis.

Yep. Got it.

I just tried it a few different ways since my last post, and figured it out (using the * wildcard option).

Very cool! Thanks again.

Now, I’m off to go figure out how to auto-populate the contacts in all of the [Spark] clients so that the users don’t all have to add them all manually.

…different thread, I know, but do you have any pointers (perhaps a specific thread or document with step-by-step) off the top of your head for how to do this with my particular type of configuration?

Thanks.

steven

Actually, a side-note about my ldap.searchFilter…

There’s soemthing I’ve been doing with it as a work-around for another problem, and I’m wondering if you could help here too (and let me know if there’s another thread for this, or if you want me to create a new one).

Basically, the group which I want it to look at is in an OU with a long, complex name, and it doesn’t work. So, I moved the group up a level into an OU with a simple name, and it works fine.

Here’s the name of the OU I’d like to have it in…
“Groups, Users, etc”

When I copy the name of this OU within SysInternals’ Active Directory Explorer, it gives me
"OU=Groups, Users, etc" -snip-

However, when I add that into the field and move the group into that OU (and restart, etc), it breaks the LDAP connection (can’t find users, etc), and I’m not able to log into Openfire. Then I have to go edit the .script file with vi (pita for a Windows guy) to get it back to how it needs to be.

Is there a way to get Openfire to work happily with an OU that has a name like this?

I really do not know how to answer that because I canot visualize the name of the group. Is there a reason you are using sysinternals apps instead of the MS Server administration apps. The MMCs provided by MS work great to manage the AD structure. Namely Active Directory Users and Computers.

Oh, boy…here we go down a rabbit hole.

I’m sorry for even mentioning that tool.

Please do not get caught up with the tools I’m using. They are not relevant to my question.

Can you please re-read my last post?

I clearly posted the name of the OU. So, how is it that you can’t visualize it?

If you mean this is the name: Groups, Users, etc I would seriously and rapidly change the name. those are invalid characters in that name. This is one of those situations where windows is freaking stupid, because it will allow you to do things like use invalid characters in a name for an OU. Renaming the OU should have no effect on the objects contained within. It will present a warning, but I have never had an issue.

Quoting from when I first asked about it above…

Here’s the name of the OU I’d like to have it in…
“Groups, Users, etc”

Like I said that OU contains invalid characters. You should rename the OU to something like GroupsUsersEtc. The spaces and commas should not be used.

The campus active directory admins approved the name of that group and it’s been in service with no problems since late 2001. So, I’m not sure why I’d need to change it now. Why can’t this software package just ‘see’ it properly?

Beyond that, we have a digital document management/database system which is also leveraging the active directory (accessing this OU in our space), and it would need to be reconfigured if we were to rename this OU.

Of course, I could do that, but it’s easier said than done. If it comes to that, I will get it on the list as one of the steps that must be done in order to get Openfire working as we want it in our environment.

Meanwhile, I will probably just go with the way Openfire is working now (cause, it is indeed working - and I’m plenty happy about that ).

Thanks for your help in this process, Todd.

You are an invaluable resource for this project.

Hi Todd.

OK, next problem with this way of doing it…

I decided to try the second of the two options for doing the group thing (the one with separate groups listed in the field…not the wild card one).

However, even though I followed your syntax exactly, when I go to the groups place in Openfire now, there are none showing up.

So, for now, I will go back to the wildcard version, but is there some kind of limit to the number of characters that can be on the line for this - and is that perhaps why the other way isn’t working for me (the full LDAP path to the groups is very long, and there are 5 of them)?

Thanks.

steven