What is LDAP:
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection-oriented transfer services. LDAP is defined in RFC2251 “The Lightweight Directory Access Protocol (v3).
Connection between LDAP and Clearpass:
On your Clearpass server(s), before we can start authenticating clients against your Enterprise Active Directory, you will have to add the AD as an authentication source on Clearpass for the purpose of LDAP by specifying a hostname, connection port, Bind DN, Bind Password and NetBIOS Domain name.
Snapshot below:
Per the configuration above, the port used for communication between the Clearpass server and the AD has been set to 389 which is insecure, and the most common port used by customers at the same time. Perhaps, we do not fully understand why this is a risky deal so let me break this down a bit.
Whenever a client tries to connect to your enterprise network, be it a wired port or wireless SSID with 802.1x enabled, they enter their AD username and password. Now, before the Clearpass server can authenticate the username and password provided by the client, it first performs an LDAP lookup against the AD to check if the user is present or not. If the user is present, it would continue with the authentication process, otherwise, it would reject the client with alert: “user not found” on the access tracker.
For Clearpass to perform an LDAP lookup against the AD, it must first bind to the AD with the Bind DN and password configured in the AD authentication source. If this bind transaction were traced using Wireshark, it would look like this:
If you pay attention to the snippet above, you can’t help but notice that the Bind DN and password are sent as cleartext. Usually, a service account would be configured for binding so compromising the password may not be a major security concern, however, if you have your domain administrator account or any account with elevated privileges, this becomes a very serious issue. So, make sure that you use a service account only and not an administrator account. Now, we don’t have this option of using different credentials during TACACS authentications, do we?
Since TACACS involves employees logging into network devices/Clearpass using their AD credentials for administrative purpose, they will have to use their own AD credentials. Now, you may be wondering how this is different from a 802.1x authentication. Let me assure you that they are very different. While authenticating a user via 802.1x, the communication between Clearpass and the AD during password verification use a bunch of very secure protocols. Moreover, the actual password is not sent to Clearpass but only a hashed value so even if there were an intruder in between, it’s very difficult to arrive at the actual password of the client.
However, TACACS authentications from Clearpass to the AD do not use these secure protocols and to make things worse, it’s done using a simple LDAP bind to the AD. The only difference being, this time, instead of binding to the AD with the Bind DN and password, Clearpass uses the client credentials to bind to the AD and if the bind is successful, it assumes the authentication as passed.
Let’s take an example of an employee named Airowire logging into the Clearpass Policy Manager with his/her AD username and password:
User enters his username and password and hits Login:
We receive the TACACS request on Clearpass and status reads “AUTHEN_STATUS_PASS” which means the authentication was successful:
Check the TACACS service and you will observe that, under the Authentication tab, you DO NOT have an option to choose an authentication method but only a source:
The reason being, different authentication methods like CHAP, MSCHAP and MSCHAPv2 could be used between the switch/controller and Clearpass but Clearpass simply confirms the validity of the credentials by binding to the AD with the authenticating user’s username and password. To top it all off, if we have port 389 configured in the authentication source, the packet trace would look like the one below:
The user’s password is crystal clear.
To avoid this security hole, we would always recommend using AD over SSL so that the bind request is performed inside the SSL tunnel, hence protecting the credentials. Simply changing the connection security from None to AD over SSL would not get LDAPS (LDAP Secure) working. There are several prerequisites from the AD end to achieve this without which the connection would fail with the error below:
The Event Viewer on the AD would display the warning below:
The reason we see the warning above is because we do not have a certificate installed on the AD for secure LDAP services yet.
Steps on installing a certificate for LDAPS on your domain controller is documented clearly in the weblink below:
Once enabled, this is how your authentication source configuration would look:
Packet capture taken during a bind from Clearpass to the AD:
Since we have an SSL handshake preceding the bind, all traffic is encrypted.
