I’m having a few issues linking OpenFire in with our Active Directory system. We have about 40,000 users in the system and it seems that OpenFire tries to download all users every time user info is needed instead of just looking up the ones it needs (which are about 50 of these users I’m interested in.) This means that every time you click on the tab to view the users, you have to sit there for about 30 seconds while it downloads the list. (It then displays a mere 10 of these users, and clicking onto the next page causes another 30 second delay to display the next 10 users…) Needless to say, this seems very inefficient.
It also tells me that I only have 1,000 users on the system. This perhaps explains why there are users missing from the prepopulated groups on everyone’s roster.
Unfortunately I can’t narrow down the base DN as the users we are interested in are spread right across the AD structure, so the base DN is already as specific as it can be - any more so and users we want don’t appear.
Is this just a limitation of the way OpenFire uses LDAP? Would I be better off switching to a MySQL database and writing some scripts myself to populate it with data from LDAP? It seems a shame to ignore OpenFire’s LDAP support, but unfortunately it doesn’t seem to be written to scale very well. (Or hopefully I’m just doing something wrong!)
All the users we are interested in are in a single AD group, but I was unable to modify the user search criteria to only return results from this group (mostly because AD LDAP doesn’t support nested groups, nor wildcard matching on the memberOf attribute.)
Any suggestions or is LDAP not recommended for larger organisations?
as long as you can’t use a filter to limit the number of returned users it’s impossible for Openfire or any other LDAP client to “just looking up the ones it needs”. Some LDAP server support paged results, I don’t know whether Openfire does.
Anyhow it seems that there is no LDAP import for users and for groups which can be triggered every 24 hours. This could help a lot as Openfire would need to query LDAP only for authentication.
Organisations usually use LDAP/AD to manage their users in one place and this is fine.
First the 1000 result limited is a limitation of AD.
Second create a new AD group add the users you want to grant access to Openfire then use a user filter in openfire to limit results based on that groups membership.
Thanks for the replies. I did try to use the criteria that sixthring suggested (it was the closest I got) but unfortunately there are ten groups that need to be specified and the text box is not long enough to allow these to be entered.
There is some mention of a config file that can be edited by hand, but my conf/openfire.xml file has no LDAP information at all so I don’t know which file the docs are talking about!
First the 1000 result limited is a limitation of AD.
Dear Sixthring, this is simply not the true anymore. Limitation is in OpenFire code itself. Please take a look here .
a.nielsen wrote:
… but unfortunately there are ten groups that need to be specified and the text box is not long enough to allow these to be entered…
Maybe the easiest way is to mark groups you need by some unused field in LDAP schema? What I mean is to fill some field in Group object (mail,url), and then filter by that field(group filter): (&(objectClass=group)(mail=*)) or (&(objectClass=group)(url=*))
It is possible to all users to login, but only these 10 groups will be available in roster.
That patch may have added more features to the LDAP functionality of openfire, but it does not change the fact that Active Directory limits the search results of a query to 1000 per request unless the default settings of AD are modified.
It seems that LDAP Paged results is specified in RFC2696 . In my point of view AD works as expected (as RFC recommend) but OF does not. I also think that any LDAP server in existence support Paged results. This patch does not add new functionality in OF, it just enables it.
Just google it if you do not believe me. AD up to server 2003 at the least has a 1000 result limit by default this setting can be changed:
MaxPageSize - This value controls the maximum number of objects that are returned in a single search result, independent of how large each returned object is. To perform a search where the result might exceed this number of objects, the client must specify the paged search control. This is to group the returned results in groups that are no larger than the MaxPageSize value. To summarize, MaxPageSize controls the number of objects that are returned in a single search result.
Default value: 1,000
You can continue to argue with me over this if you like. In short if the user does not need more than a 1000 user or groups or other things populated into Openfire from AD then they should user filters to limit what is populated.
First the 1000 result limited is a limitation of AD.
Yes it is, but one can use paged results to get all users without changing this limit as far as I know. I did not test this anyhow.
Second create a new AD group add the users you want to grant access to Openfire then use a user filter in openfire to limit results based on that groups membership.
One does use LDAP and uid=xxx to have unique IDs and you recommend to create a new group and copy (or move) there uid’s? As long as moving is possible this may be fine, but making a copy is likely a bad idea.
… In short if the user does not need more than a 1000 user or groups or other things populated into Openfire from AD then they should user filters to limit what is populated.
What if I need more than 1k users and cannot change LDAP server behavior?
a) Use only 1k users
b) Use RFC standard compliant client to retrieve paged result
Clearly for me the right decision is to make OF standard compliant client. In fact OF is, just need simple tweak.
Second create a new AD group add the users you want to grant access to Openfire then use a user filter in openfire to limit results based on that groups membership.
One does use LDAP and uid=xxx to have unique IDs and you recommend to create a new group and copy (or move) there uid’s? As long as moving is possible this may be fine, but making a copy is likely a bad idea.
I think the AD group was referring to a group not to an OU, and as users can be (and usually are) members of multiple goups this should not require any ‘moving’ or significant changes to user accounts.
In this way the management of accounts can be done in one place (AD/LDAP) through group membership, rather than needing to be done in LDAP and Openfire.