Authentication from Active Directory DC Server and a separate AD Certificate Service Server?

I am contemplating turning on TLS within the Authentication settings using Active Directory… I have looking over this video about Graylog - LDAP / Active Directory (SSL) - https://www.youtube.com/watch?v=u5id42rHR_s

1. Describe your incident:

I have 2 servers that are already running the “Active Directory Certificate Services” but they are not Domain Controllers (DC’s). They are just used for self-signed certificates.

Is it possible to have an Active Directory DC and a separate “Active Directory Certificate Services” Server to be able to use the Authentication, Active directory with TLS? If so, how may can this be setup?..

Or…

Does this feature have to be combined on an Active Directory DC System? Will turning “on” this role on a AD DC affect anything for the normal users and active directory joined windows systems?

2. Describe your environment:

  • OS Information:
    Debian 12, Bookworm

  • Package Version:
    mongodb-org/bookworm/mongodb-org/7.0,now 7.0.14
    opensearch/stable,now 2.17.0
    graylog-server/stable,now 6.0.6-1

  • Service logs, configurations, and environment variables:

3. What steps have you already taken to try and solve the problem?
Spent time looking over Active Directory TLS related post here and googling around for anything related to this. I have not found anything that provides a clear enough answer.

I have done the Active Directory, none TLS option test which all are passing fine.

4. How can the community help?
Giving some feed back regarding this…

In terms of how Graylog connects to LDAP using TLS, there is not anything special or unique about the certificates. You more or less configure graylog using the appropriate LDAP config info and thats it. You don’t even strictly need graylog to validate the cert served from LDAP, however, if you do, you will need to configure Graylog to trust cert that signed the certificate that LDAP is using. This blog has an explanation of how to do this, specifically the section about “Java Key Store”.

To specifically answer your question, “Active Directory Certificate Services” can live on any server and does not need to be served from your Domain Controllers. This is how I did it at my previous job. Graylog doesn’t really know/care about how the certs were generated as long as they are valid (e.g. valid date, valid hostname, cert is trusted).

Hope that helps.

Hi there and thank you for the response back… I have already setup graylog to use TLS … HTTPS. The certs were purchased from a CA, not self-signed… The purchased cert also are not on or part of the 2 systems that have the “Active Directory Certificate Services” Role turned on.

I also just found out that the Role was appears like it was never configured. It looks like the person that setup it up only took it far enough to generate pki/self-signed certs. So… “Configuration required for Active Directory Certificate Services at XYZ” was never done. :confused: As it shows in the/this video:

So I fell like I am still left with wondering the same questions…

The link you posted is part of what I used to turn on/setup TLS/HTTPS. It has no mention about Active Directory TLS and Graylog… That I am aware of…

Are you able to configure Active Directory as an authentication service in Graylog? Are you receiving any errors or running into any issues?

Are you able to configure Active Directory as an authentication service in Graylog?

Yes I am able to configure “Active Directory” with the “None” (Port 389) option. I am able to click the “Test Server Connection” button and I receive an “Successfully connected to Server-IP-Address:389”. I can go into the next setup section “Next: User Synchronization”. Fill out the needed information and use the “Test User Login” button with account that match the “Seach DN” and “Search Pattern” I setup. I receive an “Successfully logged in into Server-UP-Address:389”.

Are you receiving any errors or running into any issues?

If I am using the “Server-Address:389” and “none” for the AD setup… I do not receive any errors.

If I use the “Server-Address:636” and “TLS” for the AD setup… I receive the following when I click the “Test Server Connection” button.

Couldn't establish connection to Server-IP-Address:636

    An error occurred while attempting to connect to server Server-IP-Address:636: IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server /Server-IP-Address:636: SSLHandshakeException(PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target), ldapSDKVersion=7.0.0, revision=323ff4fd3d622b96522298f300abc6915d0c209b'))

Edited to correct some of the formatting of the text…

Understood. This means that Graylog doesn’t trust the certificate.

You will need to save the certificate that signed the certificate your active directory server is using.

  1. Use openssl to read the certificate: openssl s_client -connect 192.168.0.99:636
    • NOTE: if you run this command from windows, you need to install the openssl binaries for windows. If you run this on a linux server, openssl is included out of the box.
  2. Save the certificate text to a text file named cert.crt, the output should look like this
  3. On windows, you can open this .crt file with the certificate viewer and see the certificate chain
  4. Select each certificate in the chain and click on ‘View certificate’, check go to the details tab and click ‘copy to file’.
    image
    image
  5. Follow the steps here for the ‘Java Key Store’, ’ Import Certs’, ’ Configure Graylog’ sections. This is required to configure graylog to trust the certificate(s) that sign your active directory ldap cert.

Hope that helps

Interesting… I now have more that I need to understand…

Do I need to pull both the public and the private…? Can these both be pulled from the AD server that I am using within graylog?

Just the public cert. The idea is that Graylog by default does not trust any certificates. When graylog (by way of connecting to LDAP via TLS using TCP 636) attempts to connect to a device serving TLS, it won’t understand how to trust the certificate being served.

Using the steps above, we can tell graylog specifically how to trust the certificate. This is because these certificates work on chain of trust. For example, windows, by default, has what is called Root Certificates. ALL publicly issues certificates are signed by these root certificates. If your computer (in this example, windows) trusts the root, it will trust trust any certificate the trusted certificates have also signed.

Check out Public key infrastructure - Wikipedia and Public-key cryptography - Wikipedia to learn more.

I am trying my best to to follow that page… I didn’t used this page to setup TLS… HTTPS… i rebuilt the graylog vm 3 times when trying to follow it…

I built it a 4th time using this video and it worked out of the gate the on the first try. - https://www.youtube.com/watch?v=QRUEgYzLdD4

I am struggling to covert “.cer” to “.pem”.?. That guide states It needs to be in pem format.

I have tried to “copy to file” with both "DER encodded Binary X.509 (.cer) and "Base-64 encoded X.509 (.cer).

So far every solution i have came across for converting it errors out.

The TLS steps aren’t important for our purposes, just the sections that explain how to import the cert(s) into a Java Key Store (JKS) file so graylog can trust the certs.

PEM encoding means you can read the text of the certificate and it it starts with
-----BEGIN CERTIFICATE-----
and ends with
-----END CERTIFICATE-----

Using the steps in my previous post using openssl to obtain your cert bound to your Active Directory domain controller will output the cert in this file. When you follow the steps in windows to view the cert chain and save as a file you can select a base64 option. The file name or file extension is not important (for example it may save as .crt). The important part is that the certificate starts with
-----BEGIN CERTIFICATE-----
and ends with
-----END CERTIFICATE-----

I definintely recommend reading up more on Public Key Infrastructure and even doing some testing in a lab scenario where you generate self-signed certs and understand the process of Root Certificate Authorities (CAs), Certificate Signing Requests (CSR), and generating certs signed by a CA.

Awesome. Looks like it is working. I got a…
" Successfully connected to server-ip-address:636"

I did have to uncheck the “Verify Certificates” option. but with “TLS” selected it passed both the tests.
" Successfully connected to server-ip-address:636"
" Successfully logged in into [10.1.1.33:636]"

Once you told me that it would take the “.cer” file format the import part was easy.

Thank you for your time.

1 Like