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.
