SAML AD ADFS yaml settings troubleshooting and role mapping notes and insight part II (Solved)

Elastic Stack Elasticsearch
1

Continued from SAML AD ADFS yaml settings, troubleshooting and role mapping notes and insight (Solved)
Our ADFS team recognized that the kibana_gov and kibana_gov_admin group needed to be changed from domain local to global scope as step one to fixing the error. The next change was that we were using the member_of property so we switched to the Token-Groups - Unqualified Names claim. The ‘Token-Groups - Unqualified Names’ will give us ‘kibana_gov’ instead of ‘CN=kibana_gov,OU=Groups,OU=xxx,OU=xxx Agencies,DC=xxx,DC=xxx,DC=gov’. Overall we changed the group scope and updated the claim rule to use ‘Token-Groups - Unqualified Names’. We also changed the scope on the kibana_gov_admin group as well so that it would pass through as a role. At this stage we were able to login.

On the ADFS side we had:
Rule 1
Edit Claim Rules for Kibana QA
	Issuance Transform Rules
		Rule Name:		Issued Claims
			Send User ID		Name ID
			Get groups		<See claim rule>
			Send kibana only	<See claim rule>
Edit Rule - Send User ID
	Claim rule name: Send User ID
	Attribute Store: Active Directory
	Mapping of LDAP attributes to outgoing claim types:
		LDAP set to User-Principal-Name
		Outgoing Claim Type set to Name ID

Rule Language:
c:[Type == &quot;http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == &quot;AD AUTHORITY&quot;]
=&gt; issue(store = &quot;Active Directory&quot;, types = (&quot;http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;), query = &quot;;userPrincipalName;{0}&quot;, param = c.Value);
Rule 2
Get Groups
c:[Type == &quot;http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == &quot;AD AUTHORITY&quot;]
=&gt; add(store = &quot;Active Directory&quot;, types = (&quot;http://schemas.xmlsoap.org/claims/Group&quot;), query = &quot;;tokenGroups;{0}&quot;, param = c.Value);
Rule 3
Send Kibana Only
c:[Type == &quot;http://schemas.xmlsoap.org/claims/Group&quot;, Value =~ &quot;(?i).*kibana.*&quot;]
=&gt; issue(Type = &quot;http://schemas.microsoft.com/ws/2008/06/identity/claims/role&quot;, Value = c.Value);

The last part of this process was to gain access to Monitoring portions of the Management section such as Users, Roles and Indices. We got a permissions level error with Kibana when we tried to access these functions. This is due to the fact that even though a user authenticates using SAML and are identified to the Elastic Stack they are not automatically granted access to perform any actions or access any data. Your SAML users cannot do anything until they are assigned roles within the SAML realm. This can be done through either the add role mapping API or with authorization realms.

https://www.elastic.co/guide/en/elastic-stack-overview/6.5/saml-role-mapping.html

We ran the curl command below. The last portion of the url, admin, is the <name> section of the path parameters. From the Elastic website; "Path parameters for the command in the <name> section is a distinct name that identifies the role mapping. The name is used solely as an identifier to facilitate interaction via the API; it does not affect the behavior of the mapping in any way." A fairly important piece because I got hung up on trying to figure out what exactly the last portion of the command was referring to.

https://www.elastic.co/guide/en/elasticsearch/reference/6.5/security-api-put-role-mapping.html

curl -u elastic:new_password -X PUT "https://xxx.xxx.xxx:9200/_xpack/security/role_mapping/admin" --insecure -H 'Content-Type: application/json' -d'
{
"roles": ["superuser"],
"enabled": true,
"rules": { "all": [
{ "field": { "realm.name": "saml1" } },
{ "field": { "groups": "kibana_gov_admin", "kibana_gov } }
] }
}'

Overall Notes:

  • Note the @ character shouldn't have any problems being passed in ES/Kibana
  • ES can still use SAML 1.1, officially ES only supports SAML 2.0 but we didn't test if this field was needed or not. A check of your metadata.xml might be needed to see what attributes are populating for use in matching up the correct fields. For our environment having the nameid_format set to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified so SAML:1.1 did work.
  • These settings can work if fronted by a VIP
  • realm.name must match whats in your yaml block of the elasticsearch.yml file and the groups field may or may not need the full DN depending on how its configured in ADFS
  • name.id or nameid:persistent seems to be the appropriate implementation for attributes.principal but changing this to "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" may be needed with the implementation and metadata.xml info
  • SAML cannot use role mapping files to grant roles to users (skipped right over this by accident in the docs)
  • Kibana logs may not be of much use since the actual authentication is done by ES. ES logs are more important and you may to turn on Trace logging to get the appropriate logs.
1 Like
2

This actually not true, see my relevant comment in SAML AD ADFS yaml settings, troubleshooting and role mapping notes and insight (Solved) - #2 by ikakavas

Most errors are returned from Elasticsearch to Kibana as Exceptions so if one has only access to kibana logs, setting logging.verbose: true in kibana.yml will make sure that enough information will be printed there to start the troubleshooting. But in general, you are correct, ES logs are much more useful as the core of the SAML implementation is in Elasticsearch

1 Like
3

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.