Missing user in AD group

Just to add a little mystery (as if there weren’t already enough with this issue). I downloaded the new version (3.3.3) in hope that this might solve the issue. Installed it on another test machine. Checked my users that were missing - still not there. Turned on the debugging and found this (not sure if everything i pasted is needed or not, but oh well, here it is, with my domain changed) -

2007.09.24 15:03:49 Trying to find a user’s DN based on their username. sAMAccountName: cn=monica garcia,cn=users,dc=MYDOMAINNAME,dc=com, Base DN: DC=MYDOMAINNAME;DC=com…

2007.09.24 15:03:49 Creating a DirContext in LdapManager.getContext()…

2007.09.24 15:03:49 Created hashtable with context values, attempting to create context…

2007.09.24 15:03:49 … context created successfully, returning.

2007.09.24 15:03:49 Starting LDAP search…

2007.09.24 15:03:49 … search finished

2007.09.24 15:03:49 User DN based on username ‘cn=monica garcia,cn=users,dc=MYDOMAINNAME,dc=com’ not found.

2007.09.24 15:03:49 Exception thrown when searching for userDN based on username ‘cn=monica garcia,cn=users,dc=MYDOMAINNAME,dc=com’

org.jivesoftware.openfire.user.UserNotFoundException: Username cn=monica garcia,cn=users,dc=MYDOMAINNAME,dc=com not found

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:626)

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:554)

at org.jivesoftware.openfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java: 77)

at org.jivesoftware.openfire.user.UserManager.getUser(UserManager.java:185)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvid er.java:698)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:99)

at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:184)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:102)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:65)

at org.jivesoftware.openfire.admin.user_002dproperties_jsp._jspService(user_002dpr operties_jsp.java:305)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1074)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:146)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:751)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475

I see similiar results for EVERY user that is missing the group info.

Soooooo, I took the cn=monica garcia,cn=users,dc=MYDOMAINNAME,dc=com and did a search with the Softerra LDAP Browser that had been recommended in numerous other posting about such issues and it found the user with no problems. Used the same filter I use in my config file - STILL found the user. This was the case for ALL the users that seem to be missing their group membership.

The one oddity that I can note (not sure if it is relevant or not) is that all my users that are missing group membership have a first name that ends in the letter A…granted, could be coincidence, but something to possibly chew on. I thought I had figured out the culprit, BUT I have other users whose first name ends in A that are not affected. If anyone else can help me out and keep me from banging my head against this brick wall, I would appreciate it - it’s beginning to give me a headache!

Kurt

You don’t happen to have “Hide from the Global Address List” selected for these users?

I found that many applications which look for users in AD are unable to find them if they are hidden from the GAL.

No, I don’t have that selected – wish it had been that though.

As a temporary solution to this glitch, I “copied” the users in questions in AD and created a new account with their login slightly different and add a - to the end of their display name…then back in spark, i just add them login as this “new” user. This allows them to see everyone and BE seen by everyone. It’s not the most elegant solution, but it worked for me until the problem is resolved.

Kurt

I had spotty sucess copying users. Some worked and some did not. Most of my users have large exchange accounts and the effort in moving them is not something I want try since this is not yeat a crirtical application.

Hi All,

I know it is a little old thread… I had such problems with missing users and my investigation led to having contacts with the same names… After renaming the contacts to “first secondname - contact” the users appeared…

I had excluded the Contact objects from the LDAP query but these were still intercepted…

I hope this helps to somebody.

Best Regards,

I know this may sound quite weird, but MS Dynamics Ax has issues at times where it can’t work out a users AD permissions to access the application. The way to ‘fix’ it is to create a new security group and add the problem user to it. The security group does not get used for anything else. My geuss is some sort of enumeration issue. Maybe a similar issue in Openfire?

Brian

Should probably add that you only create the dummy group once and add/remove the problem accounts as they get reported by the users.

Brian

I am on version 3.6.4 (Windows) and am seeing this issue with 1 account so far, and I can’t figure out what the problem is. The user is definitely in the same AD group that others are in, but does not show up in the group within Openfire, does not have a Roster for his User profile, and therefore he can not see the Contacts in his client. The account shows up as signed in, and if you manually add Contacts everything works.

I have also “checked” the account and don’t see anything abnormal or even different than other accounts. The user has been removed and readded to the AD group without any luck.

I have been searching the forums here and the Internet and I haven’t seen anyone with a solution that works. Unfortunately, this account is mail enabled and I do not want to delete it/recreate it.

I am hoping someone can come up with a solution or bugfix that works

Thanks

I’m in the same situation as you.

I have one user that doesn’t appear on any roster, but if we add him manually, we can chat whitout problems to him. I can’t rename the user account because the group membership it’s quite complicated about him and the account it’s also mail enable with Exchange.

I have created an account only for Openfire to this user and I have added the user only to the group that is shared. It isn’t the best solution, but it’s working meanwhile found another better.

Can you do a test. Copy the problem user (don’t worry about the exchange settings, yet) and see if the new account appears. If it does, then check if you have a filter that excludes based on some Exchange AD option. If it doesn’t, you will probably need to do a side by side comparison of the AD setting per account using your preferred AD viewing tool.

Just thinking, but is the ‘missing’ account an old one that may have been through an AD upgrade, eg 2000 to 2003?

Brian

Thank you for your help.

I can’t copy the account because it belongs to a departament chief and I can’t try anything “extrange” with it. I have created a new account to him only to use with openfire and only member of openfire shared group and it’s working in this way.

I have already done a side by side comparison and the config it’s the same to other accounts that are working without problems.

And finally, the domain always been 2003 AD, so it’s a “new” account.

Looks so negative, but everything it’s sooooo extrange

Thanks again!!

I had to face a problem very similar to this one.I’m linking OpenFire 3.6.3 to an Active Directory server. When importing users and their groups, everything look fine. Users are imported and group membership are correct when I look directly into the users properties.

But the situation is different for the groups. I created a security group called OpenFire in my AD and i added 12 users in that group. In Openfire, 7 users are listed. Strangely, has i said before, the Openfire group is listed into the account detail.

When i’m configuring the LDAP connexion, i’m having the right number of user for the Openfire group when i’m using the Test option.

I searched post and trying everything for 8 hours and 15 minutes ago I founded what was wrong (and thanks to this post : http://www.igniterealtime.org/community/message/201174#201174) : my baseDN. I was using DC=mycompany,DC=com and was thinking that the number of users returned for the Openfire group when using the Test button was taking the baseDN as a parameter but obviously this is not true.

So I changed my basedn to cn=Users,dc=mycomp,dc=com and my missing users appeared… victory!!!

Hope this will help someone in the future.

Did anyone found a resolution to this issue? I am having the same problem and started another thread recently.

http://community.igniterealtime.org/thread/47864