Overview

In this article, learn about these concepts:

• Domain membership
• Configuring a primary domain controller
• Configuring a backup domain controller
• Adding computers to a domain
• Managing logon scripts
• Managing roaming profiles
• Managing system policies

This article helps you prepare for Objective 312.4 in Topic 312 of the Linux Professional Institute's Mixed Environment Specialty exam (302). The objective has a weight of 4.

Back to top

Prerequisites

This article assumes that you have a working knowledge of Linux command-line functions and that you understand the basics of Samba configuration. You should be familiar with the overall structure of the smb.conf configuration file and be able to edit it in the editor of your choice. You should be able to bring a Samba server up to serve files.

Back to top

Setting basic domain features

A domain controller's primary purpose is to manage authentication for other computers. This requires the Samba server to accept certain types of authentication data from its clients and to respond appropriately. Enabling these features requires setting a few smb.conf options. In practice, domain controllers also tend to serve additional roles on the network, so you may need to adjust additional Samba options.

Before proceeding further, you should be aware of the relationships between the computers on a Microsoft® Windows NT®-style domain. The domain controller is at the core of this network. Its clients may be file and print servers running Samba, the Windows® operating system, or some other software. These computers are known as domain member servers, and they function both as servers (to user workstations) and as clients (to the domain controller). The architecture of the network can affect these relationships. For instance, in a peer-to-peer network, a single computer can function as both a domain member server and as a file-sharing client. The domain controller can function as a file server and even as a client.

Setting mandatory domain controller features

The most basic Samba configuration for a domain controller involves setting the following smb.conf options:

workgroup = EXAMPLE
security = User
encrypt passwords = Yes
passdb backend = tdbsam:/etc/samba/private/passdb.tdb
domain logons = Yes
admin users = ntadmin

Some of these options can be changed, depending on your needs, but others cannot. Specifically:

• The workgroup option sets the Windows NT domain name. A domain is just a workgroup with extra features.
• The security option must be set to User.
• The encrypt passwords option must be set to Yes.
• The passdb backend option can be set to any legal value; however, if you want to use both primary and backup domain controllers, you may need to set it in a particular way, as described in Configuring a backup domain controller.
• The domain logons option must be set to Yes.
• The admin users option sets one or more users (ntadmin, in this example) as administrative users. These users effectively have root privileges to any share to which they connect. You must either set an administrative user in this way or add root to your Samba account database to join new computers to your domain.

These settings have certain implications. Specifically, your Samba server computer must have local Linux accounts for all the users it should authenticate, and these accounts must have entries in the Samba password database. Once you've configured Samba in this way, it will begin accepting domain logons—but only for old Microsoft Windows 9x/Me computers or Samba servers set with the security = Server option. For more recent Windows computers or for Samba computers that use the more secure security = Domain configuration, you must create machine trust accounts.

Creating machine trust accounts

Unlike workgroups, which any computer on a network can join, domains are exclusive: To gain the full benefits of a domain, a computer must be a full-fledged member of the domain. From a user's perspective, the main benefit of domain membership is single sign-on, which means that a user need only type a user name and password once to gain access to any server that's a member of the domain. From a Samba administrative perspective, domain membership enables use of the security = Domain configuration option on domain member servers. This setting is more secure than the security = Server setting, but fully joining the domain requires additional configuration.

To fully join a domain, a computer (either a domain member server or a client system) requires its own account on the domain controller. The domain controller itself is exempt from this requirement. This account is independent of the account of any user who might use the computer. This account is known as a machine trust account.

It's best for all your machine trust accounts to use a single Linux group reserved for this purpose. The following command creates a group called trust for this purpose:

# groupadd -r trust

With the machine trust group created, you can proceed with creating machine trust accounts—one for each domain member (client or server) on your network. You should use the computers' network basic input/output system (NetBIOS) names, converted to lowercase text and with dollar signs ($) appended, as user names. For instance, if the computer's NetBIOS name is WEMBLETH, its machine trust account name would be wembleth$. You can use the useradd and smbpasswd commands to create these accounts, as in:

# useradd -d /dev/null -M -g trust -s /bin/false wembleth$
# smbpasswd -a -m wembleth$

This example creates a machine trust account called wembleth$, setting the account's home directory to /dev/null (-d /dev/null), telling the utility not to create the home directory (-M), adding it as a member of the trust group (-g trust), and setting the default shell to /bin/false (-s /bin/false). The second command creates an entry in the Samba password database for the account, specifying that it should be a machine trust account (-m).

If you created a new user for the admin user parameter, you must set that user's Samba password with smbpasswd, as in smbpasswd ntadmin, to set that user's password. This account will be used when adding machines to the domain. If you have no other use for this account's high privilege under Samba, seriously consider commenting out the admin users line in smb.conf after you've joined all your domain clients to the domain.

Setting additional domain features

Although the features just described make up the critical domain controller features, domain controllers also typically take on certain other roles on a NetBIOS network. In particular, they function as domain master browsers, as Windows Internet Name Service (also known as NetBIOS Name Server) systems, and often as time servers. You can configure these features by setting the following options:

domain master = Yes
preferred master = Yes
os level = 65
wins support = Yes
time server = Yes

Once you've saved your changes to the smb.conf file, Samba eventually detects the changes and reconfigures itself. If you want to speed matters up, you can pass the server a SIGHUP signal or use your distribution's SysV init scripts to reload the configuration.

Adding computers to a domain

At this point, your Samba server is sufficiently configured to function as a domain controller, and you can begin adding computers to the domain. How you do this depends on the operating system installed on the domain member server or domain client, however. In Windows 7, perform these steps:

1. Enter the following registry entries.
   
   

   HKEY_LOCAL_MACHINE\System\CCS\Services\LanmanWorkstation\Parameters DWORD DomainCompatibilityMode = 1 DWORD DNSNameResolutionRequired = 0

   
   

   Alternatively, download the Win7_Samba3DomainMember.reg file and double-click it on the Windows system. This step is not required for Windows Vista® or earlier Windows operating systems.

2. Open the Control Panel System and Security item.
3. Click System.
4. Click Change Settings under the Computer Name, Domain, and Workgroup Settings heading.

   Windows opens a system properties window.

5. Click Change.

   Windows opens the Computer Name/Domain Changes window, shown in Figure 1.

   
   
   Figure 1. You join a domain in Windows by using the Computer Name/Domain Changes window
   
   
   
6. Select the Domain option, and then type your domain name in the text box.
7. Click OK.

   Windows responds by opening the Windows Security window, shown in Figure 2.

   
   
   Figure 2. The Windows Security window prompts for your administrative user name and password
   
   
   
8. Type your Samba administrative account name (as set via admin users) and password in the window, and then click OK.

Windows prompts you to restart the computer, after which you should be joined to the domain.

Note: Not all versions of Windows can join a domain. The Home versions, for example, are restricted to use in workgroups.

After you have joined a Windows computer to your domain and restarted it, the computer prompts you to press Ctrl-Alt-Del to log on. You should use a user name and password associated with your Samba server to log on. Thereafter, you will be able to access any computer that's a part of the domain and that authorizes the account you used at your first logon without retyping your password. If you configure the computer to share files or printers, the computer relies on the Samba server for authentication.

If you want a Samba server to function as a domain member, you must also join it to the domain. To do so, first set the following options in the Samba domain member server's smb.conf file:

password server = SERVERNAME
domain logons = No
encrypt passwords = Yes
security = Domain
domain master = No
preferred master = No
os level = 1
wins support = No

Many of these options are the opposite of those for the domain controller; you must set them in this way to ensure that you don't have two computers competing to be master browsers or to deliver NetBIOS names. The password server option should point to the domain controller you intend to use. The security option can be set in either of two ways: You can set it to Domain, as in this example, to fully join the domain, or you can set it to Server, in which case Samba will not fully join the domain but will send its password requests on to the domain controller using simpler, non-domain protocols. If you set security = Domain, you must fully join the domain by typing the following command:

# net join member -U ntadmin

Change ntadmin to the user name you've chosen for your administrative account. The program prompts for a password; enter the password associated with the ntadmin user. If all goes well, you'll see a message that you've joined the domain that you've specified via the workgroup option in smb.conf.

Once you've joined a Samba server to a domain, the computer relies on the domain controller for authentication—but only for Samba. Topic 313.3, Winbind, covers modifying a Linux computer to use a domain controller for non-Samba authentication tasks.

Back to top

Creating domain shares and user settings

When you have tested basic domain logon functionality, you may want to go further. One way to do so is to create a special domain share called NETLOGON and configure Samba to store users' Windows desktop settings on the domain controller.

Creating NETLOGON shares

Domain logon scripts are stored in the NETLOGON share. These scripts run on the domain client whenever a user logs on to a domain. Thus, you should create such scripts in Windows and test them in Windows: These are not Linux scripts.

A NETLOGON share is an ordinary file share of that name. (Objective 312.2 covers creating file shares.) Ordinarily, you want to limit who can write to the NETLOGON share. A typical definition might look like this:

[netlogon]
   comment = Network Logon Service
   path = /var/samba/netlogon
   guest ok = No
   read only = Yes
   write list = abe

This example creates a read-only share to be stored in /var/samba/netlogon. The write list parameter gives the user abe write access to the share. Note that abe must have Linux write access to /var/samba/netlogon; if Linux permissions prevent abe from writing to this directory, listing the user in the share's write list does no good.

Windows clients must know what scripts to run from the NETLOGON share. This is done through the logon script global parameter. A basic example sets a simple file name:

logon script = LOGON.BAT

This example tells all clients to run the LOGON.BAT file. Sometimes, though, you need to provide different logon scripts for different clients. For instance, you might need different scripts for different client operating systems. An example that does this might look like this:

logon script = LOGON-%a.BAT

In this example, %a is a variable that takes on a different value for different client operating systems, as detailed in Table 1. You can use other variables, as well, as described in Objective 312.1. If you were to use the preceding example, a Windows 7 client would execute the script called LOGON-Vista.BAT, whereas a Windows XP client would execute the script called LOGON-WinXP.BAT. Note that not all operating systems use network logon scripts. For instance, Linux does not, so you wouldn't need to create a LOGON-CIFSFS.BAT script.

In addition to network logon scripts, the NETLOGON share can hold a system policies file. This file can automatically make changes to the Windows registry file to help the computer fit into the domain. Under Windows 9x/Me, the policies file is called Config.POL and is generated on a Windows computer using a tool called the Policy Editor (Poledit.exe). Under Windows NT, Windows 2000, Windows Server 2003, Windows XP, Windows Vista, and Windows 7, the policy file is called NTConfig.POL and is generated by clicking Start > Programs > Administrative Tools. Generating these files is beyond the scope of this article, but you should be aware of the possible need to place the file in the NETLOGON share.

Creating roaming profiles

Ordinarily, Windows computers store information on their users' desktop environments locally. This is fine if each individual uses just one computer most of the time; however, this isn't always the case. In a university's computer lab, for instance, individuals might log on using any of several different computers. In such a situation, it's desirable to store users' desktop settings on a remote server. This is the job of a roaming profile.

To enable roaming profiles for Windows NT, Windows 2000, Windows XP, Windows Vista, and Windows 7, you must create a PROFILES share. This share is typically made non-browseable so that it doesn't show up in browse lists and confuse users. It's also set with limited file and directory permissions within Samba to prevent users from reading or writing each others' profiles. The Linux directory used for the share, though, must enable all users to read and write to it (0777 permissions may be required, depending on your group policies). The Samba share used to store roaming profiles might look like this:

[profiles]
   comment = NT Profiles Share
   directory = /var/samba/profiles
   read only = No
   create mode = 0600
   directory mode = 0700
   browseable = No

This share is conventionally created on the Samba domain controller; however, it could in principle appear on some other file server. In addition to creating the PROFILES share, you must tell Windows where to find it. You do this with the global logon path option:

logon path = \\%L\PROFILES\%U

This example uses the %L variable (the NetBIOS name of the current server) and the %U variable (the user name associated with the session) as part of the path to the roaming profile directory. Be sure that your roaming profiles are stored in the PROFILES share you created.

Back to top

Configuring a backup domain controller

Windows NT domains can have multiple domain controllers to provide redundancy in case one fails. In Windows NT domain parlance, one domain controller is designated as the primary domain controller (PDC), and the other is the backup domain controller (BDC). This configuration entails additional configuration complexity, but it's worthwhile if your network is highly dependent on the domain controller.

In Samba, enabling a BDC is best done by using the Lightweight Directory Access Protocol (LDAP) to store account information. LDAP was designed to support the sort of database data exchanges required for this type of configuration, so pairing a PDC with a master LDAP server and the BDC with a slave LDAP server makes sense. The LDAP servers can run on the same or different computers than the Samba servers. Other configurations, such as using a single LDAP server with both the PDC and BDC, are possible but not optimal, because you lose at least some failover capability—particularly if the LDAP server runs on the same computer as one of the domain controllers.

A minimal PDC configuration that uses an LDAP server adds several Samba configuration options for identifying the LDAP server. Changed or new global options for the PDC are, at a minimum:

passdb backend = ldapsam://localhost:389
ldap suffix = dc=example,dc=org
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=ntadmin,dc=example,dc=org

This example tells Samba to use an LDAP server running on the same computer (passdb backend = ldapsam://localhost:389) and identifies various critical LDAP features used to identify and administer account information.

Note: LDAP configuration is a complex topic in and of itself. In this article, I assume that your master and slave LDAP servers are already properly configured. Check the Resources section for links to additional LDAP information.

I recommend configuring your PDC to use the master LDAP server and thoroughly testing this configuration before proceeding. With that task done, you can configure the BDC, beginning with a few preliminary steps:

1. Type net rpc getsid on the BDC computer.

   This command retrieves a critical identifier that must match on the PDC and BDC computers.

2. Type smbpasswd -w mypass on the BDC, where mypass is the LDAP administrative password.
3. Synchronize the local account database on the PDC and BDC.

   You can do this in several ways, the simplest of which is copying /etc/passwd, /etc/group, and /etc/shadow from one computer to another. If you use LDAP for Linux account maintenance, this step may not be necessary.

4. Duplicate the NETLOGON share from the PDC on the BDC.

   Remember to copy both the share definition in smb.conf and the share's directory. You should synchronize the share directory on a regular basis so as to replicate changes that might be made over time.

With these steps taken care of, you can create your BDC configuration in smb.conf:

passdb backend= ldapsam:ldap://slave-ldap.example.org
domain master = No
domain logons = Yes
os level = 64
ldap suffix = dc=example,dc=org
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=ntadmin,dc=example,dc=org
idmap backend = ldap:ldap://master-ldap.example.org
idmap uid = 10000-20000
idmap gid = 10000-20000

These options cause the BDC to defer to the PDC in master browser elections, to use the slave LDAP server (slave-ldap.example.org) for its password database, and to use the master LDAP server (master-ldap.example.org) for storing mapping information between Linux and Windows account information.

Back to top

Setting up interdomain trusts

In a large organization, different departments may have their own Windows NT domains. This configuration enables each department to maintain its own accounts, but it can limit the ability of departments to use each others' resources. For instance, two departments that are physically close to each other might want to enable each others' users to use their printers as a shared resource. This type of cross-domain resource sharing can be implemented by setting up interdomain trusts, or trusts for short.

Trust relationships have two important properties you should keep in mind. First, they're nontransitive, meaning that they affect only the domains for which they're explicitly configured. For instance, if the PHYSICS domain trusts GEOLOGY, and GEOLOGY trusts BIOLOGY, PHYSICS does not automatically trust BIOLOGY. Second, trust relationships are one-way. For instance, PHYSICS can trust GEOLOGY without GEOLOGY trusting PHYSICS. To enable two-way trust relationships, you must configure each domain to trust the other.

To configure interdomain trusts, each domain must first be properly configured in its own right. The first domain is the trusting domain, which hosts resources that should be accessible to the other domain, which is the trusted domain. For instance, suppose that PHYSICS has a wide-carriage printer to which users of GEOLOGY should have access. PHYSICS is then the trusting domain and GEOLOGY is the trusted domain. To begin configuring a trust relationship, you must first create both Linux and Samba accounts on the trusting domain (PHYSICS) for the trusted domain (GEOLOGY):

# useradd -d /dev/null -M -g trust -s /bin/false geology$
# smbpasswd -a -i geology

Note that you must include a trailing dollar sign ($) when creating the Linux account with useradd but not when creating the Samba account with smbpasswd. The smbpasswd command prompts you to enter a password for the interdomain trust account. Remember this password, because you will need to enter it again shortly. The GEOLOGY domain controller will use this account, much as if the trusted domain controller were an ordinary member of the trusting domain, to enable its own members to access PHYSICS resources.

With the interdomain trust account created on the trusting domain controller, you can now configure the trusted domain controller to use that account:

# net rpc trustdom establish physics

Type this command on a Linux member of the trusted domain (GEOLOGY, in this example). You will be asked for a password; enter the same one you typed for the smbpasswd command on the trusting domain. If all goes well, members of GEOLOGY will now be able to access the servers on PHYSICS. If you want to establish a two-way trust, you must repeat these steps, reversing the roles of the two domains.

If you want to terminate an interdomain trust, you can do so on the trusted domain:

# net rpc trustdom revoke physics

Alternatively, you can type the following command on the trusting domain:

# net rpc trustdom del geology

Back to top

Moving forward

The next topic in this series, LPIC-3 objective 312.5, covers the Samba Web Administration Tool, which enables web-based configuration of Samba.

Resources

Learn

• LDAP-based authentication for Samba (Keith Robertson, developerWorks, January 2006) describes how to configure Samba and LDAP in more detail than can be presented here.
  
  
• The Backup Domain Control chapter of the official Samba documentation provides much more detail about this topic.
  
  
• The Samba net command documentation includes information on managing interdomain trusts.
  
  
• 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 and the tasks and sample questions.
  
  
• 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.
  
  
• Exam Preparation Resources for Revised LPIC Exams provides a list of other certification training resources maintained by LPI.
  
  
• 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.
  
  
• 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.
  
  
• Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
  
  

Get products and technologies

• Download the Win7_Samba3DomainMember.reg file that's required to join a Windows 7 computer to a Samba domain.
  
  
• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  
  

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

Roderick W. Smith is a consultant and author of over a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He is also the author of the GPT fdisk partitioning software. He currently resides in Woonsocket, Rhode Island.

Rate this article

Comments

Back to top

Table of contents

• Overview
• Prerequisites
• Setting basic domain features
• Creating domain shares and user settings
• Configuring a backup domain controller
• Setting up interdomain trusts
• Moving forward
• Resources
• About the author
• Comments

Dig deeper into Linux on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers