Adding a Linux Server to an Active Directory Domain
- Configure Kerberos
- Configure Samba
- Add the System to Active Directory
- Configure Winbind
- Disable NSCD
- Configure Services To Use Winbind
- Enable the Services
- 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.
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.
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:
Before starting this process, ensure that the Linux system is networking correctly, and has a valid entry in DNS. Also ensure that you know:
- The DNS name of a DC server.
- An Active Directory username and password that has the right to add machines to the Active Directory.
- The Organizational Unit (OU) that you want the Linux server to be listed in.
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).
Samba includes a very complete set of documentation. The relevant sections are in the Samba HOWTO:
- Joining Active Directory As A Member Server (Chapter 7)
- Synchronising Accounts with Winbind (Chapter 21)
For PAM the documentation is here:
This walk-through was also very useful for me:
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.
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:
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:
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:
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"
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
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:
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
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:
Winbind usernames have the format:
If you enable the setting winbind use default domain (as shown in the example smb.conf above), users may just specify an account name: