Summary: Since the release of Windows 2000, Microsoft has offered Active Directory as its directory service, and later versions have renamed it Active Directory Domain Services (AD DS). AD DS leverages the popular LDAP for resource management, Kerberos for authentication, and tight integration with DNS for name resolution. If you currently use AD DS, integrating a Linux server can help centralize identity management and maintenance for Linux printing and file services. However, doing so can be challenging. Fortunately, Samba provides a solution for Linux integration with AD DS that requires no modification to the directory service.
In this article, learn about these concepts:
- Understanding Active Directory Domain Services (AD DS)
- Understanding how Samba communicates with AD DS
- Configuring Samba to work with AD DS
- Interacting with AD DS
.
Understanding Active Directory
Although other methods are available for integrating your Linux servers into the AD DS domain, Samba can help ease the management and configuration without requiring any schema modifications in AD DS or other software installations on the Windows Server computer. A Samba server can’t become a domain controller within an AD DS domain, but it can join as a member server and interact with AD DS services.
AD DS has its foundations in the following Internet standards:
- Domain Name System (DNS) for name resolution
- Kerberos version 5 for user authentication
- Lightweight Directory Access Protocol (LDAP) version 3 for directory services
LDAP originated out of the need for a more lightweight directory service than its predecessor, the X.500 protocol. LDAP has evolved a good deal since its its release in 1993. Today, it is the de facto Internet standard for directory services.
Microsoft claims LDAP compliance in the core. Table 1 shows the Requests for Comments (RFCs) providing extended support for reading and performing operations in LDAP.
Table 1. Microsoft RFC support for LDAP
| RFC | Support | |
|---|---|---|
| 2251 | LDAP v3 | Since Windows 2000 |
| 2252 | Attribute Syntax Definitions | Since Windows 2000 |
| 2253 | UTF-8 String Representation of Distinguished Names | Since Windows 2000 |
| 2254 | LDAP Search Filters Using Strings | Since Windows 2000 |
| 2255 | The LDAP URL Format | Since Windows 2000 |
| 2256 | The X.500 User Schema for use with LDAPv3 | Since Windows 2000 |
| 2829 | Authentication Methods for LDAP | Since Windows 2000 |
| 2830 | Extension for Transport Layer Security | Since Windows 2000 |
| 2589 | Extensions for Dynamic Directory Services | Since Windows Server 2003 |
| 2798 | Defines the inetOrgPerson LDAP Object Class |
Since Windows Server 2003 |
| 2831 | Using Digest Authentication as an SASL Mechanism | Since Windows Server 2003 |
| 2891 | LDAP Control Extension for Server Side Sorting of Search Results | Since Windows Server 2003 |
Kerberos was developed by the Massachusetts Institute of Technology to be a network authentication protocol at a time when security on the Internet and internal networks moved to the forefront. This protocol provides strong cryptography, which allows a client to prove its identity to a server; likewise, a server can prove its identity to the client. This operation uses tickets and authenticators.
AD DS tightly integrates with DNS and uses it to:
- Locate AD DS domain controllers
- Express the organizational structure in the names of its domains in a hierarchical manner
- Provide a name-resolution service for domain controller location and AD DS domains
Keep in mind that AD DS itself is not a DNS server and doesn’t replace the tasks that DNS typically performs. As a general rule, a DNS server stores zones and resource records, while AD DS uses the same namespace to store the domains and their objects. Table 2 compares typical DNS and AD DS roles.
| DNS | AD DS |
|---|---|
| Maps domain names to resource records | Stores DNS names as objects (dnsZone) |
| Maps computer names to resource records | Stores computer names as object records |
A service record (SRV record) is a specification of data in DNS defining the location of servers for specified services. For AD DS to function properly, DNS servers must provide support for service location resource records (RR). SRV RRs map the name of a service to the name of a server offering that service. AD DS clients and domain controllers use SRV records to determine the IP addresses of domain controllers.
Before your Linux server can interact with AD DS, you must verify your Samba installation can support LDAP and Kerberos. If you are using a previously compiled version of Samba, chances are your installation will support both Kerberos 5 and LDAP. If you compile Samba from source, be sure to include support for the
kbr5 and ldap libraries. Primarily, this involves a change to the include/config.h header file before running the make command:
#define HAVE_KRB5 1 |
Library names may vary, depending on your Linux computer.
When Samba is installed on your Linux computer, you can use the Samba service daemon
smbd to discover what your installation of Samba supports (see Listing 1).
Listing 1. Displaying a partial listing of Kerberos 5 support in Samba
[tbost@samba3 ~]$ smbd -b | grep KRB |
Listing 1 displays the support for the
krb5 and ldap libraries, respectively, on a Fedora distribution. Your output may differ depending on the distribution. Nonetheless, verify that your command output displays HAVE_KRB5_H and HAVE_LDAP_H at a minimum.Kerberos and NTP
Kerberos support relies on your Samba server keeping time in sync with the domain. AD DS is usually configured to use a domain controller for the time service. You can configure the Network Time Protocol (NTP) on your Linux computer using the specified Windows domain controller as the time server.
Samba can use Kerberos as a way to authenticate users in an AD DS domain. To configure Samba, locate the krb5.conf file in /etc directory, because you need to perform a few modifications to the default file configuration. At a minimum, you should specify the domain name in the
realms section of the file along with the fully qualified domain name of the Windows domain server that performs authentication for AD DS (see Listing 2).
Listing 2. Configuring the krb5.conf file
[realms] |
Listing 2 shows an example of a simple configuration using LPIC302.LOCAL as the AD DS domain name. Make sure you enter your domain in all uppercase letters, or Kerberos will not connect. The
kdc directive specifies the AD DS controller with host name wins3.lpic302.local. In addition, the admin_server is specified as the domain controller. The default_domainparameter is useful if you want Kerberos to assume this domain name when none is expressed by the user.The Winbind daemon facilitates authentication for users to the AD DS domain. As such, you should configure the Pluggable Authentication Modules (PAM) to use the
pam_winbind module, as shown in Listing 3.
Listing 3. Configuring PAM to use pam_winbind
auth sufficient pam_winbind.so |
Listing 3 displays the modified system-auth file in the /etc/pam.d directory on a Fedora-based distribution. Depending on your Linux distribution, the authentication file’s name may vary. Typically, the file name will be services or login.
The placement of pam_winbind.so is important. If you expect that your users will primarily authenticate from their AD DS account as opposed to the local passwd file, pam_winbind.so should be entered first. Otherwise, you may find your auth.log files filling quickly with failed local login attempts.
The Name Service Switch provides a standard mechanism by which your Linux computer can interact with common services, one being authentication. Your Linux computer will query the /etc/nsswitch.conf file when using these services. Modify this file as follows to allow your Linux computer to use Winbind for user authentication.
The code that follows highlights the process to add Winbind support to allow users to authenticate against an AD DS Kerberos 5 database using Winbind:
passwd: files winbind |
Not surprisingly, the smb.conf file needs a configuration change so Samba can work within the AD DS domain. At the most basic level, set the parameters for the
realm and security, as shown in Listing 4.
Listing 4. Configuring the smb.conf file
[global] |
The configuration in Listing 4 sets the
realm to the domain name, lpic302.local. The security parameter is set to ADS. ADS indicates that Samba will operate in AD DS Service security mode. You can set the line windbind use default domain = yes to eliminate the need to qualify user names and other resources with the domain name when accessing resources. For example, instead of authenticating with LPIC302.LOCAL/tbost, Winbind assumes the domain LPIC302.LOCAL when the user name tbost is specified.When configuration is complete, Samba has been restarted, and the Winbind daemon is running, you can interact with AD DS.
The
net tool is an extremely useful one for Samba administrators. If you have experience with the Windows net command, you’ll be familiar with many of its options and functionality. The net ADS command is what you use when working with AD DS. One of the first things to do is join a domain:
[tbost@samba3 ~]$ sudo net ADS join -U Administrator%password |
This code uses the
net command to join the domain. Alternatively, you can omit %password and enter the Windows Administrator account password when prompted. The second command verifies that the server has joined the domain. The third command in the snippet can create (or move from the default Computers object) a computer account for the Samba server in AD DS under ACCOUNTING/Servers. The object organizational unit ACCOUNTING/Servers should already exist in Active Directory if applying the third command. If you need more information about the net command, its online man page provides a lot of useful information. In addition, you can issue the command net help ADS, as shown in Listing 5.
Listing 5. Listing users and groups in an AD DS domain
[tbost@samba3 ~]$ net help ADS |
You use the
wbinfo tool, which the Winbind daemon provides, to query AD DS resources:
[tbost@samba3 ~]$ wbinfo -p |
This snippet uses
wbinfo to discover information about the domain. The wbinfo -p command pings the Winbind daemon to verify that it’s running. The wbinfo -u command returns a listing of all users in the domain, while wbinfo -g returns all groups in the domain. Consult the wbinfo manual for more tool options and functionality.If you are familiar with the
setfacl and getfacl commands, you should have little problem learning the smbcacls command that the Samba client suite provides. You can use the smbcacls tool to change group and user ownership or manage access control list permissions on shares provided by a Windows Server machine in a domain:
[tbost@samba3 ~]$sudo smbcacls -G LPIC302.LOCALaccounting |
This code uses the
smbcacls command to change the group permissions on the file private.doc to the accounting group on the shared directory budget on a Windows Server machine to the accounting group within the AD DS domain. The smbcacls --help command displays the available options to the various functionality of the tool.