Troubleshooting Active Directory and SSSD With Packet Captures

When setting up External Authentication with customers we typically use SSSD to configure a Linux to use a separate server to authenticate users and learn their group memberships. We’ve been learning more about configuring SSSD and what effects the different configurations have on how this is performed. Here is a set of different scenarios and packet captures to share what we learned.

This is a capture of the network traffic when running the command id to look up a user’s ID. Take note of the bind request performed and how the value of ldap_default_authtok is sent over the network.

SSH Login to SSSD Client

In this capture the configuration was modified to disable TLS which should never be done and is not supported in SSSD.

In the ladder diagram view you can see the SSH Client logging in and the SSSD client authenticating.

Take a look at the LDAP traffic to see why you should never disable TLS!

StartTLS Without Certificate

Since we don’t want users’ passwords to be transmitted in the clear let’s remove the line that disables TLS and try to login over SSH again.

In this capture we can see that the client does try to perform the authentication over TLS but the server is responding with the following error message:

errorMessage: 00000000: LdapErr: DSID-0C090E17, comment: Error initializing SSL/TLS

This error message gets sent by the Active Directory server when there is no TLS certificate available for it to use.

StartTLS With Untrusted Certificate

After configuring a certificate for the server following these instructions let’s try and login again.

The server now responds indicating that it will start a TLS connection to perform the authentication. But now our SSSD client is rejecting the TLS connection complaining about an Unknown CA!

This is good because we don’t want our SSSD client blindly trusting an machine on the network claiming to be our Active Directory server. We’ll need to copy the public key from our AD server and configure the SSSD client to trust this certificate as the server we want to use.

StartTLS With Trusted Certificate

Once we have a copy of the Active Directory server’s public key we can copy it to our SSSD client and tell it to trust this by running the following commands:

update-ca-trust force-enable
cp <FILENAME OF CERTIFICATE> /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
service sssd restart

Now the user can login over SSH without their password being sent in a plaintext packet. TLS can also be used for the entire connection which we will configure in the next section.

SSH Login with LDAPS

Update the /etc/sssd/sssd_LDAP.conf file to use ldaps as the protocol instead of ldap. In our example we would change this to:

ldap_uri = ldaps://ad1.cloudshark-a.example.com

Note that the filter expression ldap will no longer show any of our LDAP packets. That’s because now they are being transmitted over TCP using port 636 and they are using TLS! Now any eavesdroppers won’t be able to see any of the LDAP traffic we are sending back and forth.

Setup

This is the default setup used to create these captures. The examples above may use different configurations where noted.

Active Directory

  • Operating System: Windows Server 2008 R2
  • DNS: ad1.cloudshark-a.example.com
  • IP: 192.168.2.131

SSSD Client

  • Operating System: CentOS Linux release 7.2.1511
  • IP: 192.168.2.133 SSSD
  • Version: 1.14.0

/etc/sssd/sssd.conf:

[sssd]
domains = LDAP
services = nss, pam
config_file_version = 2
[nss]
[pam]
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ad1.cloudshark-a.example.com
ldap_search_base = cn=Users,dc=cloudshark-a,dc=example,dc=com
ldap_schema = ad
ldap_id_mapping = true
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=cloudshark-a,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = cloudshark123!

SSH Client

  • IP: 192.168.2.1