StuartEllis.eu

Adding a Linux Server to an Active Directory Domain

  1. Introduction
  2. Prerequisites
  3. Documentation
  4. Configure Kerberos
  5. Configure Samba
  6. Add the System to Active Directory
  7. Configure Winbind
  8. Disable NSCD
  9. Configure Services To Use Winbind
  10. Enable the Services
  11. Tip: Username Formats

These notes were written for a Fedora system, which is closely related to Red Hat Enterprise Linux and CentOS, but the software described is available for every Open Source operating system.

Privileged Commands: The prefix # indicates commands that require root privileges.

Introduction

Integrating a Linux server with an Active Directory consists of several steps, and is not difficult if one simply follows the instructions for each step. The main difficulty is in understanding what each system does.

PAM is a flexible authentication system that is now incorporated into most UNIX variants. When any PAM-aware service is presented with a username and password, then these are simply passed on to PAM. PAM can be configured to consult multiple information sources and perform various other actions as part of the login process.

Kerberos is a technical standard that enables secure communication between all users and systems that are part of a single Kerberos realm. Each Kerberos KDC service for a realm has a copy of the database that holds user and system records. Several providers offer server software that implements Kerberos, and Microsoft Active Directory is one such product.

There are several similarities between Kerberos and LANMAN, the authentication technology used by Windows NT 4.0. A Kerberos realm equates to an NT domain, and KDC servers hold copies of the accounts database just as LANMAN domain controllers did. With Windows 2000 and above a Windows (Active Directory) domain actually is a Kerberos realm, the domain controllers are Kerberos Key Distribution Centers for that realm, and the client systems use the Kerberos protocol to authenticate users with the domain controller servers. To ease the transition, Microsoft continue to use LANMAN terminology, and Active Directory domain controllers act as both LANMAN domain controllers, and KDCs.

LANMAN clients automatically located a domain controller by querying the network WINS service. Kerberos KDCs have special SRV records in DNS, and the clients query DNS to find an available server to authenticate with. Active Directory automatically injects SRV records for the domain controllers into Microsoft DNS zones.

Samba is a suite of software for UNIX-like systems that handles file sharing, printer sharing and logons in a Windows-compatible way. The main Samba service provides the functions of Windows File and Printer sharing (technically known as SMB or CIFS), and may also act as a LANMAN domain controller.

The Samba suite provides a separate Winbind service that supports both PAM and the main Samba service. When a user attempts to login to a server running Winbind then PAM or the Samba service may call it to verify the account with a remote domain controller. Winbind works with both NT 4.0 domains and Active Directory domains.

UNIX-like systems store information about users differently to Windows, and this means that even if a user is listed in Active Directory then Samba must have some information about the user account in it’s own database. Equally, having a user account on a UNIX-like system does not allow the user to access files and printers through the Samba service unless the user has a listing in the Samba user database.

Prerequisites

Samba 3 is needed for a UNIX-like system to join Active Directory as a full member server. This version is now included with every current Open Source operating system.

On a Fedora or Red Hat system, install the following packages:

Samba:

Kerberos:

Before starting this process, ensure that the Linux system is networking correctly, and has a valid entry in DNS. Also ensure that you know:

If your network still uses WINS then you also need to know the IP address of the WINS server (it’s probably the DC that is configured with the PDC emulator role).

Documentation

Samba includes a very complete set of documentation. The relevant sections are in the Samba HOWTO:

For PAM the documentation is here:

This walk-through was also very useful for me:

http://www.flatmtn.com/computer/Linux-EmailServer.html

Configure Kerberos

Samba 3 uses the Kerberos protocol to authenticate with Active Directory, so you need to configure the Linux system to act as a Kerberos client for the realm (domain) for this facility to work. Fedora supplies the MIT Kerberos software. If the krb5-workstation package has been installed then the necessary client programs will be in /usr/kerberos/bin/.

The name of the Active Directory Kerberos realm is the same as it’s domain name. Usernames are also the same, but are suffixed with the name of the realm that they are part of. In standard Kerberos all names are in upper case, e.g.

MROBERTS@ADEXAMPLE.LOCAL

Active Directory domain controllers are registered in DNS, so you do not need to manually specify the servers. Instead edit /etc/krb5.conf to enable DNS lookups. The libdefaults section should read:

[libdefaults]
ticket_lifetime = 24000
default_realm = ADEXAMPLE.LOCAL
dns_lookup_realm = yes
dns_lookup_kdc = yes

Comment out the realms and domain_realms sections.

To test that Kerberos is configured correctly, use the kinit command:

kinit MROBERTS@ADEXAMPLE.LOCAL

Configure Samba

The supplied Samba configuration file is very long, and most of the settings are not necessary for AD membership. Make a copy of the file and create a blank one:

# cp /etc/samba/smb.conf /samba/smb.conf.original

An example smb.conf for an Active Directory member server:

[global]

socket options = TCP_NODELAY
SO_RCVBUF=8192
SO_SNDBUF=8192

workgroup = ADEXAMPLE
server string = Samba Server

local master = no
domain master = no
preferred master = no
wins support = no
wins server = 10.0.1.2
dns proxy = no

realm = ADEXAMPLE.LOCAL
security = ADS

password server = ms-dc-01.adexample.local

winbind separator = +
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

template homedir = /home/%U
template shell = /bin/nologin

log file = /var/log/samba/%m.log
max log size = 5000

printcap name = /etc/printcap
load printers = no

If you want the main Samba service to provide access to home directories or printers, add these stanzas. For printer sharing you should also change load printers = no to read load printers = yes.

[homes]
comment = Home Directories
browseable = no
writable = yes

[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = no
writable = no
printable = yes

Once you have edited the smb.conf file, run the testparm utility to check that the Samba configuration is valid:

# testparm

Add the System to Active Directory

First you must login to the Active Directory with kinit, since no other method has been setup yet:

# kinit USER@ADEXAMPLE.LOCAL

You may then use the net utility to create a machine account for the new member server:

# net ads join "Example-OU\Example-OU"

Configure Winbind

Once Samba is configured you must set the nsswitch system to use Winbind to verify accounts that do not exist on the local system. In the file /etc/nsswitch.conf amend the lines:

passwd:     files
shadow:     files
group:      files

To read:

passwd:     files winbind
shadow:     files
group:      files winbind

Winbind has better performance when run in double daemon mode. In the file /etc/sysconfig/samba amend the line:

WINBINDOPTIONS=""

To read:

WINBINDOPTIONS="-B"

Disable NSCD

The service NSCD (Name Service Caching Daemon) seriously interferes with Winbind authentication and must be completely disabled before enabling Winbind.

To do this, edit /etc/nscd.conf. Edit these three lines:

enable-cache            passwd          yes
enable-cache            group           yes
enable-cache            hosts           yes

They should read:

enable-cache            passwd          no
enable-cache            group           no
enable-cache            hosts           no

This disables all NSCD caching.

To make the new configuration active, restart the network service:

# /sbin/service network restart

Configure Services To Use Winbind

The PAM configuration for Samba itself does not need to be modified for Winbind. By default the main Samba service ignores PAM, and will either use Winbind or an internal account database to authenticate users.

Most other modern services on Linux use the PAM system for authentication. If you want to use Winbind with every service on the system that supports PAM, then modify /etc/pam.d/system-auth. If you only want specific services to use Winbind for authentication then you need to modify individual configuration files in /etc/pam.d/. Several services have their own file, but a number of services use the login facility, controlled by /etc/pam.d/login.

Add two lines to the appropriate PAM file:

auth sufficient /lib/security/pam_winbind.so

and

account sufficient /lib/security/pam_winbind.so

Amend all other auth and account types from required to sufficient.

Note that PAM reads the file sequentially, so where there are multiple sufficient sources the first successful one is used. Think carefully about the sequence in which you wish the system to check authentication services. A laptop may be off the main network more often than it is on it, and will be unable to access internal authentication services whilst it is disconnected.

If you edit the PAM configuration file for a service, you must restart that service for the changes to take effect.

Default /etc/pam.d./sshd settings:

auth      required     pam_stack.so service=system-auth
auth      required     pam_nologin.so
account   required     pam_stack.so service=system-auth
password  required     pam_stack.so service=system-auth
session   required     pam_stack.so service=system-auth
session   required     pam_limits.so
session   optional     pam_console.so

Example /etc/pam.d/sshd using Winbind:

auth      required     pam_nologin.so
auth      sufficient   pam_stack.so service=system-auth
auth      sufficient   pam_winbind.so

account    sufficient  pam_stack.so service=system-auth
account    sufficient  pam_winbind.so

password  required     pam_stack.so service=system-auth

session    sufficient  pam_stack.so service=system-auth
session   required     pam_limits.so
session   optional     pam_console.so

PAM does not guarantee that the user will have a home directory available, and without one the login process will fail. If you want to automatically use a home directory stored on another server, investigate automount.

If you would like to automatically create local home directories for new users as they login, then you could use this line in the PAM configuration:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

If at all possible, create any local home directories with another means, before the user concerned can sign in. The easiest way may be to add the facility to your account creation scripts. By default SSH (and an increasing number of other services) do not run with root privileges through the login process, which means that they cannot create home directories as pam_mkhomedir.so mandates. Forcing services to run as root is not recommended.

Enable the Services

You can start the main smb service for Samba by typing:

# /sbin/service smb start

To make the smb service automatically start on boot:

# /sbin/chkconfig --level 345 smb on

To run Winbind:

# /sbin/service winbind start

To make Winbind automatically start on boot:

# /sbin/chkconfig --level 345 winbind on

The main Samba service does not need to be running for Winbind to operate.

Tip: Username Formats

Kerberos usernames use this format, and must be in uppercase:

AUSER@ADEXAMPLE.LOCAL

Winbind usernames have the format:

ADEXAMPLE+auser

If you enable the setting winbind use default domain (as shown in the example smb.conf above), users may just specify an account name:

auser