How to use Active Directory to authenticate linux users

Question

What are the best-practices for using Active Directory to authenticate users on linux (Debian) boxes?

The way I would like it to work would be to add AD users to a group - say linux administrators or linux webserver, and based on their group membership they would/would not be granted access to a particular server. Ideally the root account would be the only one maintained in the standard way.

My goals in doing this are as follows:

• To allow password changes in one place
• To automatically grant certain people access to the linux servers using their AD credentials
• To consolodate all of our user information into one database

Things I want to avoid are:

• anything difficult/counter-intuitive for our Active Directory administrator to manage
• locking users out if the AD servers are unreachable for some reason (ie - it needs to cache the credentials somehow)
• anything too complex or non-standard that will break the next time I upgrade the server.

Answer 1

Also see Linux clients on a Windows domains and How practical is it to authenticate a Linux server against AD?

Answer 2

There is no reason for you to use any external software on most distributions.

For Debian/Ubuntu you can do it with libnss-ldap and libpam-krb5. There are a few tricks to get it 100%. This assumes you have "unixHomeDirectory" populated for Linux users, your Linux boxes are using NTP common with your Windows systems (required by Kerberos) and that you are OK with plain text NSS lookups (not password but group membership info etc - you can also use TLS but that's more complicated to set up). You should NOT have pam_ldap as a password or auth source in PAM unless you are set up to use TLS.

/etc/ldap.conf

# LDAP Configuration for libnss-ldap and libpam-ldap.
# Permit host to continue boot process with out contacting LDAP server
bind_policy soft
# Define LDAP servers to use for queries, these must be Global Catalog servers
uri ldap://ldap.site.company.local
# Define root search location for queries
base dc=company,dc=local
#debug 1
# LDAP version, almost always going to be v3, it is quite mature
ldap_version 3
# Username used to proxy authentication. You can have this in a separate file owned by root for security OR use TLS/SSL (see man page)
# Do NOT use LDAP for authentication if you are using plain text binds, use Kerberos instead (and LDAP for authorization only). See libpam-krb5.
binddn cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
# Password for proxy acct
bindpw SooperSekeretPazzwerd
#  TCP port to perform queries on, 3268 is a Global Catalog port which will reply for all users in *.company.local
port 3268
# Search range scope (sub = all)
scope sub
# Tell the client to close TCP connctions after 30 seconds, Windows will do this on the server side anyways, this will prevent errors from showing up in the logs.
 idle_timelimit 30
# Expect queries for group membership to return DN for group members instead of usernames (lets you use MSAD group membership seamlessly)
nss_schema rfc2307bis
# Filters - User accounts must have a UID >= 2000 to be recognized in this configuration and must have a unixHomeDirectory defined.
nss_base_group dc=company,dc=local?sub?&(objectClass=group)(gidNumber=*)
nss_base_user dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
# Object Class mappings.  You may want to have the posixAccount to map to "mail" and have users login with their email addresses, i.e.  "nss_map_objectclass posixAccount mail".
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
# Attribute mappings.
nss_map_attribute uniqueMember member
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
# Attribute in LDAP to query to match the username used by PAM for authentication
pam_login_attribute sAMAccountName
# Filter for objects which are allowed to login via PAM
pam_filter objectclass=User

You should not need to edit /etc/krb5.conf assuming your Linux boxes are using DNS servers that know about AD (_msdcs zones with the appropriate SRV records are resolvable)

/etc/nsswitch.conf should have "files ldap" for users, groups, shadow.

For Red Hat using SSSD:

/etc/sssd/sssd.conf

[domain/AD]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ldap.company.local:3268/
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
ldap_default_authtok = SooperSekeretPazzwerd
ldap_schema = rfc2307bis
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
enumerate = true
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_id_use_start_tls = False
cache_credentials = True
krb5_realm = SITE.COMPANY.COM
case_sensitive = false
[sssd]
services = nss, pam
config_file_version = 2

domains = AD
[nss]
filter_users = root,named,avahi,nscd

Answer 3

The software you are looking for is called Likewise-open.

From their page:

• Joins non-Windows systems to Active Directory domains in a single step from the command line or from a GUI
• Authenticates users with a single user name and password on both Windows and non-Windows
• Enforces the same password policies for non-Windows users and Windows users
• Supports multiple forests with one-way and two-way cross forest trusts
• Caches credentials in case your domain controller goes down
• Provides single sign-on for SSH and Putty
• Next-generation authentication engine that supports Kerberos, NTLM, and SPNEGO
• No schema changes to Active Directory required

We've used it on some machines here and it seems to work well.

http://www.likewise.com/products/likewise_open/

Answer 4

I've used Likewise-Open, and found it to be buggy and not very reliable. Last year I switched to Centrify, both for Linux and for the Mac, and haven't had to mess with it much at all. I far prefer Centrify's conf file configuration to Likewise-Open's registry file configuration that requires manipulation with external tools.

http://www.centrify.com/express/free-active-directory-tools-for-linux-mac.asp

Answer 5

You should evaluate Radius. Configure the linux boxes to use pam-radius and install the MS radius plugin NPS. It will talk to AD. You can get an overview in the pdf eguide here: http://www.wikidsystems.com/learn-more/two-factor-authentication-white-papers (no reg). Just ignore the two-factor authentication bits.