[graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
Hi Jason!
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 (port 12900 of your graylog server).
That logs all kinds of details about the searches performed and the
entities returned.
With regards to "flat" vs" "hilly" AD topologies, the group search is using
subtree scope, so deeper hierarchies should not be a problem, the same is
true (but this hasn't changed to pre-1.2 versions) for user search. I'm
unsure what changes when AD is trying to flatten the hierarchy, but
apparently the error:
2015-09-08T20:56:40.614-04:00 ERROR [DefaultAttribute]
ERR_04486_VALUE_ALREADY_EXISTS The value '20150728213900.0Z' already exists
in the attribute (dSCorePropagationData)
comes out of the library we use for connecting. I'll check the code to see
if that breaks everything.
If you are interested, the relevant code starts
here:
https://github.com/Graylog2/graylog2-server/blob/1.2/graylog2-server/src/main/java/org/graylog2/security/ldap/LdapConnector.java#L121-121
Please let me know any additional things I need to be able to reproduce
this issue.
Thanks,
Kay
On Wednesday, 9 September 2015 03:07:31 UTC+2, Jason Haar wrote:
>
> Hi there
>
> Says it all really. After upgrading from 1.16 to 1.2rc4, none of the LDAP
> (actually ActiveDirectory) accounts work - even the Admin ones (thankfully
> the standard backdoor "admin" account still works)
>
> I tried logging in with a new LDAP account - it also fails (default user
> mode: Reader). But refreshing the "user" area shows the new account - so
> it's been created even though I can't log in with it. The login page error
> says "sorry those creds aren't valid"
>
> I didn't change the LDAP User Mapping area [ which is set to
> "(&(objectClass=user)(userPrincipalName={0}))" ], but changed the new Group
> Mapping to
>
> (&(objectClass=group)(cn=*))
>
> with "Group Name Attribute" set to "cn". I also used ldapsearch to test
> that filter - it works fine, returning a bunch of groups
>
> However, after filling in that section I go to "LDAP Group Mapping" and it
> says there are no LDAP groups - so something's wrong in the group section
> of the "LDAP Settings". We are running an AD forest and I'm logging in
> using an account from a child domain (we don't have user accounts in the
> parent) - so could this be a recursion problem? However, the logs do show
> evidence of the LDAP query bringing back groups from the child domains - so
> it all looks good as far as I can see
>
> I've turned up the Authentication logging to "debug" and this shows up on
> any LDAP login event. That "ERR_04486_VALUE_ALREADY_EXISTS" is the only
> thing that looks like an error?
>
>
> 2015-09-08T20:56:25.519-04:00 DEBUG [ModularRealmAuthenticator] Realm
> [org.graylog2.security.realm.SessionAuthenticator@79ea39fc] does not
> support token org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false. Skipping realm.
> 2015-09-08T20:56:25.520-04:00 DEBUG [ModularRealmAuthenticator] Realm
> [org.graylog2.security.realm.AccessTokenAuthenticator@5d75e8f0] does not
> support token org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false. Skipping realm.
> 2015-09-08T20:56:40.614-04:00 ERROR [DefaultAttribute]
> ERR_04486_VALUE_ALREADY_EXISTS The value '20150728213900.0Z' already exists
> in the attribute (dSCorePropagationData)
> 2015-09-08T20:56:41.964-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User
> usern...@domain.name: No group mapping for ldap group
> 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [usern...@domain.name] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm]
> AuthenticationInfo caching is disabled for info [usern...@domain.name].
> Submitted token: [org.apache.shiro.authc.UsernamePasswordToken -
> usern...@domain.name, rememberMe=false].
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [null] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] No
> AuthenticationInfo found for submitted AuthenticationToken
> [org.apache.shiro.authc.UsernamePasswordToken - usern...@domain.name,
> rememberMe=false]. Returning null.
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] Looked up
> AuthenticationInfo [null] from doGetAuthenticationInfo
> 2015-09-08T20:56:41.973-04:00 DEBUG [AuthenticatingRealm] No
> AuthenticationInfo found for submitted AuthenticationToken
> [org.apache.shiro.authc.UsernamePasswordToken - usern...@domain.name,
> rememberMe=false]. Returning null.
>
Re: [graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
On 09/09/15 20:41, Kay Roepke wrote:
> 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 (port 12900 of your graylog server).
>
Err - humor me - this is all new to me. I can't see a System/Logging
section - I can see a System/Loggers section - but I can't see how that
relates to LDAP settings - nothing shouts out as being related
Anyway, I simply cranked all graylog-server logging up to TRACE via the
"Logging" page on graylog-web and I assume that does the same thing (in
a noisier manner!)
I don't see any new errors (but they wouldn't be in TRACE?), but I see
vast amounts of LDAP data being recorded - so that looks fine (" egrep
-i 'UserServiceImpl|ldap' "). There's a lot of binary data in there -
I'd guess the login event pulls all fields? (BTW really shouldn't - that
slows things down - especially if there's a WAN involved). So you get
ones like "msexchrecordedname" - which is a 4K binary blob - and one
I'm looking at right now isn't even mine. I'm the only user on the
system, I would have thought graylog would only pull back details from
my account?
How does this new LDAP group-role mapping work? Is graylog trying to
suck out all groups from LDAP to populate the mapping page? The Global
Catalog of our AD forest is over 300MB in size if you were to try to
scrape the lot... I know I can put a filter in there - but as it's not
working with "(objectClass=group)" I don't think there's much point in
making it less likely to work ;-)
Anyway, these TRACE logs might mean something...?
015-09-09T05:46:52.776-04:00 TRACE [DelegatingSubject] attempting to get
session; create = false; session is null = true; session has id = false
2015-09-09T05:46:52.776-04:00 TRACE [DefaultSubjectDAO] Session storage
of subject state for Subject
[org.apache.shiro.subject.support.DelegatingSubject@7685d279] has been
disabled: identity and authentication state are expected to be
initialized on every request or invocation.
2015-09-09T05:46:52.776-04:00 TRACE [DefaultSecurityManager] This
org.apache.shiro.mgt.DefaultSecurityManager instance does not have a
[org.apache.shiro.mgt.RememberMeManager] instance configured.
RememberMe services will not be performed for account [ja...@nz.our.domain].
2015-09-09T05:46:52.776-04:00 TRACE [DelegatingSubject] attempting to
get session; create = false; session is null = true; session has id = false
--
Cheers
Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/55F0062D.3010303%40trimble.com.
For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
Not sure if this helps but...
Search Base DN should be the OU parent where you want any valid users to be
found for login
OU=User Accounts,DC=ochsner,DC=org
User Search Pattern should match the username users will input to login
(&(objectClass=user)(sAMAccountName={0}))
Group Search Base DN can be similar to your user search base DN. The OU where
your groups live.
OU=Groups Live Here,DC=ochsner,DC=org
Group Object Class should just be:
group
Group Name Attribute should just be:
cn
The example text in red is usually helpful. If you've already got those fields
set appropriately disregard!
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/914efb85-a462-48b0-9c0f-e74657d6e18a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
What Drew said, but starting with RC.4 the Group Object Class is Group
Search Filter and needs to be a valid filter:
(objectClass=group)
in the standard case.
On Wednesday, 9 September 2015 16:41:17 UTC+2, Drew Miranda wrote:
>
> Not sure if this helps but...
>
> Search Base DN should be the OU parent where you want any valid users to
> be found for login
> OU=User Accounts,DC=ochsner,DC=org
>
> User Search Pattern should match the username users will input to login
> (&(objectClass=user)(sAMAccountName={0}))
>
> Group Search Base DN can be similar to your user search base DN. The OU
> where your groups live.
> OU=Groups Live Here,DC=ochsner,DC=org
>
> Group Object Class should just be:
> group
>
> Group Name Attribute should just be:
> cn
>
> The example text in red is usually helpful. If you've already got those
> fields set appropriately disregard!
>
>
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/d394e1d8-d62a-43fc-b404-920aa0d07e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
On 10/09/15 00:29, Kay Roepke wrote: > Would you be willing to give a snapshot build a try once I have it up? Sure thing - I'm still only got a single host test box - so it's no big thing if it breaks ;-) > > Not really, the interesting ones come from LdapConnector. OK, well here's what the following grep reports, after I remove what I assume are normal lines grep LdapConnector server.log.4|egrep -v ' DN CN=.* member\?$|Group Entry: Entry$' , manager=.., msexchrecordedname= 2015-09-09T05:46:52.504-04:00 TRACE [LdapConnector] Re-binding with DN CN= using password 2015-09-09T05:46:52.749-04:00 TRACE [LdapConnector] Binding DN CN= did not throw, connection authenticated: true So that binary blob shows up on it's own line (ie doesn't begin with a timestamp) - so there must be a carriage return in there - could that cause issues? -- Cheers Jason Haar Corporate Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/55F0B9A5.5020404%40trimble.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
Whoops - forgot to mention this was LDAPS to our Global Catalog LDAP service (that's the trick Microsoft uses to emulate "flattening" an AD hierarchy Also I just changed from LDAPS to LDAP so that I could sniff what's going on. According to wireshark the group search filter was working - returning data. However, if I removed the filter entirely, then I can log in via LDAP! So it's now back to the way it was before the upgrade. However, I need to figure out how to do the filter so as to get the LDAP mappings to Roles working. Also, if I even try the example filter "(objectClass=group)" - that breaks it again Thanks Jason -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/abaa8a07-0caf-41e0-a2bb-562938657321%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[graylog2] Re: upgrading graylog-server from 1.16 to 1.2rc4 totally broke all LDAP access
I just upgraded to 1.2 rc2 so I'll check my configuration tomorrow and see if it is helpful to you. For what it's worth the upgrade worked and ldap login and group mappings worked. -- You received this message because you are subscribed to the Google Groups "Graylog Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to graylog2+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/a279bcf6-8a28-474b-b14c-0752d04b0d13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
