Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0.0-M20
-
Component/s: None
-
Labels:None
Description
When starting the server sometimes it is not possible to bind to the server. In that case the following error is returned to the client:
INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=admin,ou=system
Same error is reproducable in UberJarMainTest, it fails sporadically on my machine (Linux) and on Jenkins (https://builds.apache.org/view/A-D/view/Directory/job/dir-apacheds-ubuntu-deploy/1680/org.apache.directory.server$apacheds-service/testReport/org.apache.directory.server/UberJarMainTest/serviceInstanceTest/)
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Added e.printStackTrace() in AuthenticationInterceptor line 495
org.apache.directory.ldap.client.api.exception.InvalidConnectionException: Cannot connect to the server: Connection refused at org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:658) at org.apache.directory.server.core.authn.DelegatingAuthenticator.authenticate(DelegatingAuthenticator.java:265) at org.apache.directory.server.core.authn.AuthenticationInterceptor.bind(AuthenticationInterceptor.java:465) at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:439) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:184) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:636) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:66) at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) at org.apache.mina.transport.socket.nio.NioSocketConnector.finishConnect(NioSocketConnector.java:221) at org.apache.mina.transport.socket.nio.NioSocketConnector.finishConnect(NioSocketConnector.java:47) at org.apache.mina.core.polling.AbstractPollingIoConnector.processConnections(AbstractPollingIoConnector.java:459) at org.apache.mina.core.polling.AbstractPollingIoConnector.access$700(AbstractPollingIoConnector.java:65) at org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:527) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ... 1 more java.lang.NullPointerException at org.apache.directory.server.core.authn.SimpleAuthenticator.getStoredPassword(SimpleAuthenticator.java:126) at org.apache.directory.server.core.authn.SimpleAuthenticator.authenticate(SimpleAuthenticator.java:188) at org.apache.directory.server.core.authn.AuthenticationInterceptor.bind(AuthenticationInterceptor.java:465) at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:439) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:184) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:636) at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:66) at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) at java.lang.Thread.run(Thread.java:745)
Why would be use the DelegatingAuthenticator at first ??? This makes no sense !
For standard servers, the DelegatingAuthenticator should not be activated by default, and if it's set, at least the delegateBaseDn should be used to avoid calling this Authenticator from the root DN.
Currently, here is the configuration for this Authenticator :
dn: ads-authenticatorid=delegatingauthenticator,ou=authenticators,ads-interceptorId=authenticationInterceptor,ou=interceptors,ads-directoryServiceId=default,ou=config
ads-authenticatorid: delegatingauthenticator
objectclass: top
objectclass: ads-base
objectClass: ads-authenticator
objectClass: ads-authenticatorImpl
ads-authenticatorClass: org.apache.directory.server.core.authn.DelegatingAuthenticator
ads-enabled: TRUE
I'll set the ads-enabled attribute to false.
FTR, we don't use at all the delegateBaseDn attribute, which is a mistake, no matter what.
The problem is in AuthenticationInterceptor we use a HashSet which holds the authenticators, and for each JVM start (and probaly JVM version and platform) the "order" is different.
Another issue is that register() is called twice, once with null DirectoryService and once with the instance.
Wait, the call of AuthenticationInterceptor.setAuthenticators(Authenticator[]) the order of the 4 interceptors differs from run to run.
This array is generate in ServiceBuilder.createAuthenticators() using a HashSet, so here the initial shuffling is done.
Then the proper functioning of AuthenticationInterceptor.setAuthenticators(Authenticator[]) depends on the order.
yes. Thus the comment I have added a very long time :
// TODO : we should refactor that.
// try each authenticator
Anyway, I have fixed the pb by disabling the delegating authenticator atm (and by making the use of the delegateBaseDN mandatory).
Added a first fix here: http://svn.apache.org/r1675262
I think it should be fixed now. The authenticator selection is done in a way which is not random anymore.
Logfile contains following message which is produced in AuthenticationInterceptor line 495: