1. Blog
  2. Cyberdefense
  3. Configuring and reconfiguring Palo Alto Firewall to use LDAPS instead of LDAP

Configuring and reconfiguring Palo Alto Firewall to use LDAPS instead of LDAP

Microsoft has updated  a security advisory ADV190023, “Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing”, published on 08/13/2019, the last update was on 03/10/2020

Please check the document via the following URL: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

This Microsoft document alerts about the usage of LDAP  (clear text) with Microsoft active directory, LDAP traffic is unsigned an unencrypted making it vulnerable to man-in-the-middle attacks.

This vulnerability could allow a man-in-the-middle attacker to successfully forward an authentication request to a Microsoft domain server which has not been configured to require channel binding, signing, or sealing on incoming connections.

The default configuration of the AD domain allows an unsecure LDAP connection.

This document will explain how to create an LDAP connector on a Palo Alto Networks firewall with basic settings and other improvements to secure the LDAP communication between AD server and Palo Alto Networks firewall .

In this document we will show the difference between LDAP over TLS and LDAP over SSL.

Lab scenario

Throughout this document, we will use the following  lab environment :

  • Windows 2019 server with DNS , active directory and certificate authority activated
    • Domain name : prolab.local
    • DNS entry for the Windows 2019 = pro-dc2019.prolab.local
    • Active directory user with LDAP access allowed, username = paloldap@problab.local
    • IP address 10.74.10.8
  • Palo Alto firewall VM ( IP 10.74.10.4 )

In this document you will see several LDAP connector configurations, from the basic one to more evolved configurations.

Devices configurations LDAP without SSL/TLS

On the Palo Alto firewall, we will setup an unsecure LDAP connector (LDAP without SSL/TLS).

First of all, we will configure an LDAP server profile,

Go to Device -> Servers -> LDAP

Click ADD and the following window will appear.

Give a name to this profile = Ldap-srv-profile

Add the server ( domain controller ) = pro-dc2019.prolab.local

Type = active directory

Bind DN = DC=prod , DC=local

Bind DN = paloldap@prolab.local

Leave unchecked “Require SSL/TLS secured connection

Click OK

Next step is to configure an Authentication profile,

Go to Device  Authentication profile

Click ADD

Give a name to this authentication profile = auth-LDAP

Type = LDAP

Server profile = Ldap-srv-profile

Login attribute = sAMAccountNAme

Select the “Advanced” Tab

Select all user using ADD button   ( for our test, authentication by user ou user group is not relevant )

Click OK and commit

Now we will test this authentication profile with the following CLI and with our active directory user “ paloldap” :

Test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a

shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: plaintext

Starting LDAP connection…

Succeeded to create a session with LDAP server

DN sent to LDAP server: CN=paloldap,CN=Users,DC=prolab,DC=local

User expires in days: never

Authentication succeeded for user “paloldap”

The output show that the LDAP connection is OK !

Now Let take a pcap on the management plane , using tcpdump CLI

tcpdump filter ” host LDAP-SERVER-IP” snaplen 0

during the tcpdump re run the test authentication profile

Now extract the pcap using the CLI

scp export mgmt-pcap from mgmt.pcap to username@1DEST-IP:Path

 

If you look into the pcap , you will see the clear text , you can see the username and password

This is why, the best practice is to encrypt communication between firewall and domain controller during the LDAP communication, in this case using SSL/TLS

Devices configurations LDAP with TLS ( no verify)

In this section, we will use the same Server profile and authentication profile but we will change some parameters

To  activate the TLS on communication between the firewall and Windows AD server

Go to Device -> Server Profiles -> LDAP and open the LDAP profile ( in this example profile with name “ Ldap-srv-Profile “)

Check the box “ Require SSL/TLS secured communication “

Click Ok and Commit

Now we will test again the authentication profile with the CLI :

test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: GSSAPI

Starting TLS at ldap://10.74.10.8:389

Starting TLS succeeded

Succeeded to create a session with LDAP server

DN sent to LDAP server: CN=paloldap,CN=Users,DC=prolab,DC=local

User expires in days: never

Authentication succeeded for user “paloldap”

as we can see from the CLI output, now we have a secure communication using TLS

Set the tcpdump to take a pcap using CLI :

tcpdump filter “ host LDAP-SERVER-IP” snaplen 0

Re run the TEST authentication CLI  and we will check the PCAP for this traffic

As we can see , only two ldap packet , only requesting TLS

Note : with LDAP over TLS , the client/server start with non-encrypted communication as we can see on the pcap  on line 4 and 5 , only after that start the encrypted communication

After that we can see the TLS transactions ( hello packet )  and the rest of the communication is encrypted , impossible to see anything ( no password or username )

Note: the TCP port is still 389, the port used is not important for TLS

The firewall receives the server certificate but does not try do verify him because we instruct the firewall to have this behavior

Devices configurations LDAP with TLS (verify)

we will enforce again the security instructing the firewall to check the server certificate

We will edit the config of the Ldap server profile

Go again to Device -> Server Profile -> LDAP and edit the profile used in this example “ Ldap-srv-profile”

Check the box “ Verify Server Certificate for SSL sessions”

And commit

Now we will  run  again the test of the authentication profile

test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: GSSAPI

Starting TLS at ldap://10.74.10.8:389

Starting TLS succeeded

Common name presented by LDAP server: /CN=PRO-DC2019.prolab.local

Server certificate: ‘/CN=PRO-DC2019.prolab.local’ is invalid for server ‘pro-dc2019.prolab.local’: unable to get local issuer certificate

Failed to create a session with LDAP server

Authentication failed against LDAP server at pro-dc2019.prolab.local:389 for user “paloldap”

Authentication failed for user “paloldap”

The process fail because as we can see “Server certificate: ‘/CN=PRO-DC2019.prolab.local’ is invalid for server ‘pro-dc2019.prolab.local’: unable to get local issuer certificate”

The  firewall is unable to verify the certificate because we do not have on the firewall the Trusted certificate authority that signed the AD certificate ( in this example CA and AD are running on the same server )

We will need to export the CA certificate from the windows CA server, access to CA via URL using the user “paloldap”:

http://CA-IP/certsrv

Click on “ Download Ca Certificate “

Click on “ Download Ca Certificate “ and save the certificate file

Now we will need to import this certificate into the firewall , but before that we need to format the certificate into a Base 64 format

Follow the procedure

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGSCA0

 

Now we have the CA certificate into the correct format , we will import into the firewall

Go to Device -> Certificate management -> Certificate and click Import

Give a name for this certificate and select the file ( certificate CA )

Click OK

run again the Test on authentication profile

test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: GSSAPI

Starting TLS at ldap://10.74.10.8:389

Starting TLS succeeded

Common name presented by LDAP server: /CN=PRO-DC2019.prolab.local

Succeeded to create a session with LDAP server

DN sent to LDAP server: CN=paloldap,CN=Users,DC=prolab,DC=local

User expires in days: never

Authentication succeeded for user “paloldap”

And now  we have TLS communication and the firewall was able to verify the server certificate

Let enforce more the security, forcing the AD server to only accept LDAPS ( LDAP TLS )

Follow the Microsoft guide

https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server

 

As mentioned in the document, we can test using the ldp.exe , here the result that shows the connection denied using a simple bind

create a LDAP server profile with the box “ Require SSL/TLS secured connection”. Unchecked , in this example “ NO-Ldap-srv-profile-1″, in this way, we will check if the server if not any more accepting Ldap connection without TLS

Create an authentication profile that will use the above recently created server profile, in this example “ auth-NoLdapS “

Click OK and commit

Run Test authentication profile from the firewall

test authentication authentication-profile auth-NoLdapS username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication requests…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: plaintext

Starting LDAP connection…

Failed to create a session with LDAP server

Authentication failed against LDAP server at pro-dc2019.prolab.local:389 for user “paloldap”

Authentication failed for user “paloldap”

 

As we can see the firewall was not able to create the LDAP connection because the server requires TLS usage.

New test using the authentication profile that use TLS/SSL , in this example “ auth-LDAP “

 

test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

 

Target vsys is not specified, user “paloldap” is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: GSSAPI

Starting TLS at ldap://10.74.10.8:389

Starting TLS succeeded

Common name presented by LDAP server: /CN=PRO-DC2019.prolab.local

Succeeded to create a session with LDAP server

DN sent to LDAP server: CN=paloldap,CN=Users,DC=prolab,DC=local

User expires in days: never

Authentication succeeded for user “paloldap”

 

Using SSL/TLS on the authentication profile, the firewall was able to connect using TLS ( TCP port  389 ) . TLS accept connections on other port than 389

Devices configurations LDAP with SSL (verify)

 

Now let change on the Server Profile  that use LDAPS, in this example “ Ldap-srv-profile “ , the server port to 636 ( SSL )

 

Go to Device -> Server Profiles -> LDAP and open the profile “ Ldap-srv-profile “

Look at Server List area , and change the port from 389 to 636

Click Ok and commit

Let run again a Test authentication CLI

 

Test authentication authentication-profile auth-LDAP username paloldap password

Enter password :

Target vsys is not specified, user “paloldap” is assumed to be configured with a

shared auth profile.

Do allow list check before sending out authentication request…

name “paloldap” is in group “all”

Authentication to LDAP server at pro-dc2019.prolab.local for user “paloldap”

Egress: 10.74.10.4

Type of authentication: GSSAPI

Starting LDAPS connection…

Common name presented by LDAP server: /CN=PRO-DC2019.prolab.local

Succeeded to create a session with LDAP server

DN sent to LDAP server: CN=paloldap,CN=Users,DC=prolab,DC=local

User expires in days: never

Authentication succeeded for user “paloldap”

 

As we can see , the message now is “ starting LDAPS connection” instead of “ Starting TLS” that appeared with setting port TCP 389

Looking into the pcap

We cannot see any LDAP transaction, the process starts with encrypted communication and only after that start the LDAP processes

 

 

 

 

 

Share the post