com.sun.jndi.ldap.Ber$DecodeException: Encountered ASN.1 tag 2 (expected tag 10)]

Set up a clean Openfire 3.7.1 on Windows, talking to an LDAP directory (Other or unknown) on localhost. I tested the LDAP pages at each stage and all is OK. I can login as one of the users in the LDAP directory I designated as admin.

When I click on the User/Groups tab in the Openfire admin console, it pauses for a few seconds, then the following exception appears in the error.log and it then displays the list of LDAP users in the directory. If I click on any user shown it will display the data for the user and again show the error in the log.

I have enabled debug trace to the openfire console window and it shows a dump of the conversation, but I don’t know how to interpret it.

Any ideas on the problem?

2011.12.01 10:44:37 org.jivesoftware.openfire.ldap.LdapManager -

javax.naming.NamingException [Root exception is com.sun.jndi.ldap.Ber$DecodeException: Encountered ASN.1 tag 2 (expected tag 10)]

at com.sun.jndi.ldap.DefaultResponseControlFactory.getControlInstance(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.convertControls(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.getResponseControls(Unknown Source)

at javax.naming.ldap.InitialLdapContext.getResponseControls(Unknown Source)

at org.jivesoftware.openfire.ldap.LdapManager.retrieveList(

at org.jivesoftware.openfire.ldap.LdapUserProvider.getUsers( 191)

at org.jivesoftware.openfire.user.UserManager.getUsers(

at org.jivesoftware.openfire.admin.user_002dsummary_jsp._jspService(user_002dsumma

at org.apache.jasper.runtime.HttpJspBase.service(

at javax.servlet.http.HttpServlet.service(

at org.eclipse.jetty.servlet.ServletHolder.handle(

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1216)

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

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1187)

at org.jivesoftware.util.LocaleFilter.doFilter(

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1187)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1187)

at org.jivesoftware.admin.PluginFilter.doFilter(

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1187)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1187)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(

at org.eclipse.jetty.server.handler.ScopedHandler.handle(


at org.eclipse.jetty.server.session.SessionHandler.handle(

at org.eclipse.jetty.server.handler.ContextHandler.doHandle( 3)

at org.eclipse.jetty.servlet.ServletHandler.doScope(

at org.eclipse.jetty.server.handler.ContextHandler.doScope( )

at org.eclipse.jetty.server.handler.ScopedHandler.handle(

at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandler

at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.jav a:126)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(

at org.eclipse.jetty.server.Server.handle(

at org.eclipse.jetty.server.HttpConnection.handleRequest(

at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConne

at org.eclipse.jetty.http.HttpParser.parseNext(

at org.eclipse.jetty.http.HttpParser.parseAvailable(

at org.eclipse.jetty.server.HttpConnection.handle(

at 62)

at org.eclipse.jetty.util.thread.QueuedThreadPool$

at Source)

Caused by: com.sun.jndi.ldap.Ber$DecodeException: Encountered ASN.1 tag 2 (expected tag 10)

at com.sun.jndi.ldap.BerDecoder.parseIntWithTag(Unknown Source)

at com.sun.jndi.ldap.BerDecoder.parseEnumeration(Unknown Source)

at javax.naming.ldap.SortResponseControl.(Unknown Source)

… 43 more

Can you see if you can sniff the network traffic and provide a dump privately? Of course it make sense if you can switch to unencrypted LDAP connection.

Can you try setting

ldap.clientSideSorting = true

You might also try setting this:

ldap.pagedResultsSize = 0

Please let me know if any of those workarounds help. Seems like AD is sending INTEGERs instead of ENUMERATIONs somewhere.

Hi Marcin,

Setting ldap.clientSideSorting = true stops the problem from occurring. Withouth that setting, Wireshark shows the searchResDone packet as

Frame 22 (103 bytes on wire, 103 bytes captured)
Ethernet II, Src: CadmusCo_4f:13:af (08:00:27:4f:13:af), Dst: IntelCor_07:8b:78 (00:1c:c0:07:8b:78)
Internet Protocol, Src: (, Dst: (
Transmission Control Protocol, Src Port: ldap (389), Dst Port: 58240 (58240), Seq: 15, Ack: 241, Len: 49
    LDAPMessage searchResDone(2) success [0 results]
        messageID: 2
        protocolOp: searchResDone (5)
                resultCode: success (0)
                matchedDN:                 errorMessage:         [Response To: 11]
        [Time: 2.005458000 seconds]
        controls: 1 item
                controlType: 1.2.840.113556.1.4.474 (sortResult)
                    BER Error: Wrong field in sequence  expected class:UNIVERSAL(0) tag:10(ENUMERATED) but found class:UNIVERSAL(0) tag:2
                        [Expert Info (Warn/Malformed): BER Error: Wrong field in sequence]
                            [Message: BER Error: Wrong field in sequence]
                            [Severity level: Warn]
                            [Group: Malformed]

It’s not AD, but another LDAP server. It looks like it’s a bug in the LDAP server, do you agree?

Many thanks for the pointers.


Yes, this is a bug in the LDAP server. You can report this back to whoever wrote this. I am just wondering if we should implement a fallback in Openfire for this case - to degrade

gracefully by turning off server side paging and/or sorting if it fails.

Is the exception present only in the debug log? Is output somehow affected/incorrect/truncated? If no, I would leave the code as it is.

The only issue appears to be the exception logged in error.log. It does not seem to affect the operation, but I have only tested it against a small directory.

As long as the issue can be resolved by setting the

ldap.clientSideSorting = true

then I don’t think it’s necessary to patch up openfire to handle this case - I think the LDAP server is based on a very early draft from 1998 of the server side sorting specification.