Why is LDAP no longer working after upgrading to 4.1?

[Alan_Bradley]

I just upgraded my install to 4.1 and LDAP auth is no longer working. The failsafe user is all I can use.

Previously I had roles assigned to users (groups were not part of our configuration)

[gkanapathy]

We will merge the questions. All the answers will be kept. If you have the problem, you don't know which the solution is yet. Presumably

[jrodman]

well, there could be a more complex answer to that one, but this works too.

[the_wolverine]

This is a different issue.

[Johnvey]

This should be merged into http://answers.splunk.com/questions/1053/why-is-ldap-no-longer-working-after-upgrading-to-4-1

[the_wolverine]

In version 4.1 Splunk is able to use, side by side, LDAP and SplunkAuth.

Any users configured in your $SPLUNK_HOME/etc/passwd file will be able to login.

Splunkauth accounts takes precedence over LDAP (as of version 4.1), any Splunk users with a conflicting LDAP login will bypass LDAP and be able to login using their Splunkauth credentials.

If you migrated from version 4.0x -> 4.1, there is a migration bug where the SplunkAuth users are not disabled. If you are encountering this issue the solution is to delete any conflicting Splunk auth accounts, either via UI by browsing to

Manager >> Access Controls >> Users

As an Admin user, you will be able to see, in table format, your users along with their Authentication system (LDAP or Splunk) and any assigned roles. Click Delete for those users who are required to authentication using LDAP credentials.

Or, delete these conflicts directly from the $SPLUNK_HOME/etc/passwd file.

The users should now be able to login with their LDAP credentials.

[the_wolverine]

We have discovered another scenario where LDAP will not work in 4.1 when the ldap implementation uses a multi-valued groupMappingAttribute.

For example, if you've got:

groupMappingAttribute = uid 

And the LDAP entry contains:

uid: jschmoe 
uid: jschmoe@moe.com 

LDAP authentication will not work. This will be fixed in 4.1.1.

[the_wolverine]

In 4.1 we have a bug in the migration where a previous hack to LDAP configuration is not properly migrated and thus will not work.

An indication of hitting this bug is the following error in splunkd.log:

AuthenticationManagerLDAP - LDAP config [LDAP Strategy Name] is missing required setting: groupMemberAttribute

The modification required to your authentication.conf involves setting your groupMappingAttribute and groupMemberAttribute to the same value as your userNameAttribute.

Example:

userNameAttribute = uid
groupMappingAttribute = uid
groupMemberAttribute = uid

OR

userNameAttribute = sAMAccountName
groupMappingAttribute = sAMAccountName
groupMemberAttribute = sAMAccountName

NOTE : THIS ONLY APPLIES TO CASES WHERE USERS ARE MAPPED DIRECTLY TO SPLUNK ROLE. That is, if your userBaseDN = groupBaseDN, then this applies to you.

[matt · Accepted solution]

We have seen instances when LDAP is configured not use groups that 4.1 is not reading the config the same way that 4.0.

In 4.0 Splunk didn't care if you had a value like:

groupMappingAttribute = dn
groupMemberAttribute = uniqueMember 

In 4.1 Splunk cares a bit more and since those values wont be present we should change them to something that does. If you update those two values to

groupMappingAttribute = uid
groupMemberAttribute = uid 

You should be able to login again.

[Chris_R_]

In case someone runs into a AD issue, I just spoke with a AD user having auth issues. They got their auth working by making groupMappingAttribute, groupMemberAttribute, groupNameAttribute = CN

[Marklar]

Note that this should only be an issue if you were treating users as their own groups by setting groupBaseDN to the same value as userBaseDN.

Previously, groupMappingAttribute and groupMemberAttribute were ignored for this config. This implies that you couldn't have separate group and user entries in that same tree, which has been fixed.

As Matt pointed out, you can fix your configuration by setting groupMappingAttribute and groupMemberAttribute to the same value as userNameAttribute. This means that when we interpret the user entry as a group, we treat the username as its only member.