Setting up password authentication with Active Directory on Debian

Central directory services such as OpenLDAP or Active Directory (AD) simplify the password management for administrator and user. With regard to Linux server, the aspect of the SSH authentication via AD is interesting. From an IT security perspective, this solution also has its advantages:

• Administrators do not have to choose and administrate different passwords for every server. You can log in to the servers with the AD password.
• The password change or deactivation of an account can be made via AD.
• Central administrated root passwords do not have to be known by all administrators anymore.

The following article shows how to configure an in Debian 7 wheezy with libpam-ldapd via mod_pam with an AD. The authentication is not only valid for SSH but also for all services that use PAM (like, for example, sudo) after successful configuration. As the libpam-ldapd packages are also available for Ubuntu, the instructions can be also used for Ubuntu.

Requirements and purpose

The following information is required for the setup:

1. The LDAP-URL of the AD server
2. The search or Base DN in which the users are located.
3. (recommended) A Bind DN, including a password, used to search the Active Directory or the base DN.
4. For TLS
   • The certificate file for the encrypted communication (since passwords are transferred between the server and AD during authentication, an encrypted communication is highly recommended).
5. The users, who want to sign up, must already exist on the server

In the following, the objectives of the instructions are listed:

• Password authentication of users via the passwords stored in AD.
• Other things like groups, home-paths or similar are not retrieved from the AD.
• The root user should be able to sign up with local passwords.

Attention: Changes to PAM module configurations may prevent you from logging in or authenticating. Always have a root terminal ready in case of an emergency!

Testing connection to AD

First, the connection between server<->AD is tested. When using LDAP with START_TLS, the communication is made via port 389:

# telnet ldap.example.com 389
Trying ...
Connected to ldap.example.com
Escape character is '^]'.

After this, an actual LDAP query is made via ldapsearch (for an encrypted connection - parameter '-ZZ' -, the certificate must be configured in the /etc/ldap.conf file.):

ldapsearch -x -H ldap://ldap.example.com -D "CN=Georg Schönberger,OU=Users,DC=example,DC=com" \
-b OU=Users,DC=example,DC=com -W -ZZ sAMAccountName=gschoenberger

Installation of libpam-ldapd

The central component on the Debian server forms the package libpam-ldapd (packages.debian.org). With this package, the daemon nslcd (packages.debian.org) is also installed that is responsible for the communication between server <-> AD.

# apt-get install libpam-ldapd
[...]
The following NEW packages will be installed:
  bind9-host geoip-database ldap-utils libbind9-80 libcap2 libdns88 libgeoip1 libisc84 libisccc80 libisccfg82
 liblwres80 libnss-ldapd libpam-ldapd libxml2 nscd nslcd sgml-base xml-core

• 
  The LDAP-Url points to the host name of the AD-server.
• 
  The search base is the part of the directory where users are located.
• 
  If the AD is only used for the password authentication, the file nsswitch.conf does not have to be configured.

Those who want to perform the package configuration once again, to adjust values, must to call up

#  dpkg-reconfigure nslcd

Configuration of nslcd

The following map and filter entries, binddn and bindpw, and TLS options must be added to the /etc/nslcd.conf file:

[...]
base ou=Users,dc=example,dc=com
map             passwd          uid     sAMAccountName
filter          passwd          (objectClass=user)

# The LDAP protocol version to use.
ldap_version 3

# The DN to bind with for normal lookups.
binddn cn=reader,dc=example,dc=com
bindpw secret

[...]

# SSL options
ssl start_tls
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/Example-com-cacert.pem
[...]

The settings of the package installation that have been configured are located, as described above, in the /etc/nslcd.conf file.

Configuration of pam_ldap

In general, the configuration of the package installation is suitable for an AD-authentication. However, users can authenticate themselves with the standard configuration per AD/LDAP as well as with local password. To disable local passwords for users other than "root", the following change must be made to the file /etc/pam.d/common-auth.conf.

Attention: After this change, only the root user can use its local password. All other users rely on Active Directory and a working connection between the server and Active Directory:

# vi /etc/pam.d/common-auth
[...]
auth    sufficient      pam_ldap.so minimum_uid=1000
auth    requisite       pam_succeed_if.so uid eq 0
auth    sufficient      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
[...]

After that, AD authentication will be sufficient for all users with a UID greater than 1000 to log in. Local passwords will no longer work!

The configuration of the AD authentication is completed after the steps described above.

Error analysis

nslcd

The daemon nslcd provides a Debus mode for analyzing the LDAP authentication:

# nslcd -d
nslcd: DEBUG: add_uri(ldap://ldap.example.com)
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,2)
[...]
nslcd: accepting connections

If the -d parameter is stated more often, the nslcd debug level increases.

The error message is a bit misleading

DEBUG: failed to bind to LDAP server ldap://ldap.example.com: Invalid credentials: 80090308:
LdapErr: DSID-0C0903C8, comment: AcceptSecurityContext error, data 52e, v23f0

that also appears when a user account does not yet exist on the server.

pam_ldap

Those who want to adjust the pam-rules in the /etc/pam.d/common-auth.conf file, encounters the following error in the log file ‘’/var/log/auth.log:

pam_succeed_if(sshd:auth): incomplete condition detected

, when the terms for pam_succeed_if.so are not correct.

References

---

Author: Georg Schönberger

Translator: Alina Ranzinger Alina has been working at Thomas-Krenn.AG since 2024. After her training as multilingual business assistant, she got her job as assistant of the Product Management and is responsible for the translation of texts and for the organisation of the department.