Issue with AD Group Accuracy

Good morning,

We currently have Openfire 3.5.2 installed and working rather well. However, I have a small number of users who are experiencing issues regarding the displayed roster within their Spark client. They are only able to see groups that have been shared to all users, rather than the entire list that they should see. After checking in our Active Directory, the users are in the correct group. When I check inside the Openfire admin console, that user does not exist in the group membership but I can find their login using “User Search”. In the “User Search” window it does show the user a member of the correct groups. It seems extremely odd that the server knows about the correct group membership in one part of the console, but not the other. Does anyone have any ideas on how to correct this? Below is our search filters.

User:

Field: sAMAccountName

Filter:(&(objectCategory=Person)(memberOf=CN=domain employees,OU=Groups,DC=domain,DC=net)(sAMAccountName={0}))

Group:

Group Field: sAMAccountName

Member Field: member

Description Field: description

Filter:(&(objectClass=group)(memberOf=CN=Wildfire,OU=Groups,DC=domain,DC=net))

We have 300 users on the server, with only 3 or 4 that are experiencing this problem. Hopefully someone has seen this before, as it’s quite frustrating since it works with 98% of our userbase.

Thanks in advance,

Ted

Hi Ted

May not be related at all - but I found in our 3.5.2 installation that only users with the CN in a particular format in Active Directory would show up in our Shared Groups. For example -

nick.chaplin - worked ok

Chaplin, Nick - wouldn’t show up in Openfire

We had a mix of formats depending who created the users. Just renaming the user in ADUC solved the problem. Otherwise have you tried using an LDAP browser like AD Explorer to look in detail at the user objects to see if there is anything odd / different?

Nick

Nick,

Thanks for the response. Unfortunately everything is identical between the affected users and the functional ones. We use a script to create all users so the fields are generally populated identically across the board. That’s what makes this so frustrating, there’s no obvious reason why these few users are having problems.

Regards,

Ted

Other things I can think of that have bitten me - nested groups (Openfire doesn’t support them so make sure the non-working users are directly in the groups that you’re sharing) and also try clearing the group / user caches in Openfire.

Sounds like you’ve looked at all that kind of stuff though. There must be SOMETHING different about those users, especially if the same users can’t see more than one shared group, and it’s the same users that are affected. I feel your pain with this - I’m still battling with LDAP / Openfire integration several months down the line… It works, but there are a number of funnies which are probably caused by small configuration errors - it’s tracking those errors down which is the difficult part…

Nick

Yeah I have checked that the users are indeed directly in the groups, and they are. They’re as identical as they can be to working users. I’m at a total loss as there’s no errors, logs, or anything that pinpoints why these few users have issues. Appreciate the comments. Hopefully someone has seen this in the past.

Ted

Have you cleared the cache? I was banging my head trying to figure out why the members of some groups showed and the members of another group didn’t. I just needed to clear the cache (Server > Server Manager > Cache Summary) and that did the trick for me.

Nested groups will be a treat when implemented! I can’t wait.

Yep I did clear the cache! Unfortunately it didn’t work either. It’s driving me and my colleagues crazy since no one can pinpoint where the issue is, or why it’s just these few users. I hate when an issue is best described as “gremlins”.

Thanks for the suggestion.

Ted