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

graylog2-server-0.92.3 LDAP NullPointerException #837

Closed
rhartkopf opened this Issue Dec 29, 2014 · 10 comments

Comments

Projects
None yet
3 participants
@rhartkopf

rhartkopf commented Dec 29, 2014

I am getting an exception after setting up LDAP on graylog2-server 0.92.3 and graylog2-web-interface 0.92.3. Here's what it looks like from the web side:

[error] o.g.r.m.UserService - Unauthorized to load user rhartkopf
org.graylog2.restclient.lib.APIException: API call failed GET http://@172.17.0.4:12900/users/rhartkopf returned 500 Internal Server Error body: java.lang.NullPointerException
        at org.graylog2.users.UserImpl.getFullName(UserImpl.java:90)
        at org.graylog2.rest.resources.users.UsersResource.toMap(UsersResource.java:491)
        at org.graylog2.rest.resources.users.UsersResource.get(UsersResource.java:121)
        at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        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:151)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:384)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:342)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
        at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
        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:297)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1030)
        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:622)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

        at org.graylog2.restclient.lib.ApiClientImpl$ApiRequestBuilder.execute(ApiClientImpl.java:436) ~[org.graylog2.graylog2-rest-client-0.92.3.jar:na]
        at org.graylog2.restclient.models.UserService.retrieveUserWithSessionId(UserService.java:169) ~[org.graylog2.graylog2-rest-client-0.92.3.jar:na]
        at lib.security.RedirectAuthenticator.authenticateSessionUser(RedirectAuthenticator.java:122) [graylog2-web-interface.graylog2-web-interface-0.92.3.jar:0.92.3]
        at lib.security.RedirectAuthenticator.getUsername(RedirectAuthenticator.java:54) [graylog2-web-interface.graylog2-web-interface-0.92.3.jar:0.92.3]
        at controllers.SessionsController.index(SessionsController.java:62) [graylog2-web-interface.graylog2-web-interface-0.92.3.jar:0.92.3]

And from the server side:

2014-12-29 16:48:19,128 ERROR: org.graylog2.plugin.rest.AnyExceptionClassMapper - Unhandled exception in REST resource
java.lang.NullPointerException
        at org.graylog2.users.UserImpl.getFullName(UserImpl.java:90)
        at org.graylog2.rest.resources.users.UsersResource.toMap(UsersResource.java:491)
        at org.graylog2.rest.resources.users.UsersResource.get(UsersResource.java:121)
        at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        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:151)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:384)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:342)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
        at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
        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:297)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1030)
        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:622)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

When configuring and testing LDAP, the test appears to succeed, but doesn't return the results for the LDAP record:

image

Any help is appreciated. Thanks!

@joschi joschi added the bug label Dec 30, 2014

@joschi joschi added this to the 0.93 milestone Dec 30, 2014

@joschi

This comment has been minimized.

Contributor

joschi commented Dec 30, 2014

While the NullPointerException is still a bug, please verify that the user "rhartkopf" in your LDAP directory actually has a valid attribute for the user's display name and that this is the attribute you've configured as Display Name attribute in your LDAP settings in Graylog2.

@rhartkopf

This comment has been minimized.

rhartkopf commented Dec 30, 2014

The redacted results from an equivalent ldapsearch command are below. I am using 'cn' as the Display Name attribute.

rhartkopf@pribiloffur:~$ ldapsearch -x -H ldaps://ldap.example.com:636 -D "cn=at_svc_graylog2,o=example,c=com" -W -b "o=example,c=com" -s sub "(uid=rhartkopf)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=example,c=com> with scope subtree
# filter: (uid=rhartkopf)
# requesting: ALL
#

# rhartkopf, example, com
dn: cn=rhartkopf,o=example,c=com
objectClass: posixAccount
o: ate
cn: rhartkopf
uid: rhartkopf
memberUid: rhartkopf
username: rhartkopf
accountStatus: active
uidNumber: 5075
homeDirectory: /home/rhartkopf
loginShell: /bin/bash
gecos: rhartkopf via sealauth
description: rhartkopf via sealauth
gidNumber: 5000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
@kroepke

This comment has been minimized.

Member

kroepke commented Dec 30, 2014

Could you please provide a dump of your ldap settings in mongodb?

You can get it via:
$ echo "db.ldap_settings.find().pretty()" | mongo graylog2 | grep -v password

The command already removes the password related fields for convenience :)

Thanks!

@rhartkopf

This comment has been minimized.

rhartkopf commented Dec 30, 2014

{
        "_id" : ObjectId("54a1e697e4b058d291c8f72e"),
        "enabled" : true,
        "reader" : "admin",
        "search_base" : "o=example,c=com",
        "username_attribute" : "cn",
        "ldap_uri" : "ldaps://ldap.example.com:636/",
        "trust_all_certificates" : false,
        "system_username" : "cn=at_svc_graylog2,o=example,c=com",
        "active_directory" : false,
        "principal_search_pattern" : "(uid={0})",
        "use_start_tls" : false
}

And the users after attempting login, since that's where the null value is:

{
        "_id" : ObjectId("54a1e69ee4b058d291c8f737"),
        "username" : "rhartkopf",
        "external_user" : true,
        "email" : "rhartkopf@localhost",
        "permissions" : [
                "*"
        ],
        "password" : "User synced from LDAP.",
        "full_name" : null
}

@joschi joschi self-assigned this Dec 31, 2014

joschi added a commit that referenced this issue Dec 31, 2014

@joschi

This comment has been minimized.

Contributor

joschi commented Dec 31, 2014

@rhartkopf Your LDAP settings look reasonable and there's also no trailing whitespace in the display name attribute which is what I suspected at first.

Did you change the display name attribute in your LDAP settings after the first login of the user "rhartkopf"?

Could you please, just for a cross-check, change the display name attribute in your LDAP settings from cn to username and login again with that user?

@rhartkopf

This comment has been minimized.

rhartkopf commented Jan 5, 2015

I cleared the settings/users and attempted with the username attribute. Error messages are exactly the same as above. DB settings, redacted:

> db.ldap_settings.find().pretty()
{
        "_id" : ObjectId("54a1e697e4b058d291c8f72e"),
        "enabled" : true,
        "reader" : "admin",
        "search_base" : "o=example,c=com",
        "username_attribute" : "username",
        "ldap_uri" : "ldaps://ldap.example.com:636/",
        "trust_all_certificates" : false,
        "system_username" : "cn=at_svc_graylog2,o=example,c=com",
        "active_directory" : false,
        "principal_search_pattern" : "(uid={0})",
        "use_start_tls" : false
}
> db.users.find().pretty()
{
        "_id" : ObjectId("54aab600e4b0b8c8e1571c2f"),
        "username" : "rhartkopf",
        "external_user" : true,
        "email" : "rhartkopf@localhost",
        "permissions" : [
                "*"
        ],
        "password" : "User synced from LDAP.",
        "full_name" : null
}
@joschi

This comment has been minimized.

Contributor

joschi commented Jan 12, 2015

This might be related to how the attributes are added in Graylog2: https://github.com/Graylog2/graylog2-server/blob/0.92.3/graylog2-server/src/main/java/org/graylog2/security/ldap/LdapConnector.java#L117-119

@rhartkopf Does using uid as display name work? Which LDAP server (exact product name and version) are you using?

@rhartkopf

This comment has been minimized.

rhartkopf commented Jan 12, 2015

Using uid yields the same results. The server was written in-house, but the results of ldapsearch are standard and there are no errors server-side as shown in the results above: #837 (comment)

@rhartkopf

This comment has been minimized.

rhartkopf commented Jan 12, 2015

I tested with http://packages.graylog2.org/nightly-builds/graylog2-0.93.0-SNAPSHOT-20150112150701.tar.gz and the problem appears to be solved. The test still "succeeds" with a blank LDAP entry, but login occurs with no errors.

image

@joschi

This comment has been minimized.

Contributor

joschi commented Jan 13, 2015

I couldn't reproduce the issue with OpenLDAP or ApacheDS, so I guess it's some kind of incompatibility between your homegrown LDAP server and the LDAP library (also from the Apache Directory project) we're using in Graylog2.

Since the immediate error (the NPE) is now handled properly and the username is being used as fallback for the display name (in your case it's identical with the username or cn anyway), I'm closing this issue now. Please feel free to add a comment if anything new comes up.

@joschi joschi closed this Jan 13, 2015

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