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 - > [email protected], 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 - > [email protected], 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 > [email protected]: No group mapping for ldap group <XXX> > 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User > [email protected]: No group mapping for ldap group <XXX> > 2015-09-08T20:56:41.969-04:00 WARN [UserServiceImpl] User > [email protected]: No group mapping for ldap group <XXX> > 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm] Looked up > AuthenticationInfo [[email protected]] from doGetAuthenticationInfo > 2015-09-08T20:56:41.971-04:00 DEBUG [AuthenticatingRealm] > AuthenticationInfo caching is disabled for info [[email protected]]. > Submitted token: [org.apache.shiro.authc.UsernamePasswordToken - > [email protected], 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 - [email protected], > 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 - [email protected], > rememberMe=false]. Returning null. > 2015-09-08T20:56:41.973-04:00 DEBUG [AbstractAuthenticator] Authentication > successful for token [org.apache.shiro.authc.UsernamePasswordToken - > [email protected], rememberMe=false]. Returned account [ > [email protected]] > 2015-09-08T20:56:41.973-04:00 DEBUG [DefaultSubjectContext] No > SecurityManager available in subject context map. Falling back to > SecurityUtils.getSecurityManager() lookup. > 2015-09-08T20:56:41.973-04:00 DEBUG [DefaultSubjectContext] No > SecurityManager available in subject context map. Falling back to > SecurityUtils.getSecurityManager() lookup. > 2015-09-08T20:56:41.976-04:00 DEBUG [DefaultSessionManager] Creating new > EIS record for new session instance > [org.apache.shiro.session.mgt.SimpleSession,id=null] > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/graylog2/ec0440c4-7723-4f6b-8be3-b7e1488eac95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
