We’ve migrated our AD servers from Windows 2003 AD to Windows 2008 AD. Effectively, all that meant for me and my Openfire Server (v3.52) was to point to the new Win2008 Domain controller for user authentication and group management services. So, in my Openfire configuration file, all I did was change from Old 2003 AD server (x.x.x.x) to the new 2008 AD server (y.y.y.y). No other changes were made and my Openfire server seemed to digest the change with no issue whatsoever after a reboot. For the most part, my Spark users are able to login, get group info, obtain privacylist info (where relevant), etc, with no problem. But I have one user who, although she can login, is unable to view her group membership from her Spark client and no other users can see her in their group/roster listings. I can see her active sessions listed in the Openfire Admin console but not from my spark client (my account is in the same group). As a result, she has to “search” for users in order to send an IM and conversely, users have to search for her to send her and IM. She basicially is not processing/broadcasting presence info nor is she getting/showing group membership although both are shown in the Admin Console for Openfire. No other users report a similar occurence. We currently have relatively low usage right now (about 60 users).
What I’ve done:
- Cleared various server caches from the Admin Console and restarted the server. Result: No change.
- Deleted/Moved the various properties files for her spark client to let spark rebuild them (spark.properties, groups.properties, etc). Result: No change.
- Installed Spark 2.6.0 (beta) on her machine. Result: No Change.
- Created a privacylist specifically for her that allowed ALL traffic. Result: No change.
- Deleted her from the AD group and re-added her to the group. Result: No change.
- What changes should I have expected coming a Win2003 AD and moving to a Win2008 AD?
- Should I adjust the search filters?
- My cache settings are the default, should I adjust the specific cache sizes now that I’m using Win2008 AD?
- Am I missing something with Spark?
Thanks in advance.
What is the domain functional level of your domain? I have same issue when I went to implement this in a 2003 / 2008 mixed environment. It worked fine when I changed the LDAP host to the 2003 box. Wanted to set it up on the 2008 server as it would be around longer. Using the latest versions Opefire (3.6.4) and Spark (2.5.8).
Same issue you described worked for all 25 users except 1 would not populate the group roster. Works after pointing at a 2003 AD DC.
Does your user have any special characters in the username or display name, and anything like that? Are you using a small business server by chance?
No special character in username and display name fields
Display Name: Susan Summers
The new DC is a windows server 2008 enterprise edition the old DC is a windows server 2003 SBS. Works fine when I point at old DC which is surprising usually SBS has wierd quarks.
It could be an odd permissions issue. Please try the following:
Go into your active directory users and computers
go to view and select “advanced features”
right click the root of your domain (domain.local) and select properties
select the “security tab”
added your ldap lookup user account
on “Apply onto” select “user objects”
check “read all properties” only (nothing else should be checked)
apply and ok
restart openfire service
Let me know if you have any questions
added the user for LDAP lookup
apply to: descendant user object
check read all properties
click ok to apply changed settings
Startup my test server service
change LDAP host back to 2008 box
clear all cache on server
stop service, start service
check server group roster - User is missing again.
The username I am using is an Enterprise Admin member. I have created a new user off copying this users account to see if it would work fine with new user account, it does.
try checking the properties of the account thats not showing up.
within properties, click the security tab. Is your ldap user account listed?
also, click “advanced” and see if the “allow inheritable permissions…” is checked.
My specific LDAP user account is not listed but the group to which he is a member is (domain admin, enterprise admin, etc).
Include inheritable permissions is not checked.
Going to add my LDAP user account to permissions list for this specific user object.
Edit permissions check “read all properties” Apply to “decendant user objects”
Apply and save
Startup test server and flush the cache in openfire
Restart server and check group roster
She still only shows up in user list and not the group roster
Checking debugging log.
I do see some errors when its trying to find some baseDN for a group and the user I am having issues with
searchFilter: (&(objectclass=user)(!(useraccountcontrol:1.2.840.1135126.96.36.1993:=2)))(&(member Of=cn=dom-ain_IM,ou=Openfire_IM,dc=domain,dc=local))
security group is similar to this dom-ain_IM
group contact list name is the company name
Attached is some snippets from the log where errors are thrown.
User DN looks accurate to me not sure why it would fail the lookup.
No clue why it is trying to search my AD for the contact list name of “company name” instead of using the security group dom-ain_IM or the groupSearchFilter I defined
openfire debug log.txt.zip (733 Bytes)
inheritable permissions should be checked. Give that a try.
Also, your search filter is a little more complex than it needs to be. Try this
(&(objectclass=organizationalPerson)(|(memberOf=CN=dom-ain_IM, OU=Openfire_IM, DC=domain,DC=local)))
i will give that a try tomorrow. The search filter checks to see if the user account is disabled. this affectively removes people from the group when we disable accounts. Keeps the group/buddy list clean without having to remember to remove group membership. It also only finds people that are a member of the openfire group. Will simplify search filter to give it a shot.
yeah, I’ve done that too. I just like to keep things simple while troubleshooting.
Also, keep in mind, that in my example, your tree must be like this
-dom-ain_IM (security group within Openfire_IM OU)
Because this is your ldap search, anyone that needs to be able to to sign into openfire must be a member of this group.
In my setups, I usually have multiple groups.
group 1. is used for the ldap search and is used for only access or deny.
group 2-XX is used for my roasters
Ok, taking a break from staring at linux code for a bit.
Let’s set inheritable permission on this user object: Susan Summers
- cn=susan summers,ou=adminstaff,ou=domain users,dc=domain,dc=local
- User object > properties > security > advance > LDAP user listed (with read all properites) and include inheritable permissions checked.
Now to change my search filter to something simplier
- (&(objectclass=organizationalPerson)(|(memberOf=CN=dom-ain_IM, OU=Openfire_IM, DC=domain,DC=local)))
Restart Openfire service
Unable to login to admin console
- setup field from true to false
restart openfire service
walkthrough setup again and test filters
- I musta had fat fingers plus this keyboard shift key get stuck
- No change to suggested filters, they tested fine
Group filter test shows 23 users in group
Was able to log into the admin console.
admin console group shows only 22 in roster
Susan Summers is in user list but not group roster
checking debug log.
Same error messages in notepad I posted in previous post, pops up.
Do any additional ports need to be opened on 2008 server besides 389 for LDAP ?
weird. try clearing the cache again and restarting the service again.
its odd that she is showing up in user list of openfire, but not the roster.
you could try creating another security group and another roster., put her in it, and see if she pops up in that.
Also, I would recommend using mysql or ms sql over the embedded DB. that way if you make a mistake, like with the search filter, you can easily edit the properties in the database table!
I have created a new security group in the past. Even let openfire pull all security groups this one user doesn’t populate any of them. Might use a backend database in the future but for initial testing and implmentation this is good. They may decide they hate it 2 weeks from now its hard to tell. This is a seperate server than what the users are currently pointing at, so no big deal. I could try moving her to a different OU temporarily see if that joggles something loose.
I am fairly confident that if I blow away her user object and recreate it the problem will vanish. But the pain from doing such a thing would be annoying. Exchange would get all pissy, all the little crap her specific acount had permission to would probably break and take weeks to find what broke where. Easier to create an openfire AD user object just for her to login with. 1/23 thats good enough and no issues seen with new users so far. As long as the 2003 DC is there I can just point at that. I doubt it will go anywhere for a year or so. I will mess with it some more later.
I agree…its something with the user account. Sorry that we didn’t get it figured out. I guess you could always reset the users permissions. thats easy enought to do if you wanted to try it.
You could also try this…make the dc a global catalog server, and use that to do your ldap lookups. I don’t know if it would yeild any different results, but thats easy enough to try as well.
You could always just take screen shots of all her settings. You can reattach her mailbox to a new account in exchange. If your network is setup well all her settings will transition fine. the new account will take ownership of the old data.
Alright guess what our 2003 SBS server was decommissioned. Here is what I found that fixed my original issue. I found this thread “http://community.igniterealtime.org/thread/36541” and and tried the most obvious thing first upgrade from 3.6.4 to 3.7.0 Beta. No change in the group roster listing. Read this same thread more deply and saw how it said that it was the problem arises in how openfire querys the CN=* first to pull the full DN. I broke out custom search on the 2008 server and ldap query and put in CN=Susan* and looky looky two object return with same CN=. One is a User object and the other appeared to be a public folder object from Exchange. Since my base DN= is the entire directory and not a sub folder it made sense that it pulled some exchange info. Found public folder no clue what it was used for or if used now and renamed it. Same CN=Susan* query and now I only get one item with Susan Summers matching. Remove Cache bounce service and bingo missing users are back. Compared to other users no other user had this issue. And appearently 3.7.0 Beta does not fix this issue with a CN=* query returning multiple objects.