Authentication Service TLS (Windows Active Directory)

[Linedo (Linden)]

I am running Graylog 5.1 on Ubuntu 22.04. I have a single node installation behind an nginx proxy.

I have an “Authentication Service” configured to our Windows Active Directory to allow domain users to login. This works fine when I have no encryption (LDAP - port 389), however when I enable the TLS option (LDAPS - port 636) I receive the following error:

Couldn’t establish connection to xxx.xxx.xxx.xxx:636

• An error occurred while attempting to connect to server xxx.xxx.xxx.xxx:636: IOException(LDAPException(resultCode=91 (connect error), errorMessage=‘An error occurred while attempting to establish a connection to server /xxx.xxx.xxx.xxx:636: SocketException(Connection reset by peer), ldapSDKVersion=5.1.1, revision=580fabe31b0752099ccd9a835fe7da96e8251e28’))*

I have both SSL and TLS certificates on my Graylog server, however when I enable TLS in server.conf I am no longer able to connect to the front end (I receive a gateway timeout), I am pointing to the correct .pem certificate and pkcs8 key (2048) in my server.conf file.

I am not really sure what this error means, or how I can resolve this issue. Any help would be much appreciated.

Thanks.

[faen]

Could it be that your Graylog server cannot connect to your domain controller on TCP:636 because of a network/firewall restriction?

[Linedo (Linden)]

Hi @faen,

Thanks for the response, I added a rule to allow port 636 between my Graylog server to Windows AD on both routers on this path, however it is possible that it was either misconfigured or a local firewall is at fault.

I will install nmap on my Graylog server and run a TCP scan on port 636 to my AD server.

[Linedo (Linden)]

It does not appear to be a firewalling issue:

[drewmiranda-gl (Drew Miranda)]

Can you provide some additional information?

Do you have any corresponding errors in graylog’s server.log?

Are you using “verify certificates” checkbox or not?

Is the public certificate of the domain controller imported into the java key store (JKS) that graylog uses to validate certs?

From the graylog server what output do you get when you run these commands? (you can redact as much as you need to when posting the results)

Test connect with openssl:

openssl s_client -connect <ldap ip or hostname>:636

the last bit of the output is the important part. Here is an example of output when i query my lab domain controller

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 853C00006584A06E13D9EA48D7408C93E28ADF04C06432A1FA88610304D64F40
    Session-ID-ctx: 
    Master-Key: 0BB929DEA930AC82AB261894D522E44EAED821085B17CA1321E367E4E8D05239F632766C0A61411EC6D7130090F4773D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1704994826
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes

Enumerate TLS Ciphers using nmap (note you’ll need to have nmap installed)

nmap -Pn --script ssl-enum-ciphers -p 636 <ldap ip or hostname>

Example output:

PORT    STATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

For reference i’m testing with a vanilla (no changes or customizations) Server 2019 domain controller.

Thanks!