# SAML AD ADFS yaml settings, troubleshooting and role mapping notes and insight (Solved)

**URL:** <https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859>\
**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:** 1\
**Showing post:** 2

<div class="post-metadata">

**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")

</div>

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).

---

_[View the full topic](https://discuss.elastic.co/t/saml-ad-adfs-yaml-settings-troubleshooting-and-role-mapping-notes-and-insight-solved/169859)._