LDAP Role assignment not working (depending on name?)

[Ikke]

We're trying to setup LDAP group mappings and notice that in some cases it's not working properly (ie, the user is not assigned the proper group, does not see the streams assigned to that group).

Preliminary testing shows it might depend on the group name:

Name	Works
NLD-WEBLOG	yes
NLD-WEBLOG-Auditors	no
NLD-WEBL	no

We tried several times renaming the group and assigning a role to that group and verify if that user would see the stream assigned to that role.

The group query we used is: (&(objectClass=group)(cn=NLD-W*))

They graylog server log shows this:

2015-09-29T06:56:57.619Z INFO [LdapNetworkConnection] There is no future associated with the messageId 2, ignoring the message
2015-09-29T06:57:10.823Z ERROR [LdapConnector] Unexpected error during LDAP group resolution
java.lang.NullPointerException
at org.graylog2.security.ldap.LdapConnector.search(LdapConnector.java:168)
at org.graylog2.security.realm.LdapUserAuthenticator.doGetAuthenticationInfo(LdapUserAuthenticator.java:93)
at org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)
at org.apache.shiro.authc.pam.ModularRealmAuthenticator.doMultiRealmAuthentication(ModularRealmAuthenticator.java:219)
at org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:269)
at org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
at org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)
at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)
at org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
at org.graylog2.rest.resources.system.SessionsResource.newSession(SessionsResource.java:93)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:308)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:291)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1140)
at org.graylog2.jersey.container.netty.NettyContainer.messageReceived(NettyContainer.java:356)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at org.jboss.netty.handler.execution.MemoryAwareThreadPoolExecutor$MemoryAwareRunnable.run(MemoryAwareThreadPoolExecutor.java:606)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

[edmundoa]

Hi,

The attached stacktrace doesn't help much to figure out the problem, could you please turn the log level of org.graylog2.security.ldap.LdapConnector to TRACE? The easiest way to do so is via the System/Logging section in the API browser (http://<graylog-server-host>:12900/api-browser).

That logs all kinds of details about searches performed and the entities returned, and may help you to figure out the problem. In case you need some help with it, please send the log output to support@graylog.com if you can't share it publicly.

[bonzi316]

Hi,

we are facing the same issue here. I just sent you a trace via email. The error seem to come from a group that belong to a trust from another forest we have. I think you should ignore group that are outside of our base dn.

[Ikke]

Along with the trace, also a warning is shown:

2015-10-01T07:13:26.399Z WARN [LdapConnector] Unable to iterate over user's groups, unable to perform group mapping. Graylog does not support LDAP referrals at the moment. Please see http://docs.graylog.org/e
n/1.2/pages/users_roles.html#troubleshooting for more information.

Just like @bonzi316, the user in case also has groups that belong to another domain.

Because of that, the group lookup returns null, which causes a nullpointer exception (see https://github.com/Graylog2/graylog2-server/blob/master/graylog2-server/src/main/java/org/graylog2/security/ldap/LdapConnector.java#L168)

So I agree with @bonzi316 that filtering out groups is a good idea, or at least, check if null was returned for the group lookup.

[bonzi316]

Hi,

any idea when this fix will be release ? Since it affect role mapping for users it's a blocker for us.

Thanks

[bernd]

@Ikke @bonzi316 Thanks for the report and the information. We added a null check in #1491 to avoid a NPE.

This will be in the upcoming 1.2.2 release.

[Ikke]

Confirmed the problem is solved with 1.2.2.

[bernd]

@Ikke Thanks for the feedback! 😃