If you have a conventional NT4-style domain instead of an Active Directory domain, Samba can still serve as a domain controller. The Samba server can assume different roles that the administrator must clearly understand: It can be configured as a primary domain controller (PDC), a backup domain controller (BDC), or a file server.

When planning a Samba environment, the passdb back end is critical. Three types of database back ends store user information:

• The smbpasswd back end is an ASCII text file that contains all the user information. This back end should not be used any longer because it has several drawbacks (e.g., only write access is possible simultaneously).
• The tdbsam back end is the default after installing Samba and is certainly sufficient if only one PDC is set up with no more than 250 users to manage. Because replication to another server is not so easy, implementing a BDC is also quite complicated and uncertain.
• The ldapsam back end is not subject to size limitations, and you can set up any number of BDCs. However, you definitely need an LDAP infrastructure. On a positive note, the back end is so flexible that even Linux and OS X clients can handle authentication centrally.

In this article, I will look at the tdbsam back end, returning at the end to explain what changes are needed to run a PDC and a BDC together with an LDAP server.

PDC Settings

The entire configuration of the Samba server always resides in the /etc/samba/smb.conf file. To configure Samba as a PDC, you need the settings from Listing 1. In addition to these parameters, you might also want to enter the first shares. The NetBIOS name of the Windows domain, which is defined by workgroup **= ADMINDOM is an important parameter.

[global]
  workgroup = ADMINDOM
  server string = \%h Samba Admin-Magazin
  netbios name = Admin-Magazin
  domain master = yes
  domain logons = yes
  os level = 99

The server string = \%h Samba Admin-Magazin parameter generates a comment in the network environment of the Windows clients. The variable %h assumes the NetBIOS name of the PDC, which the netbios name **= Admin-Magazin entry sets. If this parameter is not set, the hostname of the Linux system is used as the NetBIOS name. The domain master = yes parameter ensures that the Samba server acts as a PDC. If you set this value to no, the Samba server would act as a BDC.

The domain logons = yes parameter lets users log in and must be set to yes on both the PDC and the BDC. The os level = 99 parameter sets the priority of the Samba server when selecting the master browser in the domain. With a value of 99, the Samba server wins and thus always acts as the master browser. After completing the entries in the smb.conf file, you should always examine the file for syntax errors. To do this, run the testparm command as shown in Listing 2.

root@samba:~# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions
[global]
workgroup = ADMINDOM
    netbios name = ADMIN-MAGAZIN
    server string = \%h Samba Admin-Magazin
    domain logons = Yes
    os level = 99
    domain master = yes

The process in Listing 2 shows all the parameters as well as any syntax errors. The message referring to rlimit_max:... indicates that the value 1024 is too low and was replaced with something bigger. Although you can simply ignore this message, you can get rid of it permanently, too [1]. The output from testparm also shows that the Samba server has assumed the role of the PDC.

This completes the basic configuration of the PDC. The next step involves creating the conditions for operation as a domain controller.

Besides the option of adding the parameters directly to the smb.conf file with your favorite editor, Samba also includes the web-based SWAT tool. If you use this tool, then the entire configuration can take place in a web interface.

If you have the samba-doc package installed in addition to SWAT, help is available for each parameter. SWAT includes its own web server, but it cannot be started autonomously. SWAT relies on xinetd to start, which in turn means having a suitable configuration file stored in the /etc/xinetd.d directory (Listing 3).

service swat
{
   port = 901
   socket_type = stream
   wait = no
   only_from = 192.168.123.2
   user = root
   server = /usr/sbin/swat
   log_on_failure += USERID
   disable = no

To match your own environment. or to remove it from the configuration, you need to adapt the only_from parameter. This parameter controls access to SWAT. After restarting xinetd, you can reach SWAT on http://IP-of-Samba-Server:901 . Figure 1 shows the global section of smb.conf.

Figure 1: Viewing global parameters in SWAT.

Creating Groups

In the Windows world, certain groups are needed to manage a domain. Table 1 shows an overview of all the existing groups.

Three groups must be created. The Domain Computers group is not strictly necessary, but you need it to manage machine accounts in Samba later. The important information about groups is not the name but the RID (relative identifier).

The RID makes the group unique in the domain and is always appended to the SID of the domain for every object. The SID for a domain can be viewed with the net getlocalsid command. The Domain Admins and Domain Users groups are particularly important, because they are added to the appropriate local groups on the client later when you add a client to the domain. The RID is used for this association.

The first three lines of Table 1 are the groups required for the domain. The second part lists the built-in groups, which are local groups in the Windows system that are valid only on one system. You need to create these groups whether the Samba server is a member of a Windows domain or Active Directory. To create these groups, it is essential to configure and launch winbind.

Group mappings always exist for the domain groups, and a group mapping always points to an existing Linux group, establishing a connection between the Linux and Windows worlds. Creating a group mapping therefore comprises two steps: creating the Linux group and mapping. Listing 4 shows the process of creating a group mapping for the Domainadmins group.

root@samba:~# groupadd domadmins
root@samba:~# net groupmap add ntgroup="Domainadmins" rid=512
unixgroup=domadmins type=d
Successfully added group Domainadmins to the mapping db as a domain group
root@samba:~# net groupmap list verbose
Domainadmins
    SID       : S-1-5-21-2851015207-2192045402-886076809-512
    Unix gid  : 1001
    Unix group: domadmins
    Group type: Domain Group
    Comment   : Domain Unix group

The first step creates a Linux group. The GID assigned here is not important. The group mapping is added in the second step. Here, a RID of 512 was assigned to the group to identify clearly the domain administrator group on the Windows system. Finally, you can display the list of all group mappings by typing

groupmap list verbose

which shows that the group SID is composed of the domain SID and the RID.

Next, you need to create all the other required groups, which will always include Domainusers, Domainguests, and Domaincomputers with the corresponding RIDs (the results are shown in Listing 5). Only then you can proceed to set up the domain. Later, you can create more group mappings (e.g., global groups for assigning rights on Windows systems). Because the system determines RIDs automatically, you do not need to specify them.

root@samba:~# net groupmap list verbose
Domaincomputer
    SID       : S-1-5-21-2851015207-2192045402-886076809-515
    Unix gid  : 1004
    Unix group: domcomputer
    Group type: Domain Group
    Comment   : Domain Unix group
Domainadmins
    SID       : S-1-5-21-2851015207-2192045402-886076809-512
    Unix gid  : 1001
    Unix group: domadmins
    Group type: Domain Group
    Comment   : Domain Unix group
Domainusers
    SID       : S-1-5-21-2851015207-2192045402-886076809-513
    Unix gid  : 1002
    Unix group: domusers
    Group type: Domain Group
    Comment   : Domain Unix group
Domainguests
    SID       : S-1-5-21-2851015207-2192045402-886076809-514
    Unix gid  : 1003
    Unix group: domguests
    Group type: Domain Group
    Comment   : Domain Unix group

Setting Up a Domain Administrator

Nothing works in a Windows domain without the domain administrator, who in turn requires certain privileges that grant certain rights on the system, such as the right to add clients to the domain. An overview of all the privileges is shown in Table 2.

The list of privileges can also be viewed by issuing the

rpcclient localhost -U% -c enumprivs

command on the Samba server.

On one hand, the domain administrator needs at least SeMachineAccountPrivilege; on the other hand, only a member of the Domain Administrators group can grant privileges. This means domain administrators must assign themselves this privilege. Listing 6 shows how a domain administrator would go about this.

root@samba:~# useradd -g domadmins -G users -m -s /bin/bash administrator
root@samba:~# passwd administrator
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@samba:~# pdbedit -a -u administrator -G 512 -c "[UX]"
new password:
retype new password:
Unix username:        administrator
NT username:
Account Flags:        [U     ]
User SID:             S-1-5-21-2851015207-2192045402-886076809-1000
Primary Group SID:    S-1-5-21-2851015207-2192045402-886076809-512
Full Name:
Home Directory:       \\admin-magazin\administrator
HomeDir Drive:
Logon Script:
Profile Path:         \\admin-magazin\administrator\profile
Domain:               ADMINDOM
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          9223372036854775807 seconds since the Epoch
Kickoff time:         9223372036854775807 seconds since the Epoch
Password last set:    Thu, 03 Jan 2013 13:07:54 CET
Password can change:  Thu, 03 Jan 2013 13:07:54 CET
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
root@samba:~# su - administrator
administrator@samba:/root$ net rpc rights grant ADMINDOM\\administrator SeMachineAccountPrivilege -S localhost
Enter administrator's password:
Successfully granted rights.
administrator@samba:/root$ net rpc rights list ADMINDOM\\administrator
Enter administrator's password:
SeMachineAccountPrivilege

The first step creates the corresponding Linux user; you must always have a Linux user for the Samba user, as with the group mappings. Whether the administrator is given a Linux password depends on whether the administrator needs to log in to the Linux system later. If this is not desired, a Linux password is not needed.

In the second step, the Samba user is created with the

pdbedit -a -u administrator -G 512 -c "[UX]"

command. It is important to stipulate -G 512 for the Domainadmins group as the primary group. The flags [UX] stipulate that the user (U) and password never expires (X). The third step,

su - administrator

lets you assume the identity of the user administrator, then SeMachineAccountPrivilege is assigned to this user. Now you have a domain administrator who can add clients to the domain later.