# SAML AD ADFS yaml settings, troubleshooting and role mapping notes and insight (Solved) **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [February 25, 2019, 3:10pm UTC](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859 "2019-02-25T15:10:46Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [February 25, 2019, 3:10pm UTC](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859/1 "2019-02-25T15:10:46Z")
Elasticsearch 6.5.4 Linux RPM First, appreciate the help of those who have posted useful troubleshooting methods/info in the forums and to Cyberyllium ([cyberyllium.io](http://cyberyllium.io)) and Thundercat Tech ([thundercattech.com](http://thundercattech.com)) for the extra hand in getting us up and running. Hopefully this guide will help others with SAML as well. _ **Reference Docs** _ Elasticsearch settings: > **[Configuring SAML single-sign-on on the Elastic Stack | Elastic Stack Overview...](https://www.elastic.co/guide/en/elastic-stack-overview/current/saml-guide.html)** Kibana settings: > **[Configuring Kibana | Elastic Stack Overview \[7.4\] | Elastic](https://www.elastic.co/guide/en/elastic-stack-overview/current/saml-kibana.html)** Very useful reference with known SAML implementation error messages/issues and how to troubleshoot them to a certain extent, #5 was one of our problems and it was an ADFS settings issue: > **[Common SAML issues | Elastic Stack Overview \[7.4\] | Elastic](https://www.elastic.co/guide/en/elastic-stack-overview/current/trb-security-saml.html)** Useful reference in the discussion forum: > [@ADFS SAML Authentication in Elastic Stack](https://discuss.elastic.co/t/adfs-saml-authentication-in-elastic-stack/129127): > > Hi there, I've tested Kibana /ElasticSearch 6.2.4 SAML Authentication with MS ADFS and noticed a strange behavoir. The elasticsearch.yml file contains the following config: xpack.security.authc.realms.saml1: type: saml order: 1 idp.metadata.path: [https://adfs.fqdn.com/federationmetadata/2007-06/federationmetadata.xml](https://adfs.fqdn.com/federationmetadata/2007-06/federationmetadata.xml) idp.entity\_id: "[http://adfs.fqdn.com/adfs/services/trust](http://adfs.fqdn.com/adfs/services/trust)" sp.entity\_id: "[https://kibana.fqdn.com/](https://kibana.fqdn.com/)" sp.acs: "[https://kibana.fqdn.com:443/api/security/v1/saml](https://kibana.fqdn.com:443/api/security/v1/saml)" sp.logout: "[h…](https://kibana.fqdn.com/logout) SAML blog that gave us a basic blueprint to work off of: > **[SAML Authentication and the Elastic Stack](https://www.elastic.co/blog/how-to-enable-saml-authentication-in-kibana-and-elasticsearch)** > > The Elastic Stack is a SAML 2.0 compliant Service Provider that implements the Web Browser SSO and Single Logout profiles. Kibana and Elasticsearch are the two major components of the Elastic Stack that contribute to the SAML related functionality. **Working SAML sections of our elasticsearch.yml and kibana.yml:** ```auto #--------------------------------- ES SAML -------------------------------------------- # ##Enable the token service for SAML 12/11/18 - Tim xpack.security.authc.token.enabled: true ###These are the settings needed to configure and implement for SAML authentication. -Ryan xpack.security.authc.realms.saml1: type: saml order: 1 idp.metadata.path: "https://xxx.xxx.xxx.gov/FederationMetadata/2007-06/FederationMetadata.xml" idp.entity_id: "http://xxx.xxx.xxx.gov/adfs/services/trust" sp.entity_id: "https://kibana.gov" sp.acs: "https://kibana.gov:443/api/security/v1/saml" sp.logout: "https://kibana.gov/logout" attributes.principal: "nameid" attributes.groups: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" nameid_format: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" #--------------------------- Kibana SAML ---------------------------------------------- ###Below is additional information that may be needed to incorporate SAML. xpack.security.sessionTimeout: 1800000 xpack.security.authProviders: [saml, basic] server.xsrf.whitelist: [/api/security/v1/saml] ###If our Kibana instance is behind a proxy, you may also need to add configuration to tell Kibana ###how to form its public URL. #xpack.security.public: # protocol: https # hostname: kibana-qa.svc.ny.gov # port:443 xpack.security.public.protocol: "https" xpack.security.public.hostname: "kibana.gov" xpack.security.public.port: "443" ``` I believe the original error, that I forgot to annotate, was due to the fact that we had the wrong attributes.principal defined and potentially nothing more on our ES yaml side. For this field its seems like **nameid or nameid:persistent** will be the correct info for most deployments. Unfortunately we tried more combinations of the nameid\_format and attributes.principal fields so we hit a few different errors along the way. The way we figured out that the nameid\_format field was correct for our deployment was when error #5 in the Common SAML Issues link, "Authentication to realm my-saml-realm failed - Provided SAML response is not valid for realm saml/my-saml-realm (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response: Code=urn:oasis:names:tc:SAML:2.0:status:AuthnFailed Message=null Detail=null])" started showing in our ES logs. This error indicated that ADFS didn't like the SAML version we were using and ADFS was stating the same thing on its end so we went back to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. After that error was fixed it seemed like the information we were using for the attributes.principal was the problem. From the info our colleagues provided and the settings in the thread listed above we changed the attributes principal to "nameid" which worked in that it provided us with new errors to troubleshoot. Specifically that ADFS was getting different errors and when we tried to sign in via Chrome we received a **{"message":"action [indices:data/read/search] is unauthorized for user [username@.gov]: [security\_exception] action [indices:data/read/search] is unauthorized for user [username@.gov]","statusCode":403,"error":"Forbidden"}** error. This is a good time to use the _SAML Message Decoder_ app in Chrome which gave us insight into things being passed in the session such as kibana\_gov and therefore the ability to troubleshoot what was working and what wasn’t. (Info continues here: [SAML AD ADFS yaml settings troubleshooting and role mapping notes and insight part II (Solved)](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-part-ii-solved/169860)) ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [February 25, 2019, 4:07pm UTC](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859/2 "2019-02-25T16:07:35Z")
This is awesome @Ryan_Downey , thanks for taking the time to document your experience. I'll add a few clarifications in case these prove helpful for others too. > [@Ryan\_Downey](#): > > The way we figured out that the nameid\_format field was correct for our deployment was when error #5 in the Common SAML Issues link, "Authentication to realm my-saml-realm failed - Provided SAML response is not valid for realm saml/my-saml-realm (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response: Code=urn:oasis:names:tc:SAML:2.0:status:AuthnFailed Message=null Detail=null])" started showing in our ES logs. I would expect that error to be: `[SAML Response is not a 'success' response: Code=urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy Message=null Detail=null]` We have recently updated our documentation to explain why this can happen, see #5 in : [Common SAML issues | Elasticsearch Guide [master] | Elastic](https://www.elastic.co/guide/en/elastic-stack-overview/master/trb-security-saml.html) > [@Ryan\_Downey](#): > > his error indicated that ADFS didn't like the SAML version we were using and ADFS was stating the same thing on its end so we went back to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. Just a comment here that this is not about the SAML version, this is still SAML2.0 and it is the only version of the standard that the Elastic Stack supports. This is about the format of the NameID where the URN didn't change in SAML 2.0 compared to SAML 1.1 and remained `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` . This means that ADFS by default releases NameIDs with `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` format instead of `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` format. > [@Ryan\_Downey](#): > > This is a good time to use the _SAML Message Decoder_ app in Chrome which gave us insight into things being passed in the session s Browser plugins decoding SAML messages are very helpful for troubleshooting, I just wanted to point out that this information is also logged at `TRACE` level in the elasticsearch.log as discussed in the last bullet in [Common SAML issues | Elastic Stack Overview [7.4] | Elastic](https://www.elastic.co/guide/en/elastic-stack-overview/current/trb-security-saml.html). ---
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [February 25, 2019, 4:11pm UTC](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859/3 "2019-02-25T16:11:31Z")
Ioannis, Appreciate the kind words and extra insight/clarification of this. It took some time to write up but hopefully it'll help others get their environments up and running. Enjoy the rest of your day! Ryan ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 25, 2019, 4:11pm UTC](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859/4 "2019-03-25T16:11:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.