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.
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.
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:
workgroupoption sets the Windows NT domain name. A domain is just a workgroup with extra features.
securityoption must be set to
encrypt passwordsoption must be set to
passdb backendoption 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.
domain logonsoption must be set to
admin usersoption 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
smbpasswd commands to create these accounts, as
# 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
-g trust), and setting the default shell to
-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
If you created a new user for the
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:
- 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.
- Open the Control Panel System and Security item.
- Click System.
- Click Change Settings under the Computer
Name, Domain, and Workgroup Settings heading.
Windows opens a system properties window.
- 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
- Select the Domain option, and then type your domain name in the text box.
- 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
- 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
ntadmin to the user name you've chosen
for your administrative account. The program prompts for a password; enter
the password associated with the
If all goes well, you'll see a message that you've joined the domain that
you've specified via the
workgroup option in
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.
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.
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.
Table 1. Values of the %a variable
|Value||Type of client|
|Linux Common Internet File System (CIFS) file system|
|IBM® Operating System/2® (OS/2)|
|Windows for Workgroups|
|Windows 95, 98, or Me|
|Microsoft Windows 2000|
|Windows XP 64 bit|
|Windows Server® 2003|
|Windows Vista or Windows 7|
|Any other client|
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 = \\%L\PROFILES\%U
This example uses the
%L variable (the NetBIOS
name of the current server) and the
(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.
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
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:
net rpc getsidon the BDC computer.
This command retrieves a critical identifier that must match on the PDC and BDC computers.
smbpasswd -w mypasson the BDC, where
mypassis the LDAP administrative password.
- 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.
- 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.
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
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
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
The next topic in this series, LPIC-3 objective 312.5, covers the Samba Web Administration Tool, which enables web-based configuration of Samba.
- 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
netcommand 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.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.