AD auth doesn't work after upgrading from 6.7 to 7.0

Elastic Stack Elasticsearch
1

Hi,

This is the xpack config that I had in 6.7, which worked perfectly fine for AD authentication:

xpack:
  security:
    enabled: true
    transport:
      ssl:
        enabled: true
    authc:
      realms:
        active_directory:
          type: active_directory
          order: 0
          domain_name: foo.bar.local
          url: ldaps://ad1.foo.bar.local:636, ldaps://ad2.foo.bar.local:636, ldaps://ad3.foo.bar.local:636
          ssl:
            certificate_authorities: ["/home/user/elasticsearch-6.7.1/config/cacert.pem"]
          load_balance:
            type: "failover"

For 7.0, I had to migrate to the new realms settings format as per Breaking Changes in 7.0 and I got:

xpack:
  security:
    enabled: true
    transport:
      ssl:
        enabled: true
    authc:
      realms:
        active_directory.active_directory:
          order: 0
          domain_name: foo.bar.local
          url: ldaps://ad1.foo.bar.local:636, ldaps://ad2.foo.bar.local:636, ldaps://ad3.foo.bar.local:636
          ssl:
            certificate_authorities: ["/home/user/elasticsearch-7.0.0/config/cacert.pem"]
          load_balance:
            type: "failover"

Now, if I try to authenticate, I'm getting the following error:

[WARN ][o.e.x.s.a.AuthenticationService] [server.name] Authentication to realm active_directory failed - authenticate failed (Caused by LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server ad3.foo.bar.local:636: IOException(LDAPException(resultCode=91 (connect error), errorMessage='Unable to verify an attempt to to establish a secure connection to 'ad3.foo.bar.local:636' because an unexpected error was encountered during validation processing: SSLPeerUnverifiedException(peer not authenticated), ldapSDKVersion=4.0.8, revision=28812'))'))

What am I missing? I've found a few articles with similar error, but they seem to be related either to Shield which I don't have or some Java exception which I cannot really understand in order to properly troubleshoot. Help out, please.

Best regards,
Albert.

2

Hi Albert,

Can you please verify that the CA certificate that you have referenced in

is indeed the CA certificate that has signed the certificates that your all AD Domain Controllers use for LDAP over TLS ?

Another thing that was changed in 7.0.0 is that we no longer have default tls settings so it might be the case that you have some

xpack.ssl.*

settings in your elasticsearch.yml file that would apply to the LDAP ssl settings ( if not overriden in the LDAP realm ssl settings explicitly ) in 6.7.0 but this is no longer the case in 7,0.0

3

Hi Ioannis,

The cert appears to be exactly the same as the one I used in 6.7.1. If I launch the 6.7.1 right now, it works perfectly fine with the cert, so this makes me scratch my head about how the cert itself can be an issue, to be honest. However I'm not really good at this SSL/TLS wizardry.

$ md5sum elasticsearch-6.7.1/config/cacert.pem
306f137c97bc085234d75deda7103e50  elasticsearch-6.7.1/config/cacert.pem
$ md5sum elasticsearch-7.0.0/config/cacert.pem
306f137c97bc085234d75deda7103e50  elasticsearch-7.0.0/config/cacert.pem

As you can see, the certs are identical between 6.7 and 7.0.

Maybe file permissions need to be different in 7.0?

$ ls -al elasticsearch-6.7.1/config/cacert.pem
-rw-rw-r-- 1 user user 2687 Apr  8 15:00 elasticsearch-6.7.1/config/cacert.pem
$ ls -al elasticsearch-7.0.0/config/cacert.pem
-rw-rw-r-- 1 user user 2687 Apr 25 11:26 elasticsearch-7.0.0/config/cacert.pem

Additionally, since comparison between certs in 6.7 and 7.0 isn't what you asked for, if I run diff between current cert stored on AD and the cacert.pem that I already have, it returns no differences:

$ diff <(openssl s_client -connect foo.bar.local:636 2>/dev/null </dev/null |  sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p') <(cat elasticsearch-7.0.0/config/cacert.pem)
$

As for the xpack.ssl.* setting, I don't have it set. The only xpack related settings that I have are in the topic starter.

Best regards,
Albert.

4

Thanks for the verification Albert, it does look like there shouldn't be an issue with the CA certificate.

Another thing we did change in 7.0 is the deprecation of TLSv1.0 as a default supported version and the introduction of TLSv1.3 in the list of the default supported versions so I'm wondering if your AD Controller dislikes TLSv1.3.

Can you please add

supported_protocols: TLSv1.2, TLSv1.1

under ssl: in your config and see if this fixes your issue?

5

Which section should it be under? xpack.security.transport.ssl or xpack.security.authc.realms.active_directory.active_directory.ssl? I've just tried both to no avail.

Under xpack.security.authc.realms.active_directory.active_directory.ssl:

xpack:
  security:
    enabled: true
    transport:
      ssl:
        enabled: true
    authc:
      realms:
        active_directory.active_directory:
          order: 0
          domain_name: foo.bar.local
          url: ldaps://ad1.foo.bar.local:636, ldaps://ad2.foo.bar.local:636, ldaps://ad3.foo.bar.local:636
          ssl:
            certificate_authorities: ["/home/user/elasticsearch-7.0.0/config/cacert.pem"]
            supported_protocols: TLSv1.2, TLSv1.1
          load_balance:
            type: "failover"

Under xpack.security.transport.ssl:

xpack:
  security:
    enabled: true
    transport:
      ssl:
        enabled: true
        supported_protocols: TLSv1.2, TLSv1.1
    authc:
      realms:
        active_directory.active_directory:
          order: 0
          domain_name: foo.bar.local
          url: ldaps://ad1.foo.bar.local:636, ldaps://ad2.foo.bar.local:636, ldaps://ad3.foo.bar.local:636
          ssl:
            certificate_authorities: ["/home/user/elasticsearch-7.0.0/config/cacert.pem"]
          load_balance:
            type: "failover"

The error message was exactly the same in both cases.

Best regards,
Albert.

6

It should be under xpack.security.authc.realms.active_directory.active_directory.ssl: and my suggestion was actually wrong, this is a list setting so the correct format for it should be

supported_protocols: ["TLSv1.2", "TLSv1.1"]

sorry for that.

Can you give this a try please ?

1 Like
7

OK, it actually was TLSv1 (that's right, just v1) that I had to add to the list against xpack.security.authc.realms.active_directory.active_directory.ssl.supported_protocols. This is the xpack config that work for me now:

xpack:
  security:
    enabled: true
    transport:
      ssl:
        enabled: true
    authc:
      realms:
        active_directory.active_directory:
          order: 0
          domain_name: foo.bar.local
          url: ldaps://ad1.foo.bar.local:636, ldaps://ad2.foo.bar.local:636, ldaps://ad3.foo.bar.local:636
          ssl:
            certificate_authorities: ["/home/user/elasticsearch-7.0.0/config/cacert.pem"]
            supported_protocols: ["TLSv1.2", "TLSv1.1", "TLSv1"]
          load_balance:
            type: "failover"

I'll talk to the AD team about this, but it'll certainly take a while before they add support of higher TLS versions. For now, I'll just have to live with TLSv1.

If I can make a suggestion, maybe the TLS issue for external authentication is something that's worth mentioning in Configuring AD realm in 7.0? There's a bit on TLSv1.0 in TLS version 1.0 is disabled in "Breaking changes 7.0", but because of the example in there (http), it doesn't emphasise that the change affects everything that has anything to do TLSv1.0, therefore perhaps it would be benefitial to have something about it in Configuring AD realm in 7.0.

Thanks you!

Best regards,
Albert.

8

Yes, this is the identifier for version 1.0 ( JDK Providers Documentation ).

Thanks for the suggestion Albert, I'll see what we can do to make this clearer. As a data point, would you be able to share what version is your Windows Server ?

9

Sure thing. The AD controller is running on Windows Server 2012 R2.

Best regards,
Albert.

10

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