New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP Role assignment not working (depending on name?) #1453

Closed
Ikke opened this Issue Sep 29, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@Ikke

Ikke commented Sep 29, 2015

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

This comment has been minimized.

Member

edmundoa commented Sep 29, 2015

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

This comment has been minimized.

bonzi316 commented Sep 29, 2015

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

This comment has been minimized.

Ikke commented Oct 1, 2015

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

This comment has been minimized.

bonzi316 commented Oct 6, 2015

Hi,

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

Thanks

@bernd bernd added ldap bug labels Oct 14, 2015

@bernd bernd added this to the 1.2.2 milestone Oct 19, 2015

@bernd bernd self-assigned this Oct 19, 2015

bernd added a commit that referenced this issue Oct 19, 2015

Check if group lookup worked to avoid a NPE
The group lookup can fail if the group belongs to a different domain and
the connection user is not allowed to lookup details.

Log a message to DEBUG if the lookup failed to make this debuggable.

Fixes #1453

joschi added a commit that referenced this issue Oct 19, 2015

Merge pull request #1491 from Graylog2/issue-1453
Check if LDAP group lookup worked to avoid a NPE

(cherry picked from commit 81c5baf, refs #1453)
@bernd

This comment has been minimized.

Member

bernd commented Oct 19, 2015

@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.

@bernd bernd closed this Oct 19, 2015

joschi added a commit that referenced this issue Oct 19, 2015

Merge pull request #1491 from Graylog2/issue-1453
Check if LDAP group lookup worked to avoid a NPE
(cherry picked from commit 81c5baf, refs #1453)
@Ikke

This comment has been minimized.

Ikke commented Nov 4, 2015

Confirmed the problem is solved with 1.2.2.

@bernd

This comment has been minimized.

Member

bernd commented Nov 4, 2015

@Ikke Thanks for the feedback! 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment