X-pack Azure AD SAML auth

(William Hall) #1

Were having difficulty troubleshooting getting saml working with our Azure AD.
i have been following this thread and has been helpful and we have run into a similar issue. We are now getting a 401 error when trying to login. From the logs it seems to be a SAML metadata issues i was thinking from the metadata created by ES. i created the metadata with the cmd /usr/share/elasticsearch/bin/x-pack/saml-metadata using no options just take the configs that are entered. The SAML/Azure admin and I are both unsure why this is still an issue. Below are the error codes we get from the browser:

{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [] for action [cluster:admin/xpack/security/saml/authenticate], with { header={ WWW-Authenticate="Basic realm=\"security\" charset=\"UTF-8\"" } } :: {"path":"/_xpack/security/saml/authenticate","query":{},"body":"{\"ids\":[],\"content\":\

and in the ES logs we find:

The XML Signature of this SAML message cannot be validated. Please verify that the saml realm uses the correct SAMLmetadata file/URL for this Identity Provider
[2018-03-28T21:42:39,927][WARN ][o.e.x.s.a.AuthenticationService] [magellan-elasticsearch-data-qa-0.localdomain] Authentication to realm saml1 failed - Provided SAML response is not valid for realm saml/saml1 (Caused by ElasticsearchSecurityException[SAML Signature [lb617vKxZbxLezNBhweFLzHNTIMM19ML...] could not be validated against [MIIC8DCCAdigAwIBAgIQOmhwXlZ+HblG/FMnDxqT7DANBgkqhkiG9w0BAQsFADA0...]])

this is our current config for ES and Kibana

cluster.name: qa
node.name: elasticsearch-data-qa-0.localdomain
path.data: "/var/lib/elasticsearch"
path.logs: "/var/log/elasticsearch"
node.auto_attributes: true
zen.hosts_provider: ec2
endpoint: ec2.us-west-2.amazonaws.com
host_type: private_ip
groups: es-tf-qa
tag.env: qa
node_cache_time: 20s
security.transport.ssl.enabled: 'true'
security.transport.ssl.verification_mode: certificate
security.transport.ssl.keystore.path: "/etc/elasticsearch/es-cert.p12"
security.transport.ssl.truststore.path: "/etc/elasticsearch/es-cert.p12"
security.http.ssl.enabled: 'true'
security.http.ssl.keystore.path: "/etc/elasticsearch/es-cert.p12"
security.http.ssl.truststore.path: "/etc/elasticsearch/es-cert.p12"
token.enabled: true
type: saml
order: 2
idp.metadata.path: samles.xml
idp.entity_id: https://sts.windows.net/dda1dc18-8a23-4b49-a9d4-f1d617ba8e0c/
sp.entity_id: https://kibana-qa.ops.example.com:5601/
sp.acs: https://kibana-qa.ops.example.com:5601/api/security/v1/saml
sp.logout: https://kibana-qa.ops.example.com:5601/logout
attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"

attributes.groups: "urn:oid:"

attributes.principal: "nameid:persistent"

attributes.groups: "roles"

  type: native
  order: '0'

security.audit.enabled: 'true'


server.port: 5601
server.host: kibana-qa.ops.example.com
elasticsearch.url: https://es-qa.ops.example.com:9200
elasticsearch.username: elastic
elasticsearch.password: Password
server.ssl.cert: /usr/local/kibana-6.2.3/config/star_ops_example_com.bundle_crt
server.ssl.key: /usr/local/kibana-6.2.3/config/star_ops_example_com.key
logging.dest: /var/log/kibana.log
xpack.security.authProviders: [saml]
xpack.reporting.enabled: true
server.xsrf.whitelist: [/api/security/v1/saml]

(Ioannis Kakavas) #2

Hi William

The error you get says that Elasticsearch can't validate the digital signature of the SAML response. This most probably means that the SAML Response is signed with a different private key than the one that corresponds to the public key that is published in your IDPs metadata .

You can set trace log for SAML in elasticsearch using

curl -H "Content-Type: application/json" -XPUT -uelastic 'https://es-qa.ops.example.com:9200/_cluster/settings' -d'
 "transient" : {
     "logger.org.elasticsearch.xpack.security.authc.saml" : "TRACE"

This will print the whole SAML response elasticsearch receives in your logs and that response will contain the public key (certificate) that corresponds to the private key that the IDP used to sign it. You can then cross check it with the public key(certificate) that is contained in the IDP metadata in samles.xml.

In any case the trace log will allow us to get a better insight as to what the issue at hand is.

(William Hall) #3

also worth mentioning our general ES architecture all AWS EC2 instances, we have 3 ES nodes behind and AWS ELB load balancer which is es-qa.ops.example.com and the kibana instance is a separate node as well from the 3 ES nodes.

(Ioannis Kakavas) #4

Thanks for the update. It will probably help down the line with troubleshooting but for now this looks like a SAML related misconfiguration. Let's verify that the metadata you have for the IDP ( samles.xml ) is correct and the values in there are what the IDP actually uses for signing with the process I described above and we'll take it from there.

(Tim Vernum) #5

I think this is where you've gone wrong. By my recollection, Azure AD doesn't have any way to import metadata from service providers (but I could be wrong there, it's been a while since I used Azure).

You didn't by any chance use the output from saml-metadata as your samles.xml did you?
The idp.metadata.path needs to point to a file that you downloaded from Azure.

(William Hall) #6

The samles.xml is downloaded from Azure and is not the metadata file that is generated with the saml-metadata command.

I am going to use the curl cmd Ioannis provided to ensure the keys are matching

(system) #7

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