Hey all,
I am configuring my Openfire server for LDAP access to Active Directory. The page where I enter the server settings tests OK, the page where I enter the group settings is set OK but the page where I test the user search function appears odd. Only a few accounts show up when I go through the random account list to test that the user search function is working properly.
Thinking this was odd I looked through the various logs and found this interesting exception which happened quite a few times (likely corresponding to the number of random accounts I tried).
2008.03.11 11:28:55 org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:182) javax.naming.InvalidNameException: “CN=“Opsitnik, Lucy - IOFD/DOFI”,OU=“IOFD-DOFI”,OU=“EWS-SE”,OU=BTS-SCE”: close quote appears before end of component
at javax.naming.NameImpl.extractComp(Unknown Source) at javax.naming.NameImpl.<init>(Unknown Source) at javax.naming.CompositeName.<init>(Unknown Source) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source) at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source) at org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:159) at org.jivesoftware.openfire.admin.setup.setup_002dldap_002duser_005ftest_jsp._jsp Service(setup_002dldap_002duser_005ftest_jsp.java:97)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:206) 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:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
My organisation uses a / character in most of its names. Those names where this / character appears generate this exception above. The last ou= is missing a quote at the beginning. This is weird because accounts that do not have slashes in the distinguishedName (or cn) field seem to work OK. Has anyone seen this before? I did some searching and saw some things about JNDI not liking / characters in name but this was resolved in a later version of JNDI.
Help would be appreciated as LDAP is a bit of a necessity at our corporation.
Those non-standard characters are going to reek havoc on your LDAP integration. That may be where your problem is coming from as it could affect your LDAP search. The other possibility is your baseDN does not cover all the OUs that your users are contained within.
I know they will, unfortunately I’m just the developer and not the designer of the Active Directory hive. There’s literally 5000+ accounts in there so it isn’t the easiest thing to handle. That being said LDAP integration with other products works eventually. I was hoping this was a bug in the JNDI integration (or Openfire itelf) that caused the proble. It seems weird that only the last ou= is the one not properly formatted …
ooops I forgot to reply to your second part, I am checking the right OU for all of the users. If I wasn’t it wouldn’t have found the user in the exception … all of our users are organised in a hierarchy under a single OU. in our case that ou is ou=STATCAN. ou=STATCAN is not in the distinguishedName from the exception presumably because of the quoting problem.
can you post your openfire.xml file edited for security where you see fit. I would like to see your LDAP settings.
Sure thing,
Here you go. I have edited out the password for the account used to do LDAP lookups. I should also note that the groups test works fine, it finds a number of groups perfectly well.
Here is the link to the JNDI issue I found online too if it is helpful at all: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4307193
Thanks for your help in this.
One thing and it probably is not the cause of your probles is that you can simplfy the baseDN by using an email address such as johnd@domain.com instead of the structure.
I noticed in your openfire.xml that you have this:
<nameField>name</nameField>
<emailField>userPrincipalName</emailField>
<groupNameField>sAMAccountName</groupNameField>
<groupMemberField>member</groupMemberField>
<groupDescriptionField>description</groupDescriptionField>
<posixMode>false</posixMode>
<groupSearchFilter>(objectClass=group)</groupSearchFilter>
Ours looks like this:
<nameField>cn</nameField>
<emailField>mail</emailField>
<groupNameField>cn</groupNameField>
<groupMemberField>member</groupMemberField>
<groupDescriptionField>description</groupDescriptionField>
<posixMode>false</posixMode>
<groupSearchFilter>(objectClass=group)</groupSearchFilter>
I had the defaults in originally but modified the file with various fields because either the field was not used in our AD installation or a different field yielded better results. I will try your previous advice about searching on the email address instead in the BaseDN and let you know how it goes.
My bad I am so used to typing baseDN my fingers did it automatically. I meant the AdminDN.
here is my entire openfire.xml for a reference. There is additional stuff in there for SSO.
I’m not sure what you mean by simplifying the BaseDN exactly? I have tried only mapping fields that do not contain the name with the / character in them (i.e. replacing cn, displayName, etc.) with sAMAccountName.
Could you elaborate a bit on how I do this in Openfire6
See my newer posts. I meant adminDN.
I tried it on the AdminDN and it didn’t help much. On the page where you enter the AdminDN I always press the “Test These Settings” button and the connection to the LDAP provider is successful. The only page where I see the exception from above is the page where I enter the user mapping information. When I press the “Test These Settings” button on this page the random profiles it brings up are filled with nothing for accounts whose CN= has a slash in it. For other accounts I always see something in the profile page.
That’s why this seems to be a defect to me because the account used to search LDAP and the groups both appear to work correctly. It is the user mapping that is the problem. forward slash characters are valid in the LDAP schema and in JNDI but it looks like whenever OpenFire tries to build a string to search for the user, it crashes if the user’s name contains forward slashes.
The issue may be with java not liking the forward slashes.
OK fair enough, but is there a remedy or am I basically screwed??
Can IgniteRealtime open a defect on this? Forward slashes are allowd in the LDAP standard soOpenfire, JNDI and Java should support them … no?