I am on 4.3 and have followed the instructions from Authentication.conf and Setup User Authentication
in setting up my configuration file.
I am recieving the following error:
03-27-2012 10:20:54.553 -0400 ERROR AuthenticationManagerLDAP - user="user1.lastname" has matching LDAP groups with strategy="suAdmins", but none are mapped to Splunk roles
Here is a copy of my authentication.conf (anonymized):
[authentication]
authSettings = suAdmins,otherGroup1,otherGroup2
authType = LDAP
[roleMap_suAdmins]
suadmin = user1.lastname;user2.lastname;user3.lastname;user4.lastname;user5.lastname
[suAdmins]
SSLEnabled = 1
anonymous_referrals = 0
bindDN = user.lastname@domain.com
bindDNpassword = password
charset = utf8
groupBaseDN = DC=domain,DC=com
groupBaseFilter = (&(objectCategory=person)(objectClass=user))
groupMappingAttribute = samaccountname
groupMemberAttribute = samaccountname
groupNameAttribute = samaccountname
host = ip_address
nestedGroups = 0
network_timeout = 20
port = 636
realNameAttribute = cn
sizelimit = 1000
timelimit = 15
userBaseDN = dc=Domain,dc=com
userBaseFilter = (&(objectCategory=person)(objectClass=user))
userNameAttribute = samaccountname
What I think is going on is that the returned result does match exactly with the [roleMap_] values ... though I have tried several different permutations with the User and Group attributes, and also with the roleMap values for suadmin.
I have tried samaccountname, dn, uid, cn, name for the Group and User attributes ... and I have changed the roleMap values to the expected output from each of those types requests. I have also tried quotes around the values in roleMap_.
Any thoughts on what I might be missing?
It is working now. Below is an example and some notes.
NOTE: The curly braces are place holders for real values; do not use the curly braces.
[authentication]
authSettings = {LDAP_User_Connection},{LDAP_Group_Connection_1},{LDAP_Group_Connection_2}
authType = LDAP
If you have multiple configured and enabled LDAP settings (new in 4.3), the authSettings are first-come-first-served based on the list order of the values. This is especially true when using the new feature of mapping LDAP users to roles. If the specific user matches a group defined in the {LDAP_Group_Connection} prior to reaching the {LDAP_User_Connection}, Splunk will stop looking and never match the user to your specific role.
When using multiple connection settings, Splunk will generate INFO warnings for users who are not found in a connection setting when they attempt to sign in; Splunk then moves to the next connection setting and tries again.
[roleMap_{name}]
{role} = {CaseSensitiveUser1.LastName};{CaseSensitiveUser2.Lastname}
The Role values are strictly case sensitive (for example McDonald); it must match exactly what LDAP has for the samaccountname attribute.
If there is one misspelled or incorrectly cased name, Splunk may not match for any other names even if they are spelled and cased correctly. Why this happens, I do not know.
[{LDAP_User_Connection}]
SSLEnabled = 1
anonymous_referrals = 0
bindDN = {username}
bindDNpassword = {password}
charset = utf8
groupBaseDN = dc=domainname,dc=com
groupBaseFilter = (|(samaccountname={CaseSensitiveUser1.LastName})(samaccountname={CaseSensitiveUser2.Lastname}))
groupMappingAttribute = samaccountname
groupMemberAttribute = samaccountname
groupNameAttribute = samaccountname
host = {IP or HostName}
nestedGroups = 0
network_timeout = 20
port = 636
realNameAttribute = cn
sizelimit = 2
timelimit = 15
userBaseDN = dc=domainname,dc=com
userBaseFilter = (&(objectCategory=person)(objectClass=user))
userNameAttribute = samaccountname
groupBaseDN and userBaseDN values must match exactly including case sensitivity for the path. dc=domainname,dc=com is not the same as DC=domainname,DC=com
groupBaseFilter does not require values to be case sensitive, however it probably best to match the names exactly as they are for the [roleMap_{name}] {role} values
sizelimit can be adjusted to match the number of expected objects returned based on the explicit groupBaseFilter
It is working now. Below is an example and some notes.
NOTE: The curly braces are place holders for real values; do not use the curly braces.
[authentication]
authSettings = {LDAP_User_Connection},{LDAP_Group_Connection_1},{LDAP_Group_Connection_2}
authType = LDAP
If you have multiple configured and enabled LDAP settings (new in 4.3), the authSettings are first-come-first-served based on the list order of the values. This is especially true when using the new feature of mapping LDAP users to roles. If the specific user matches a group defined in the {LDAP_Group_Connection} prior to reaching the {LDAP_User_Connection}, Splunk will stop looking and never match the user to your specific role.
When using multiple connection settings, Splunk will generate INFO warnings for users who are not found in a connection setting when they attempt to sign in; Splunk then moves to the next connection setting and tries again.
[roleMap_{name}]
{role} = {CaseSensitiveUser1.LastName};{CaseSensitiveUser2.Lastname}
The Role values are strictly case sensitive (for example McDonald); it must match exactly what LDAP has for the samaccountname attribute.
If there is one misspelled or incorrectly cased name, Splunk may not match for any other names even if they are spelled and cased correctly. Why this happens, I do not know.
[{LDAP_User_Connection}]
SSLEnabled = 1
anonymous_referrals = 0
bindDN = {username}
bindDNpassword = {password}
charset = utf8
groupBaseDN = dc=domainname,dc=com
groupBaseFilter = (|(samaccountname={CaseSensitiveUser1.LastName})(samaccountname={CaseSensitiveUser2.Lastname}))
groupMappingAttribute = samaccountname
groupMemberAttribute = samaccountname
groupNameAttribute = samaccountname
host = {IP or HostName}
nestedGroups = 0
network_timeout = 20
port = 636
realNameAttribute = cn
sizelimit = 2
timelimit = 15
userBaseDN = dc=domainname,dc=com
userBaseFilter = (&(objectCategory=person)(objectClass=user))
userNameAttribute = samaccountname
groupBaseDN and userBaseDN values must match exactly including case sensitivity for the path. dc=domainname,dc=com is not the same as DC=domainname,DC=com
groupBaseFilter does not require values to be case sensitive, however it probably best to match the names exactly as they are for the [roleMap_{name}] {role} values
sizelimit can be adjusted to match the number of expected objects returned based on the explicit groupBaseFilter
I tried the Filter suggested above. Didn't work; I received the same error as before. Prior to a more concise Filter I also bumped up my return results to 10K and added a few more seconds to timeout ... that did not work either (actual return results was around 5500 for the specific OU when tested in ADUC and using 'nix LDAP Search)
I don't believe the results are the issue .. re-reading the error I have come to the conclusion that it is possible the result set from the LDAP query is not matching exactly the values in
[roleMap_suAdmins]
suadmin = user1.lastname;user2.lastname;user3.lastname;user4.lastname;user5.lastname
When I run ADUC or ldapsearch ... the returns I get match what i have in the rolemap ... so at this point I'm not sure where the disconnect is. To prove my theory I went verbose (DEBUG) on 'AuthenticationManagerLDAP' and here is what I saw:
03-28-2012 08:28:34.672 -0400 DEBUG AuthenticationManagerLDAP - Attempting to get user information for user="user1.lastname" from strategy="suAdmins"
03-28-2012 08:28:34.692 -0400 DEBUG AuthenticationManagerLDAP - Attempting to get roles for user="user1.lastname" with DN="CN=User1.Lastname,OU=OC,OU=Accounts,DC=domain,DC=com" in strategy="suAdmins"
03-28-2012 08:28:34.693 -0400 DEBUG AuthenticationManagerLDAP - Mapping groups for user="user1.lastname" for group DN="CN=User1.Lastname,OU=OC,OU=Accounts,DC=domain,DC=com"
03-28-2012 08:28:34.693 -0400 DEBUG AuthenticationManagerLDAP - Matching group="user1.lastname" is not mapped to any roles
03-28-2012 08:28:34.693 -0400 ERROR AuthenticationManagerLDAP - user="user1.lastname" has matching LDAP groups with strategy="suAdmins", but none are mapped to Splunk roles
So if I am reading the above DEBUG correctly, then the LDAP query is finding and returning results for both the Group and User; however it is not matching the values in roleMap_.
I have tried "User1.Lastname" (with and without quotes, upper and lower case) and I have tried "CN=User1.Lastname,OU=OC,OU=Accounts,DC=domain,DC=com" in the roleMap_ values ... still no go.
Yes, I am using samaccountname still.
The debug log stated 'Mapping groups for user="user1.lastname" for group DN="CN=User1.Lastname,OU=OC,OU=Accounts,DC=domain,DC=com"'; so I tried the FQDN for the roleMap_ value to rule it out as a possibility; otherwise I have stuck with the samaccountname value.
Should be looking for samaccountname (or 'user_id') vs. fqdn based on the original config you posted.
Hmmm. You may be returning more than 1,000 "groups" (users). You could test this with ldapsearch from CLI, or just narrow the group filter for this one-off as the majority of your access comes from group mappings in other strategies.
groupBaseFilter = (|(samaccountname=user1.lastname)(samaccountname=user2.lastname)(samaccountname=user3.lastname)(samaccountname=user4.lastname)(samaccountname=user5.lastname))
Thank you for the quick responses.
My 2 'otherGroups' handle the bulk of the user access already, and they work as intended with references to the actual group memberships.
Am I mis-reading the 4.3 documentation then ... I thought the purpose of "Map users directly to roles" was to bypass the need for an actual LDAP group ... using the users name as the the "group" attribute essentially makes the user a group as far as Splunk sees it.
Here is the quote I'm seeing "If you need to map users directly to Splunk roles, you can do so by setting the groupBaseDN to the value of userBaseDN. Also, set the attributes for groupMappingAttribute, groupMemberAttribute, and groupNameAttribute to the same attribute as userNameAttribute."
In your authentication.conf file:
[roleMap_suAdmins]
suadmin = user1.lastname;user2.lastname;user3.lastname;user4.lastname;user5.lastname
Try changing this line:
suadmin = AD_GROUP_NAME
And make sure that user1.lastname is a member of that group in AD
Also, we use this under the [suAdmins] stanza:
groupBaseFilter = (objectClass=group)
groupMappingAttribute = dn
groupMemberAttribute = member
groupNameAttribute = cn
We're also on AD authentication. Hope this helps!