Chapter 4. Using Samba, Kerberos, and Winbind

The Samba standard Windows interoperability suite of utilities allows Linux systems to join an Active Directory environment by making them appear to be Windows clients. As a means of systems integration, Samba allows a Linux client to join an Active Directory Kerberos realm and to use Active Directory as its identity store.
Winbind is a component of the Samba suite to provide unified logon. It uses a UNIX implementation of Microsoft RPC calls, Pluggable Authentication Modules (PAMs), and the Name Service Switch (NSS) to allow Windows domain users to appear and operate as UNIX users on a UNIX system.

4.1. About Samba and Active Directory Authentication

While the core functionality of Samba is to perform client-server networking for file and printer sharing and associated operations, this chapter only focuses on one aspect of using Samba to interact with Windows: allowing Linux clients to authenticate by using Active Directory.

4.1.1. Samba, Kerberos, and Active Directory Domains

Active Directory is the domain controller for a number of services in Windows environments, including Kerberos realms and DNS domains. Samba supports the full range of protocols used in Active Directory, including Kerberos, DNS, NTLMSSP, or DCE/RPC. Integration with Active Directory means configuring a security environment that uses Kerberos as the native security context in Active Directory.
Several different system services should be configured on the Linux client to use Active Directory as a domain controller:
  • Samba – for users and authentication
  • DNS – to set the Active Directory server as the name server
  • Kerberos – to use the Active Directory KDC
  • PAM – to use Winbind
  • NSS – to use Winbind

4.1.1.1. Samba

There are several different ways how a Samba server can join an Active Directory domain. In SMB/CIFS networking, there are two types of security: user-level and share level. Samba provides four ways to use user-level security. Collectively, we call them the security modes. Only two of them are important for Windows integration:
  • ads configures the local Samba server as a domain member within an Active Directory domain. It also enables support for the internal usage of LDAP queries and Kerberos authentication. This is the preferred security mode.
  • domain configures the Samba server as a domain member server within an Active Directory domain by using the DCE/RPC protocol.
The necessary configuration is located in the [global] section of /etc/samba/smb.conf. The essential settings include the security type (security); the name of the Active Directory Kerberos realm (realm), which is resolved by DNS discovery; and the Samba workgroup (workgroup):
#================= Global Settings ====================

[global]
    workgroup = ADEXAMPLE  
    security = ads
    realm = ADEXAMPLE.COM

...

4.1.1.2. Kerberos

Kerberos must be configured to use the Active Directory server as its KDC. It allows users to use Kerberos tickets for authentication. Additionally, Samba must be configured to use the Active Directory Kerberos realm, which allows Winbind to manage the Kerberos principals.
The Active Directory realm should be set as the default domain in the [libdefaults] section of the /etc/krb5.conf file, and then as a KDC in the [realms] section. The [domain_realm] section should define the Active Directory domain.
For seamless Kerberos experience, ensure the Winbind Kerberos locator plug-in is installed from the samba-winbind-krb5-locator package. It ensures that Winbind and all its users and the Kerberos library and all its users use the same KDC all the time.
[libdefaults]
... 
	
  default_realm = ADEXAMPLE.COM

[realms]
  ADEXAMPLE.COM = {
    kdc = kdc.adexample.com
}

[domain_realm]
 adexample.com = ADEXAMPLE.COM
  .adexample.com = ADEXAMPLE.COM

4.1.1.3. DNS

The local DNS service must be configured to use Active Directory as its domain controller. DNS is critical for proper resolution of host names and domains for Kerberos. While many systems have proper DNS settings so that the Samba-Active Directory integration could work well without configuring Active Directory as a name server, using Active Directory as a name server avoids any potential resolution problems. The domain should also be added as a search directive, so that the Active Directory domain is used for searches and discovery.
DNS settings are configured in the /etc/resolv.conf file.
nameserver 1.2.3.4 
search adexample.com

4.1.1.4. PAM and NSS

PAM and NSS allow local applications to use the Kerberos credentials provided by Active Directory, which enables single sign-on for system applications and domain users. For ease of use, offline caching of credentials, and other features, it is recommended to use Winbind.
For PAM, the Winbind libraries are set for authentication, account, password, and optionally session management. This is configured in the /etc/pam.d/system-auth file:
auth		required	pam_env.so
auth		sufficient	pam_unix.so nullok try_first_pass
auth		requisite	pam_succeed_if.so uid >= 500 quiet
auth		sufficient	pam_winbind.so use_first_pass
auth		required	pam_deny.so

account		required	pam_unix.so broken_shadow
account		sufficient	pam_localuser.so
account		sufficient	pam_succeed_if.so uid < 500 quiet
account		[default=bad success=ok user_unknown=ignore] pam_winbind.so
account		required	pam_permit.so

password	requisite	pam_cracklib.so try_first_pass retry=3 type=
password	sufficient	pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password	sufficient	pam_winbind.so use_authtok
password	required	pam_deny.so

session		optional	pam_keyinit.so revoke
session		required	pam_limits.so
session		[success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session		required	pam_unix.so
session		optional	pam_krb5.so
session		optional	pam_winbind.so use_first_pass
Another important configuration file is /etc/security/pam_winbind.conf. In it, various parameters and defaults are set, including Kerberos authentication, offline authentication, or automatic home directory creation. For further details, see the pam_winbind.conf(5) man page.
For NSS, Active Directory can be used for passwords, shadow (users), and groups by setting Winbind as an option. Additionally, you can add the WINS service option to use the configuration also for hosts. Always use files as the first location to check for accounts; this allows local system users and services to be able to log in and access resources.
NSS settings are configured in the /etc/nsswitch.conf file:
passwd:     files winbind
shadow:     files winbind
group:      files winbind

hosts:      files dns wins

Note

Note that PAM and NSS should not configured manually for integration with Active Directory. Instead, use the authconfig utility. See Section 4.3, “Configuring a Domain Member Using authconfig for details.

4.1.2. Authentication Using Winbind and Samba

There are two important tasks when managing files: to establish the proper ownership and to control access to appropriate parties. Both relate to an effective way to identify and authenticate users. Winbind provides three related but separate capabilities:
  • Authenticate users using local PAM configuration,
  • Resolve IDs, user names, and groups using NSS lookups,
  • Create a database of mapped Active Directory SIDs and local UID/GID numbers.
Winbind is part of Samba and connects directly to the Active Directory domain. The local Linux system is a full domain member in Windows terminology, represented with a complete machine account stored in AD. PAM and NSS are configured to use Winbind for user identities on the local system.
Among other aspects of using Winbind are:
  • Winbind primarily maintains the machine account credentials (the Linux machine representation as a machine account in Active Directory). Among other functions, it can be used to update the machine account credentials or to update (or comply to) local stores of password policies.
  • Winbind supports POSIX attributes in the form of RFC 2307 attributes or in the form of "Microsoft Services for Unix" extensions (both version 3.5 and 3.0). See the idmap_ad(8) man page for details.
  • Joining the domain is done with utilities provided by Samba (using commands such as net ads join). Kerberos ticket management is done by Winbind, including ticket refresh and ticket re-acquisition.
  • The smb.conf file is the only location for defining ID mappings.

Note

In Red Hat Enterprise Linux, it is recommended to use SSSD as a capable alternative for direct integration with Active Directory. See Chapter 2, Using Active Directory as an Identity Provider for SSSD for more information.