I am coming out of a very long hiatus of posting to my site to start posting content I feel is interesting. You, however, may be put to sleep by it!
Today we are going to take a look at how to test various Linux authentication methods. As an example, let’s assume we have an MTA and which validates users against a LDAP database. We are unable to authenticate to the MTA but we also are unsure where the process is breaking down.
Typically, in this setup, the MTA talks to Cyrus SASL. SASL then communicates to PAM. The relevant PAM module then talks to LDAP. Here we have four layers to test. Let’s test each starting from the bottom.
LDAP
As all of our users are stored in a LDAP database with proper credentials, we should have no issues authenticating. If errors here are encountered, then there are problems with our ldap.conf file, firewall issues, or possibly even a configuration error on the LDAP server itself. However, it’s always best to start by looking for issues with the local client.
To test LDAP, we need to know what our base DN is, what the LDAP uri is, and some authentication credentials to test with. The following command will perform the required test.
ldapwhoami -vvv -h some.ldap.host.com -p 389 -D uid=keith,ou=ldapou,dc=somewhere,dc=com -x -Z -W
ldap_initialize( ldap://some.ldap.host.com:389 )
Enter LDAP Password:
dn:id=82471855,ou=ldapou,dc=somehwere,dc=com
Result: Success (0)
As we can see, we were returned a success, so this layer is fine. A note that the -Z flag tells the ldap utility to use a TLS connection to the remote server. This is required in most cases for authentication requests or just for improved LDAP service security.
PAM
The next step is to test PAM. PAM stands for Pluggable Authentication Modules and lets a system administrator decide how a specific system service will authenticate users. This idea lets the service or application not worry about the details of authentication but rather just know whether an authentication attempt was successful or not. Because of the modular nature, this also lets the administrator swap out one authentication method for another at almost anytime.
In this case, however, we will be using PAM against an LDAP database. As I do not know low-level programming, and I was unable to find a way to test a specific PAM module directly, I took to Google and found pamtester. One note is that I had to install pam-devel and gcc-c++ for the binary to build properly. Once built, the small utility will allow testing of a specific PAM module very easily from the command line.
pamtester smtp keith authenticate
Password:
pamtester: successfully authenticated
As we can see, we can authenticate using the PAM smtp module (typically /etc/pam.d/smtp). This ensures that PAM is able to communicate over ldap to our authentication source. If any errors are displayed, you will need to debug from there. Perhaps you do not have enough packages installed, or something is configured incorrectly.
Cyrus SASL
Next up is to test SASL. SASL stands for Simple Authentication and Security Layer and lets authentication act in a more modular method. Here, a configuration file for our MTA tells SASL which authentication methods to support. In this case we will support both plain and login. plain is a password authentication method. While this can be insecure, our MTA will only allow the transmission of login data to be sent over a TLS encrypted channel. login basically just checks against system logins available and is a backup but never used if plain is setup properly.
To test the SASL configuration, use the built-in testsaslauthd command. It should be included with your sasl package.
testsaslauthd -u keith -s smtp -p CleartextPassword
0: OK "Success."
Great – our test succeeded! If any errors are shown instead, you may have issues either with your sasl configuration in general, or possibly even with PAM again. The -s smtp tells SASL to essentially use the smtp PAM module. One thing you can do to debug is to enable debug mode in saslauthd. I did this by editing /etc/sysconfig/saslauthd and adding the -d flag after -l. Restart the service then it should dump debug output to the screen. Revert the change after you’d fixed issues found.
Also, because you must type your password on the command line, be sure to go back in your history, backspace through the password, then press the down arrow. That will modify your bash history to remove the password from visibility.
SMTP
Finally, let’s test your MTA. This will make sure that everything is tied together fully – from MTA, to SASL, to PAM, then finally to LDAP. Since we’re going to be sending login credentials, we’ll test over port 587 using TLS.
openssl s_client -connect mta.hostname.somewhere.com:587 -starttls smtp
ehlo localhost
AUTH PLAIN [base64 encoded user/pass goes here]
235 2.0.0 OK Authenticated
The above test succeeded. This means we are able to authenticate successfully through all four layers. If encountering errors above, ensure that your SASL path is configured correctly. This means that if you’re running a 64bit distribution, you have your MTA built against /usr/lib64/sasl2/ and you have the appropriate configuration in that directory as well. For sendmail, that would be a properly setup Sendmail.conf file.
Conclusion
I hope to post these types of things more regularly as they help me to document items I have worked on, as well as provide assistance for others who may have similar issues in the future. Additionally, this type of post, while not for everyone, is interesting to me and is fun to write!