Subsonic Forum

Hi guys,

First of all, I would like to thanks the creator of this absolute beauty of life. The whole thing is absolutely wonderful and I wonder why it's not as popular as it should suppose to be. Anyway, here's my suggestion. In fact, this isn't a feature request, it's more like a stability request for a specific module in Subsonic. Right now, my network is configured with an Active Directory, which where all my users are authenticating. LDAP module seams to works perfectly, but some time, there's a little problem... even if I enter my correct username and password for a multiple time, the system said I couldn't log in, and then, at this point, I'm stuck to use the admin login (this is what I want to avoid).

Some time, I just look at my system (a x64 11.10 ubuntu server) and the system seams to be saturated. In this case, if someone tries to login, the system will say to the user he can't be authenticated. I was wondering if it was possible to add a sort of password caching for all LDAP authenticated users? In that case, if the server can't temporary reach the Active Directory for any authentication, Subsonic will use his cached password to authenticate the user.

So, how do you find the idea? Please let me know!
Thanks!
Dave

LDAP authentication is really unstable. I need to make an authentication through another service with my LDAP account, reconnect with the admin account on subsonic THEN connect with the LDAP account prior to successfully connect.

Ok hey, let's give an another shot to this dead thread.
Here's the detailed log error :

Code: Select all

[2012-01-11 09:08:30,268] INFO SubsonicLdapBindAuthenticator - Failed to authenticate user 'Dave' in LDAP.
org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: windowsldap.local:389 [Root exception is java.net.NoRouteToHostException: No route to host]
        at org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultInitialDirContextFactory.java:189)
        at org.acegisecurity.ldap.DefaultInitialDirContextFactory.newInitialDirContext(DefaultInitialDirContextFactory.java:261)
        at org.acegisecurity.ldap.DefaultInitialDirContextFactory.newInitialDirContext(DefaultInitialDirContextFactory.java:241)
        at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:123)
        at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
        at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
        at org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.authenticate(BindAuthenticator.java:71)
        at net.sourceforge.subsonic.ldap.SubsonicLdapBindAuthenticator.authenticate(SubsonicLdapBindAuthenticator.java:72)
        at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:233)
        at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
        at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
        at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45)
        at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:110)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
        at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at net.sourceforge.subsonic.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:43)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at net.sourceforge.subsonic.filter.ParameterDecodingFilter.doFilter(ParameterDecodingFilter.java:54)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at net.sourceforge.subsonic.filter.BootstrapVerificationFilter.doFilter(BootstrapVerificationFilter.java:54)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java: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:712)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at org.mortbay.jetty.Server.handle(Server.java:313)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
        at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:227)
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:626)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: javax.naming.CommunicationException: windowsldap.local:389 [Root exception is java.net.NoRouteToHostException: No route to host]
        at com.sun.jndi.ldap.Connection.<init>(Connection.java:223)
        at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136)
        at com.sun.jndi.ldap.LdapClientFactory.createPooledConnection(LdapClientFactory.java:64)
        at com.sun.jndi.ldap.pool.Connections.<init>(Connections.java:115)
        at com.sun.jndi.ldap.pool.Pool.getPooledConnection(Pool.java:132)
        at com.sun.jndi.ldap.LdapPoolManager.getLdapClient(LdapPoolManager.java:328)
        at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1590)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2643)
        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:306)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
        at javax.naming.InitialContext.init(InitialContext.java:240)
        at javax.naming.InitialContext.<init>(InitialContext.java:214)
        at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:99)
        at org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultInitialDirContextFactory.java:180)
        ... 42 more
Caused by: java.net.NoRouteToHostException: No route to host
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
        at java.net.Socket.connect(Socket.java:546)
        at java.net.Socket.connect(Socket.java:495)
        at java.net.Socket.<init>(Socket.java:392)
        at java.net.Socket.<init>(Socket.java:206)
        at com.sun.jndi.ldap.Connection.createSocket(Connection.java:365)
        at com.sun.jndi.ldap.Connection.<init>(Connection.java:200)
        ... 60 more


And then, when subsonic wants to authenticate me :

Code: Select all

[2012-01-11 09:14:15,750] INFO SubsonicLdapBindAuthenticator - User 'Dave' successfully authenticated in LDAP. DN: CN=DaveWut,cn=Users,dc=windowsldap,dc=local


Please, at least one person should had encounter this kind of problem with a windows ldap server. Can you help me figure what's the problem?
Thanks!

Looks like the root problem is:

windowsldap.local:389 [Root exception is java.net.NoRouteToHostException: No route to host

Is your LDAP server really named windowsldap.local? If so, is that name resolvable to the correct IP address?

Glenn

Pinging windowsldap.local into my local network works and return the right IP address. I can connect on it using AD Explorer from Microsoft by example. My SVN works too, I do not have any problems connecting each time with my AD credentials. Can I provide any information that could help you?

Thanks!

Perhaps you have port 389 blocked? I've been using LDAP authentication since 4.6 and haven't had any issues.

So I checked if the port was block on my server running WS 2008 R2 and everything was ok. I made some other test, I tried another LDAP client like LDAP Administrator 2012.1 and I was successfully able to connect on the server through port 389. LDAPS protocol is blocked though. Can I provide any other information?

Thanks!
Dave

Try changing the LDAP host name to an IP address... does that work?

Glenn

On the 2008 R2 server, do you get an errors in your audit logs from a login failure?

bushman4 wrote:Try changing the LDAP host name to an IP address... does that work?

Glenn

Hmm good idea, I'll try this right away and I'll give you feedback.

Citlali wrote:On the 2008 R2 server, do you get an errors in your audit logs from a login failure?

I do not have any error log about fail binds to the LDAP. However, I do have a warning log that specify I do have unsecured LDAP binds to the server, but this is expected, because I don't use a secure authentication method (and I should).

You might want to run rsop.msc and ensure there aren't any GPO's that have enabled signing requirements.

There's no signing requirements. The solution of Bushman4 seams to work. I'll keep you updated!

Hi,

As I said, I told you I would keep you updated about the situation and here I am. Since I changed LDAP URL to it's proper IP address, no problems occurred. I found that thing quite strange though, because every services I use are connected using DNS binds. Anyway, thanks for your help guys! Problem solved!

Dave