SAML Authentication error


(Jack Lauret) #1

I am trying to configure SAML authentication together with our Windows 2016 ADFS server but whatever I try I am running into the following error:

Authentication to realm saml1 failed - SAML Attribute [nameid:persistent] for [attributes.principal] not found in [nameid=[username@domain.local]]

My SAML configuration looks like this:
type: saml
order: 1
idp.metadata.path: saml\FederationMetadata.xml
idp.entity_id: "http://federation.domain.local/adfs/services/trust"
sp.entity_id:  "https://elkserver.domain.local/"
sp.acs: "https://elkserver.domain.local:443/api/security/v1/saml"
sp.logout: "https://elkserver.domain.local/logout"
attributes.principal: "nameid:persistent"
nameid_format: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

On the ADFS side, I have just configured the outgoing claim for User-Principal-Name to nameid


Any help would be appreciated.

(Ioannis Kakavas) #2


The error you get is because you have configured Elasticsearch to try and map the principal attribute from the NameID with persistent format that it finds in the subject of the SAML Assertion. Since this is not found in the assertion, authentication fails because principal is required.

nameid:persistent has a specific meaning for the Elastic Stack SAML SP as described here . I'm not very familiar with ADFS but the screenshot you provided seems to imply that ADFS will be sending the UPN as a SAML Attribute in the SAML Response's Attribute Statement with a name of nameid and not as the SAML NameID in the Assertion's subject. Or that it is releasing it as a NameID but with the wrong format (if I remember correctly from other posts in the forums, the default format for NameID in ADFS is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. You can verify my assumption by setting the SAML log to trace in Elasticsearch with

curl -H "Content-Type: application/json" -XPUT -uelastic 'https://<ES_FQDN>:9200/_cluster/settings' -d'
 "transient" : {
     "" : "TRACE"

and looking at your the elasticsearch logs ( we print out the SAML Response and the attributes we extract from it ). Alternatively you can use a browser plugin (i.e. SAML tracer) to see the SAML Response in your browser.

When it comes to solutions for your problem now, you can either:

  • Figure out how to configure ADFS to send out a NameID with format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • Map principal to the claim that you have configured ADFS to release, if this is the case.

(Jack Lauret) #3

Thank you Ioannis,

in the end, I only had to change the ADFS claim from nameid to nameid:persistent.

Now I can logon with SAML. Unfortunately the roles are not working yet (you can see that I map them to the roles claim).

(Ioannis Kakavas) #4

Can you be a little more specific please ? :slight_smile:

From the original configuration you shared, I don't see you mapping the roles claim from ADFS into anything in Elasticsearch. See the relevant part of our guide
I think the easiest path forward is to map the roles claim ( i.e. ) to the groups attribute of the Elasticsearch user by adding

attributes.groups: ""

to your SAML realm configuration.
Then you can use the values of the groups attribute to do map users to Elasticsearch roles as described in here

(Jack Lauret) #5

Hi Ionannis,

Sorry, I wasn not specific because I planned to fix this myself (as I did).

The thing is that you need to manage saml roles via the api and not via a mapping file as I started with.
I did change the ADFS claims a bit:

So I map Token-Groups - Unqualified Names to the predefined Role outgoing claim. Then, when I use the api to assign a role to one of the users groups it works.
As a test I used this:

PUT /_xpack/security/role_mapping/saml-superuser
"roles": [ "superuser" ],
"enabled": true,
"rules": { "all": [
    { "field": { "": "saml1" } },
    { "field": { "groups": "MyGroup" } }
 ] }

Thank you for pointing me in the right direction!

(system) #6

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