After LDAP configuration very long local user login time-out

Our company decided to use LDAP (Active directory) authentication for internal (company) users and local authentication for external users.
But after ldap configuration local users can login to xwiki with very long login time-out about 1-2 minutes.

Is it possible to reduce it?
We use “xwiki enterprise 8.4.4” version.


but I don’t know if you can have different session timeout for LDAP user and local user (ldap user are local user in some way)

Pascal B


As i mentioned earlier we want to reduce user login time-timeout (when user type username and password and click login ) not session time-out.

Although I don’t know much about the LDAP interface of xWIKI, there are usually the following probable causes:

  • name resolution issues
  • certificate issues (LDAPS / LDAP TLS)

How big is your AD object wise? Where is the AD server located? LDAPS or LDAP with TLS?

You probably might enable logging using the GUI (or maybe there is something in the log already)

LDAP authentication works fine, but we have problem (very long login time-out ) with local user authentication when LDAP authentication is enabled.

How long does it take to login a ldap user?

If you disable the local auth after LDAP
and provide an user that does not exist, how long does it take for LDAP/xWiki to complain that there is no such user e.g. login incorrect?


LDAP (Active directory) user can login without any time-out.
But local user (user created in xwiki) has very long (about 2-3 min) login time-out.

When i have disabled the local auth and trying to connect with incorrect login.
After 2-3 min time-out xwiki page refreshed without any information about that login is incorrect.

Now the question is, which part takes so long to get to the conclusion that the users does not exist. I doubt this to be the AD …

Maybe share the ldap config (just replace all sensitive information if any)

A successful LDAP auth should definitely take longer than a failing one (because of the user fields and membership synchronization).

In any case you should get a lot of timing information by enabling the debug log (each log also print the date and time) for the LDAP and XWiki authenticators. See for LDAP and for XWiki authenticator you can search for com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImpl in the logging administration UI.

Time-out when LOCAL user has successful authentication

debug log
Password check for user XWiki.temp successful
2 milliseconds spent validating password.
XWikiAuthServiceImpl.checkAuth(XWikiContext) took 189027 milliseconds to run.

Timeout when user typing incorrect login

debug log
XWikiAuthServiceImpl.checkAuth(XWikiContext) took 127302 milliseconds to run.
DEBUG x.x.u.i.x.XWikiAuthServiceImpl - XWikiAuthServiceImpl.checkAuth(XWikiContext) took 0 milliseconds to run.

Time-out when LDAP user has successful authentication

XWikiAuthServiceImpl.checkAuth(XWikiContext) took 229 milliseconds to run.
INFO x.x.u.i.x.XWikiAuthServiceImpl- User XWiki.GenadijusL is authentified
DEBUG x.x.u.i.x.XWikiAuthServiceImpl- XWikiAuthServiceImpl.checkAuth(XWikiContext) took 1 milliseconds to run.

ldap config

xwiki.authentication.ldap.bind_DN=cn=EPS Wiki,ou=ServiceAccounts,ou=EMS,dc=office,dc=local

We use “xwiki enterprise 8.4.4” version and LDAP authentication extension

Maybe something wrong with LDAP config?

Could you paste a complete LDAP debug log, it should be easy to see where it takes time.

Hello, please see attached files.
Timeout when user typing incorrect login.txt (8.9 KB)
Debug log when LOCAL user has successful authentication.txt (13.1 KB)
Debug log when LDAP user has successful authentication.txt (13.4 KB)

Problem has been solved after change LDAP config, in config selecting only one OU.

xwiki.authentication.ldap.base_DN=dc=office,dc=local changed to

Great that you found a solution @GenadijusL.

What I understood from the log is that the LDAP server XWiki is accessing to was redirecting to another one (when the user can’t be found on the first one ?) and the second one was taking a long time to answer (more than 2 minutes).

It would be easy to make possible to disable referral following in the configurable if needed (if that really was the issue here).

Depending on the size and the structure of your active directory (and somewhat the accessed attributes) it may me a good idea to authenticate against your nearest Global Catalogs (GC) instead of the standard LDAP connector. You need to know which servers have the GC role and have to connect to port 3268 (clear) or 3269 (SSL). That could save you some redirection time. I found that the attributes in GC are normally sufficient for the standard authentication and basic attribute syncs, but YMMV. But proofing the “nonexistence” of a user should be faster, because the GC should know them all.