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

This article helps you prepare for Objective 314.3 in Topic 314 of the Linux Professional Institute's (LPI) Mixed Environment specialty exam (302). The objective has a weight of 2.

Prerequisites

To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In particular, this article assumes that you have a working knowledge of Linux command-line functions and at least a general understanding of the purpose of Samba as covered in Learn Linux, 302 (Mixed environments): Concepts. To perform the actions described in this article, you must have the Samba software installed. In addition, you should have access to a computer running a Windows Server operating system configured for and running AD DS.

Back to top

Understanding Active Directory

If you work in an environment with a lot of Windows clients or one that already has AD DS in place, you may consider integrating your Linux servers into the AD environment. AD has been Windows' authentication and directory service since Microsoft Windows 2000. A significant paradigm shift from the primary domain controller and backup domain controller, AD DS uses domain controllers that can be replicated to one another.

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 3

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.

Kerberos 5

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 uses Kerberos version 5 for user authentication. In AD DS, a domain controller acts a Kerberos Key Distribution Center for client authentication.

DNS

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.

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.

Back to top

Configuring Samba for AD DS support

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
#define HAVE_LDAP 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).

	
[tbost@samba3 ~]$ smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_KRB5_LOCATE_PLUGIN_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_DECL_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
   HAVE_DECL_KRB5_GET_CREDENTIALS_FOR_USER
   HAVE_INITIALIZE_KRB5_ERROR_TABLE
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
   HAVE_KRB5_C_ENCTYPE_COMPARE
   HAVE_KRB5_C_VERIFY_CHECKSUM
   HAVE_KRB5_DEPRECATED_WITH_IDENTIFIER
   HAVE_KRB5_ENCRYPT_BLOCK
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_ENCTYPE_TO_STRING
.....

[tbost@samba3 ~]$smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_ADD_RESULT_ENTRY
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SASL_WRAPPING
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

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.

Samba and Kerberos

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).

	
[realms]

	LPIC302.LOCAL= {
		kdc = wins3.lpic302.local 
		admin_server =wins3.lpic302.local
		default_domain = LPIC302.LOCAL
	
	}

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_domain parameter is useful if you want Kerberos to assume this domain name when none is expressed by the user.

The Winbind daemon

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.

	
auth        sufficient   pam_winbind.so
auth        sufficient   pam_unix.so use_first_pass
auth        required     pam_stack.so service=system-auth
auth        required     pam_nologin.so
account     sufficient   pam_winbind.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     optional     pam_console.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

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
group:	 files winbind

smb.conf

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.

	
[global]
realm = lpic302.LOCAL
security = ADS
password server = wins.lpic302.local
workgroup = lpic302
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

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.

Back to top

Interacting with AD DS

When configuration is complete, Samba has been restarted, and the Winbind daemon is running, you can interact with AD DS.

Using the net command

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
[tbost@samba3 ~]$ sudo net ADS testjoin
[tbost@samba3 ~]$ sudo net ADS join -U Administrator createcomputer="ACCOUNTING/Servers"

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.

	
[tbost@samba3 ~]$ net help ADS
Usage:
net ads info
    Display details on remote ADS server
net ads join
    Join the local machine to ADS realm
net ads testjoin
    Validate machine account
net ads leave
    Remove the local machine from ADS
net ads status
    Display machine account details
net ads user
    List/modify users
net ads group
    List/modify groups
net ads dns
    Issue dynamic DNS update
net ads password
    Change user passwords
net ads changetrustpw
    Change trust account password
net ads printer
    List/modify printer entries
net ads search
    Issue LDAP search using filter
net ads dn
    Issue LDAP search by DN
net ads sid
    Issue LDAP search by SID
net ads workgroup
    Display the workgroup name
net ads lookup
    Find the ADS DC using CLDAP lookups
net ads keytab
    Manage local keytab file
net ads gpo
    Manage group policy objects
net ads kerberos
    Manage kerberos keytab

Interacting with wbinfo

You use the wbinfo tool, which the Winbind daemon provides, to query AD DS resources:

[tbost@samba3 ~]$  wbinfo -p
[tbost@samba3 ~]$  wbinfo -u 
[tbost@samba3 ~]$  wbinfo -g 

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.

Managing access control lists with smbcacls

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.LOCAL\accounting \
//wins2.lpic302.local/budget private.doc

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.

Resources

Learn

• Learn more about integrating Samba, Active Directory & LDAP from the Samba 3.x manual.
  
  
• Understand how Samba uses DNS with AD DS from the Samba manual.
  
  
• Learn how to configure Samba for AD DS authentication.
  
  
• Learn how Winbind interacts with AD DS in the Samba manual.
  
  
• Learn more about LDAPv3 from the LDAPv3 working group.
  
  
• At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the LPI's Linux systems administration certification. In particular, look at the LPI-302 detailed objectives.
  
  
• Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
  
  
• In the developerWorks Linux zone, find hundreds of how-to articles and tutorials as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
  
  
• Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
  
  
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
  
  
• Attend a free developerWorks Live! briefing to get up to speed quickly on IBM products and tools as well as IT industry trends.
  
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
  
  

Discuss

• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the author

Tracy Bost is a seasoned software developer and systems engineer. He is also a lecturer and trainer for the Linux operating system. Tracy has been certified as both a Red Hat Certified Engineer (RHCE) and a Microsoft Certified Systems Engineer (MCSE), along with being an active member of the Linux Foundation. He has worked in several industries, including mortgage, real estate, and the nonprofit sector.

Rate this article

Comments

Back to top

Table of contents

• Prerequisites
• Understanding Active Directory
• Configuring Samba for AD DS support
• Interacting with AD DS
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Linux on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers