Shield with AD/LDAPS - javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

Elastic Stack Elasticsearch
1

Hi,

I'm at the end of my tether trying to get Shield to authenticate users against my AD server. I'm getting the error:

[2016-11-21 17:19:42,275][WARN ][shield.authc.activedirectory] [host] authentication failed for user [username]: failed to connect to any active directory servers
cause: com.unboundid.ldap.sdk.LDAPException: An error occurred while attempting to connect to server adhost.domain.com:3269:  java.io.IOException: Unable to verify an attempt to to establish a secure connection to 'adhost.domain.com:3269' because an unexpected error was encountered during validation processing:  javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

As far as I can tell this error means the AD server's certificate is untrusted. The AD server has a proper SSL certificate signed by Thawte. Connecting using ldapsearch and openssl s_client succeeds and reports a valid certificate. My keystore has both the AD host's certificate and the Thawte root and intermediate certificates installed. SSL transport comms between all the nodes in my cluster is working with a self-signed certificate and CA setup.

keytool -list -keystore keystore.ks

 elasticsearch_instance_deforestation_keystore_ca, Nov 21, 2016, trustedCertEntry, 
 Certificate fingerprint (SHA1): FE:DE:4B:18:A2:C3:18:02:89:15:D8:64:35:FA:F9:85:5F:FC:19:C4
 thawte, Nov 21, 2016, trustedCertEntry, 
 Certificate fingerprint (SHA1): 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
 adhost, Nov 21, 2016, trustedCertEntry, 
 Certificate fingerprint (SHA1): EE:57:B5:E7:80:41:E8:76:40:13:84:C8:31:81:7B:F0:98:50:81:8D
 elasticsearch_instance_deforestation_keystore_node, Nov 21, 2016, PrivateKeyEntry, 
 Certificate fingerprint (SHA1): 29:5C:7E:4C:D3:8D:2A:49:68:58:31:28:AB:07:33:27:73:69:A4:6E
 thawteinter, Nov 21, 2016, trustedCertEntry, 
 Certificate fingerprint (SHA1): 2E:A7:1C:36:7D:17:8C:84:3F:D2:1D:B4:FD:B6:30:BA:54:A2:0D:C5
 thawte-2, Nov 21, 2016, trustedCertEntry, 
 Certificate fingerprint (SHA1): AA:DB:BC:22:23:8F:C4:01:A1:27:BB:38:DD:F4:1D:DB:08:9E:F0:12

My config:
elasticsearch.yml

shield.ssl.keystore.password: password
shield.ssl.keystore.path: /etc/elasticsearch/path/to/keystore.ks
shield.transport.ssl: true
shield:
  authc:
    realms:
      esusers:
        type: esusers
        order: 0
      ldap1:
        type: active_directory
        order: 1
        url: ldaps://adhost.domain.com:3269
        domain_name: adhost.domain.com
        bind_dn: "cn=kibana,cn=Users,cd=domain,dc=com"
        bind_password: "password"
        files:
          role_mapping: "/etc/elasticsearch/deforestation/shield/role_mapping.yml"
        unmapped_groups_as_roles: false

role_mapping.yml:

admin:
  - "CN=username,OU=container,OU=othercontainer,DC=domain,DC=com"

Any ideas? I've absolutely no idea what I'm missing here.

2

I've been able to get this setup working with an external LDAP provider, so possibly this is related to the in-house AD servers running on Windows 2003 - is this likely?

3

I think it is likely. Windows Server 2003 requires additional patches from Microsoft to enable stronger ciphers than what it came with if I remember correctly. Shield restricts the ciphers and protocols to a limited set of known secure and performant ciphers. There is a tool that can be used to print out the SSL/TLS support for your AD server, ssl-enum-ciphers NSE script — Nmap Scripting Engine documentation

If you can run that and provide the output, it may point to why you cannot connect

4

Thanks - here's the results.

Starting Nmap 7.12 ( https://nmap.org ) at 2016-11-22 15:16 GMT
Nmap scan report for adhost.domain.com (10.0.2.16)
Host is up (0.0082s latency).
PORT     STATE SERVICE
3269/tcp open  globalcatLDAPssl
| ssl-enum-ciphers: 
|   SSLv3: 
|     ciphers: 
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
|       TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D
|       TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D
|       TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
|       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|   TLSv1.0: 
|     ciphers: 
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C
|       TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D
|       TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D
|       TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
|       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Ciphersuite uses MD5 for message integrity
|_  least strength: E

Nmap done: 1 IP address (1 host up) scanned in 1.72 seconds
5

Thanks for doing the check. It is what I expected. The ciphers being used aren't ones that shield supports out of the box. I think the best choice of those might be TLS_RSA_WITH_3DES_EDE_CBC_SH. You can try:

shield.ssl.ciphers: [ "TLS_RSA_WITH_AES_128_CBC_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "SSL_RSA_WITH_3DES_EDE_CBC_SHA" ]

The cipher name is different for Java; I believe it was one incorporated before TLS 1.0 was final. A small side note, this looks like a pretty old SSL configuration, which should be updated. SSLv3 should be turned off completely if possible.

6

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