User:Tbw/Active Directory Integration With SSSD

From ArchWiki

Related articles

A key challenge for system administrators of any datacenter is trying to coexisting in Heterogeneous environments. By this we mean the mixing of different server operating system technologies (typically Microsoft Windows & Unix/Linux). User management and authentication is by far the most difficult of these to solve. The most common way of solving this problem is to use a Directory Server. There are a number of open-source and commercial solutions for the various flavors of *NIX; however, few solve the problem of interoperating with Windows. Active Directory (AD) is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Server computers on which Active Directory is running are called domain controllers.

Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user.

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos and DNS. These same standards are available as linux, but piecing them together is not an easy task. Following these steps will help you configure an ArchLinux host to authenticate against an AD domain.

This guide explains how to integrate an Arch Linux host with an existing Windows Active Directory domain. Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join).

This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.

Terminology

If you are not familiar with Active Directory, there are a few keywords that are helpful to know.

  • Domain : The name used to group computers and accounts.
  • SID : Each computer that joins the domain as a member must have a unique SID or System Identifier.
  • SMB : Server Message Block.
  • NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
  • SSSD: SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms.

Configuration

Active Directory Configuration

This section works with the default configuration of Windows Server 2012 R2.

Updating the GPO

[To be removed if not confirmed]

It may be necessary to disable Digital Sign Communication (Always) in the AD group policies. Dive into:

Local policies -> Security policies -> Microsoft Network Server -> Digital sign communication (Always) -> activate define this policy and use the disable radio button.

If you use Windows Server 2008 R2, you need to modify that in GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> Microsoft network client: Digitally sign communications (always)

Linux Host Configuration

The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.

Installation

Install the following packages:

Updating DNS

Active Directory is heavily dependent upon DNS. You will need to update /etc/resolv.conf to use one or more of the Active Directory domain controllers: 

/etc/resolv.conf
nameserver <IP1>
nameserver <IP2>

Replacing <IP1> and <IP2> with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers.

Note: If your machine dual boots Windows and Linux, you should use a different DNS hostname and netbios name for the linux configuration if both operating systems will be members of the same domain.

Configuring NTP

Read Time synchronization to configure an NTP service.

On the NTP servers configuration, use the IP addresses for the AD servers, as they typically run NTP as a service. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum.

Ensure that the service is configured to sync the time automatically very early on startup.

Kerberos

Let us assume that your AD is named example.com. Let us further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here. 

/etc/krb5.conf
[libdefaults]
        default_realm 	= 	EXAMPLE.COM
	clockskew 	= 	300
	ticket_lifetime	=	1d
        forwardable     =       true
        proxiable       =       true
        dns_lookup_realm =      true
        dns_lookup_kdc  =       true
	
[realms]
	EXAMPLE.COM = {
		kdc 	= 	PDC.EXAMPLE.COM
                admin_server = PDC.EXAMPLE.COM
		default_domain = EXAMPLE.COM
	}
	
[domain_realm]
        .kerberos.server = EXAMPLE.COM
	.example.com = EXAMPLE.COM
	example.com = EXAMPLE.COM
	example	= EXAMPLE.COM

[appdefaults]
	pam = {
	ticket_lifetime 	= 1d
	renew_lifetime 		= 1d
	forwardable 		= true
	proxiable 		= false
	retain_after_close 	= false
	minimum_uid 		= 0
	debug 			= false
	}

[logging]
	default 		= FILE:/var/log/krb5libs.log
	kdc 			= FILE:/var/log/kdc.log
        admin_server            = FILE:/var/log/kadmind.log
Note: Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You will probably have to add 
allow_weak_crypto = true
to the [libdefaults] section.

Creating a Kerberos Ticket

Now you can query the AD domain controllers and request a kerberos ticket (uppercase is necessary): 

kinit administrator@EXAMPLE.COM

You can use any username that has rights as a Domain Administrator.

Validating the Ticket

Run klist to verify you did receive the token. You should see something similar to: 

# klist
 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: administrator@EXAMPLE.COM
 
 Valid starting    Expires           Service principal 
 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
         renew until 02/05/12 21:27:47

Samba

Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.

Note: The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research

In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares. 

/etc/samba/smb.conf
[global]
   workgroup = EXAMPLE
   password server = pdc.example.com
   realm = EXAMPLE.COM
   security = ads
   server string = %h ArchLinux Host
   kerberos method = secrets and keytab

Join the Domain

You need an AD Administrator account to do this. Let us assume this is named Administrator. The command is 'net ads join' 

# net ads join -U Administrator
Administrator's password: xxx
Using short domain name -- EXAMPLE
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'

Configuring, starting and testing services

Configuring and starting SSSD

Configure SSSD to connect to the Active Directory domain: 

/etc/sssd/sssd.conf
[sssd]
domains = example.com
config_file_version = 2
services = nss, pam
default_domain_suffix = example.com

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = ad
full_name_format = %1$s

SSSD requires permission 600 on sssd.conf to start 

chmod 600 /etc/sssd/sssd.conf

Enable and start the SSSD deamon sssd.service.

Configuring NSSwitch

Next we will need to modify the NSSwitch configuration, which tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory (sss) as additional sources for Users and Groups. 

/etc/nsswitch.conf
passwd: compat mymachines systemd sss
group: compat mymachines systemd sss
shadow: compat sss

Testing SSSD

To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the 'id' command. The following output shows that user information was retried from Active Directory: 

# id test.user@ad.example.com
uid=1897201121(test.user@ad.example.com) gid=1897200513(test.user@ad.example.com) groups=1897200513(domain users@ad.example.com),1897201115(test.group1@ad.example.com),1897201125(test.group2@ad.example.com)

Configuring PAM

Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as required or sufficient is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.

In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include pam_winbind.so into the authentication process.

The Arch Linux PAM configuration keeps the central auth process in /etc/pam.d/system-auth. Starting with the stock configuration from pambase, change it like this:

system-auth

"auth" section

Find the line: 

auth required pam_unix.so ...

Delete it, and replace with: 

auth [success=1 default=ignore] pam_localuser.so
auth [success=2 default=die] pam_sss.so
auth [success=1 default=die] pam_unix.so nullok
auth requisite pam_deny.so

"account" section

Find the line: 

account required pam_unix.so

Keep it, and add this below: 

account [success=1 default=ignore] pam_localuser.so
account required pam_sss.so

"password" section

Find the line: 

password required pam_unix.so ...

Delete it, and replace with: 

password [success=1 default=ignore] pam_localuser.so
password [success=2 default=die] pam_sss.so
password [success=1 default=die] pam_unix.so sha512 shadow
password requisite pam_deny.so

"session" section

Find the line: 

session required pam_unix.so

Keep it, and add this line immediately above it: 

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

Below the pam_unix line, add these: 

session [success=1 default=ignore] pam_localuser.so
session required pam_sss.so

passwd

"password" section

In order for logged-in Active Directory users to be able to change their passwords with the 'passwd' command, the file /etc/pam.d/passwd must include the information from system-auth.

Find the line: 

password required pam_unix.so sha512 shadow nullok

Delete it, and replace with: 

password include system-auth

Testing login

Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the /etc/ssh/sshd_config file to allow kerberos authentication (KerberosAuthentication yes). 

test.user
EXAMPLE+test.user

Both should work. You should notice that /home/example/test.user will be automatically created. Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!

Configuring Shares

Earlier we skipped configuration of the shares. Now that things are working, go back to /etc/samba/smb.conf, and add the exports for the host that you want available on the windows network. 

/etc/samba/smb.conf
[MyShare]
  comment = Example Share
  path = /srv/exports/myshare
  read only = no
  browseable = yes
  valid users = @NETWORK+"Domain Admins" NETWORK+test.user

In the above example, the keyword NETWORK is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that Domain Admins is encapsulated in quotes so Samba correctly parses it when reading the configuration file.

See also

Commercial Solutions

  • Centrify
  • Likewise
Retrieved from "https://wiki.archlinux.org/index.php?title=User:Tbw/Active_Directory_Integration_With_SSSD&oldid=549930"