LDAP Bug in Openfire 3.6.3 - javax.naming.InvalidNameException

Martijn_van_der_Klei · May 13, 2009, 1:21pm

Hi all,

I have a problem since I upgraded from OpenFire 3.5 to 3.6.3 with LDAP or rather Active Directory.

We have OpenFire setup to connect (with a read-only user) to our company’s Active Directory. When we use the various test screens in the Profile Settings section of OpenFire’s administration section, everything appears to work fine.

Once we try to update sharing information on groups or want to view the groups list, we get hammered by errors in the logfile:

2009.05.13 14:09:55 [org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.ja va:91)]
javax.naming.InvalidNameException: “CN=“Medewerkers CIO/IS”,OU=“Distribution Groups”,OU=“Messaging”,OU=“Users”,OU=“Netherlands”,OU=“Central_Services””: close quote appears before end of component
at javax.naming.NameImpl.extractComp(Unknown Source)
at javax.naming.NameImpl.(Unknown Source)
at javax.naming.CompositeName.(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source)
at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:86)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:278)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:257)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:103)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:66)
at org.jivesoftware.openfire.roster.RosterManager.hasMutualVisibility(RosterManage r.java:879)
at org.jivesoftware.openfire.roster.Roster.addSharedUser(Roster.java:876)
at org.jivesoftware.openfire.roster.RosterManager.groupUserAdded(RosterManager.jav a:628)

I’ve already trawled the forums here and searched online.

This seems to be related to OpenFire adding quotes and/or not being able to handle them. Just to be sure that we didn’t have a problem with the forward slashes, I checked whether this is a valid character.

Forward slashes are valid in a DN. However, when doing a lookup through JDNI with a DN using a forward slash, the slash should be escaped. (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4307193 )

MY REQUEST:

I would really appreciate it if an OpenFire developer would create a bug for this in the Jira issue tracker
Please check what’s going on with the quotes and forwars slashes in the code.

On a side note: when I attempt to change the ldap settings through the OpenFire admin interface (Profile Settings), I notice that OpenFire added quotes to my Base DN entry. This results in an empty Base DN entry when I try to edit the settings.

Could be a related bug or an entirely seperate one, still… I didn’t add the quotes myself.

Message was edited for clarity by: mvdkleijn

Martijn_van_der_Klei · May 14, 2009, 4:07pm

bump No one feels inclined to a bug report? I would love to enter it into Jira myself, but you’ve closed off issue reporting through Jira.

Martijn_van_der_Klei · July 9, 2009, 2:31pm

BUMP

Has anyone even bothered to read this? This is a fairly important problem that has surfaced in the more recent OpenFire versions. This is effectively not letting me upgrade to the latest OpenFire version (since the problem did not exist in our older OpenFire version) and is quickly leading my company with 35.000 potential users to start thinking about dumping our proof-of-concept OpenFire installation with +/- 100 users in favour of some other IM server.

akrherz · July 9, 2009, 4:06pm

Currently, there are no active and commiting openfire developers that are able to look into your issue. You should evaluate other jabber solutions.

daryl

Martijn_van_der_Klei · July 9, 2009, 4:27pm

I do hope you’re kidding? Did Jive drop all support for OpenFire or something? I was highly disappointed when the Spark client was effectively dropped into a black hole in terms of development, but this sounds like OpenFire is going the same way…

akrherz · July 9, 2009, 4:34pm

Check out Tigase, their project is gaining steam and is under heavy development,. http://www.tigase.org

daryl

Martijn_van_der_Klei · March 24, 2010, 10:59am

bump

This is a really annoying bug… can someone put it on the issue list please?

guus · March 24, 2010, 7:38pm

It took a while, but here’s the Jira issue: OF-353

guus · March 24, 2010, 7:51pm

Are you still in a position to reproduce this problem? If so, could you enable debug logging, and send me the relevant content?

guus · March 24, 2010, 10:15pm

My first thought is that this could be related to JM-1327. If you’re in a position to experiment, try setting the value of Openfire property ldap.encloseDNs to false.

Martijn_van_der_Klei · March 25, 2010, 12:49pm

Thanks for picking this up… I really thought OpenFire was a “dead in the water” project there.

Martijn_van_der_Klei · March 25, 2010, 12:50pm

Sounds like this might be it

I’ll try that and I’ll try to report back later today.

Martijn_van_der_Klei · March 25, 2010, 1:02pm

Error log:

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)
2010.03.25 15:05:40 [org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.ja va:98)]
javax.naming.InvalidNameException: “CN=“SPL/XM Websystems Projects Extern”,OU=“Distribution Groups”,OU=“Messaging”,OU=“Users”,OU=“Netherlands”,OU=“Central_Services””: close quote appears before end of component
at javax.naming.NameImpl.extractComp(Unknown Source)
at javax.naming.NameImpl.(Unknown Source)
at javax.naming.CompositeName.(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source)
at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:93)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:278)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:257)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:103)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:66)
at org.jivesoftware.openfire.roster.RosterManager.hasMutualVisibility(RosterManage r.java:879)
at org.jivesoftware.openfire.roster.Roster.(Roster.java:146)
at org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:86)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.broadcastUpdate(Presenc eUpdateHandler.java:282)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:124)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:112)
at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:176)
at org.jivesoftware.openfire.PresenceRouter.handle(PresenceRouter.java:134)
at org.jivesoftware.openfire.PresenceRouter.route(PresenceRouter.java:70)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:76)
at org.jivesoftware.openfire.net.StanzaHandler.processPresence(StanzaHandler.java: 337)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processPresence(ClientStanzaH andler.java:85)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:254)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:176)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:133)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)

Debug log

2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM Websystems Projects, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM Websystems Projects, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM60 Webfarm Deployment, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM60 Webfarm Deployment, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM60 WebSystems Intern, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Trying to find a groups’s DN based on it’s groupname. cn: SPL/XM60 WebSystems Intern, Base DN: DC=“cs”,DC=“ad”,DC=“corp”,DC=“net”…
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 LdapManager: Starting LDAP search…
2010.03.25 15:07:16 LdapManager: … search finished
2010.03.25 15:07:16 LdapManager: Creating a DirContext in LdapManager.getContext()…
2010.03.25 15:07:16 LdapManager: Created hashtable with context values, attempting to create context…
2010.03.25 15:07:16 LdapManager: … context created successfully, returning.
2010.03.25 15:07:16 094619 (01/05/00) - Connection #2 tested: OK
2010.03.25 15:07:16 094620 (01/05/00) - Connection #2 tested: OK
2010.03.25 15:07:16 094620 (01/05/00) - Connection #3 tested: OK
2010.03.25 15:07:16 094621 (01/05/00) - Connection #3 tested: OK

guus · November 21, 2019, 8:16am

It’s not often that I can tell without any hint of irony that it took us 10 years, but we got to it. A fix for this issue has been put in the code, and will be part of the upcoming 4.5.0 release. The fix is also part of the latest nightly build (available at https://www.igniterealtime.org/downloads/nightly_openfire.jsp). Please give it a test run, and tell us what you think!

stefanB · March 27, 2020, 2:44pm

Hi, we have users, whose cn’s contain commas and forward slashes. When I try to test the AD-settings via the web-interface, I get the following log entry

The usernames have the format Lastname, Firstname / Department

edit: forgot to mention: openfire version is 4.5.1

2020.03.27 15:38:41 ERROR [Jetty-QTP-AdminConsole-69]: org.jivesoftware.admin.LdapUserTester - An error occurred while trying to get attributes for user: Username
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr: DSID-03100288, problem 2001 (NO_OBJECT), data 0, best match of:
	'CN=Users,DC=Company,DC=LOCAL'
 ]
	at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3179) ~[?:1.8.0_201-1-ojdkbuild]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3100) ~[?:1.8.0_201-1-ojdkbuild]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2891) ~[?:1.8.0_201-1-ojdkbuild]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) ~[?:1.8.0_201-1-ojdkbuild]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) ~[?:1.8.0_201-1-ojdkbuild]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) ~[?:1.8.0_201-1-ojdkbuild]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:152) ~[?:1.8.0_201-1-ojdkbuild]
	at org.jivesoftware.admin.LdapUserTester.getAttributes(LdapUserTester.java:165) [xmppserver-4.5.1.jar:4.5.1]
	at org.jivesoftware.openfire.admin.setup.setup_002dldap_002duser_005ftest_jsp._jspService(setup_002dldap_002duser_005ftest_jsp.java:192) [xmppserver-4.5.1.jar:4.5.1]
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) [apache-jsp-8.5.40.jar:8.5.40]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javax.servlet-api-3.1.0.jar:3.1.0]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:65) [sitemesh-2.4.2.jar:?]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:73) [xmppserver-4.5.1.jar:4.5.1]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:49) [xmppserver-4.5.1.jar:4.5.1]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:226) [xmppserver-4.5.1.jar:4.5.1]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:234) [xmppserver-4.5.1.jar:4.5.1]
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [jetty-security-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) [jetty-servlet-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.Server.handle(Server.java:505) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) [jetty-server-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [jetty-io-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804) [jetty-util-9.4.18.v20190429.jar:9.4.18.v20190429]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201-1-ojdkbuild]

gdt · April 2, 2020, 12:03pm

Openfire 4.5 had a lot work done to LDAP that I would hope fixes this problem - are you able to try a more recent version?

Greg

stefanB · April 2, 2020, 12:24pm

Hi, I’m using Version 4.5.1, which seems to be the most recent stable build. I built the current alpha version of 4.6.0 too, but it still has the same issues.

Stefan

gdt · April 2, 2020, 12:42pm

Doh, sorry misread the post - confused with the topic title. In which case forget I said that.

You say;

The usernames have the format Lastname, Firstname / Department

e.g.

Thomas, Greg / Ignite Realtime

I’m not sure these would not be valid XMPP usernames, which may be the cause of the problem. Is there another field in LDAP you can use as an Openfire username?

Greg

stefanB · April 2, 2020, 2:13pm

Yeah, that’s exactly the format.

I tried to change the vCard Name in the Webinterface, but the problem persists. Can I change the field any other way?

Also, I checked the code in LdapUserTester (method getAttributes). The problem stems from the userRDN, which is loaded via the findUserRDN(string) method. These CNs have the aforementioned format. My best guess that there is a problem in LdapManager.getRelativeDNFromResult. There is some escaping there but it’s doesn’t seem to work with these CNs.