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.
Bind and Search
This is a capture of the network traffic when running the command
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
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
/etc/sssd/sssd_LDAP.conf file to use
ldaps as the protocol
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.
This is the default setup used to create these captures. The examples above may use different configurations where noted.
- Operating System: Windows Server 2008 R2
- DNS: ad1.cloudshark-a.example.com
- IP: 192.168.2.131
- Operating System: CentOS Linux release 7.2.1511
- IP: 192.168.2.133
- SSSD Version: 1.14.0
[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!
- IP: 192.168.2.1