Cost Control

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.

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.

Setting Up Users in the Domain

Once all of the prerequisites for operating a domain are met, you can start to set up the groups and users. For groups, admins need to consider the following:

• Will the group only be used for granting privileges on this host? If so, you need only set up a Linux group to hold the Linux users.
• Will the group be used to gather users and then set permissions on another file server in the domain? It does not matter whether it is another Samba server or a Windows server, you must create a group mapping. All other group mappings can be created, like the domain groups that were set up to prepare the domain, except you do not need to specify the RID; it is automatically assigned.

You can create all other users with pdbedit (as in the example with the domain administrator). All the parameters and their descriptions are excellently explained in the man page for the pdbedit command. Listing 7 shows how to create a user and a group mapping. The user settings can be changed with parameters when creating the accounts.

root@samba:~# groupadd authors
root@samba:~# net groupmap add ntgroup="authors" unixgroup=authors type=d
No rid or sid specified, choosing a RID
Got RID 1001
Successfully added group authors to the mapping db as a domain group
root@samba:~# useradd -g domusers -G authors -m -s /bin/bash skania
root@samba:~# useradd -g domusers -G authors -m -s /bin/bash skania
root@samba:~# pdbedit -a -u skania -G 513 -c "[U]" -f "Stefan Kania"
new password:
retype new password:
Unix username:        skania
NT username:
Account Flags:        [U     ]
User SID:             S-1-5-21-2851015207-2192045402-886076809-1002
Primary Group SID:    S-1-5-21-2851015207-2192045402-886076809-513
Full Name:            Stefan Kania
Home Directory:       \\admin-magazine\skania
HomeDir Drive:
Logon Script:
Profile Path:         \\admin-magazine\skania\profiles
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:    Fri, 04 Jan 2013 11:14:33 CET
Password can change:  Fri, 04 Jan 2013 11:14:33 CET
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

This time, the name of the Linux group and the name of the group mapping are identical and will not cause problems. Also, the RID is not predetermined but assigned automatically. The Linux user has not been assigned a password because, later, this user will not be logging on to the Linux system, just a Windows client in the domain. Following this pattern, you can now create new groups and users.

The group memberships of the users are always managed in the Linux group; the group mapping ensures that the members are also known on the Windows system in the domain.

Clients in the Domain

To add Windows clients to a domain, an account must exist for every Windows client in the domain. This account must always use the NetBIOS name of the Windows client. The account can be created either manually for each host or automatically by a script when adding a client to the domain. If you want to create the accounts manually, follow the procedure in Listing 8.

root@samba:/# useradd -g domcomputer -s /bin/false 'win7$'
root@samba:/# pdbedit -a -m win7 -G 515 -c "[UW]" -p "" -h""
Unix username:        win7$
NT username:
Account Flags:        [W     ]
User SID:             S-1-5-21-2851015207-2192045402-886076809-1009
Primary Group SID:    S-1-5-21-2851015207-2192045402-886076809-515
Full Name:
Home Directory:
HomeDir Drive:
Logon Script:
Profile Path:
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:    Sat, 05 Jan 2013 13:00:47 CET
Password can change:  Sat, 05 Jan 2013 13:00:47 CET
Password must change: never
Last bad Password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

The first step generates a Linux account for the client, as was previously done for a user. The dollar sign after the name is important because it distinguishes a client account from a user account. The second step is to run pdbedit to create the Samba account. Setting the group RID to 515 and the flags to [UW] tells Windows that this is a client account.

The other way to create client accounts is through a script that runs while joining a client to the domain. The script is inserted into the [global] section of smb.conf:

add machine script = /usr/sbin/useradd -d /var/lib/nobody -g domcomputer -s /bin/2 Ptfalse -M %u

The Samba server then sets up the required accounts autonomously. After joining the domain, the accounts can also be listed with getent passwd and pdbedit -L. Incidentally, if you want to join Windows 7 clients to the domain, you will need to patch the registry beforehand [2].

After creating the client account, you can join the client to the domain in the usual way. Figure 2 shows this process. A while after entering the username and password, you will see the message Welcome to the ADMINDOM domain. After restarting the system, Samba users can log in.

Centrally Managed Home Directories

A special Samba share for managing user directories automatically creates a home directory on the server for each user. Additionally, you can specify the drive letter, under which the user directory appears in Explorer.

First, you have to add the share to your smb.conf. The share name must be [homes] so that Samba can assign home directories. As you can see in Listing 9, no path to a specific directory is specified for the share. This is because Samba determines the user information independently and then shares the path for the user. In the example here, other parameters are used to ensure that only the new owner has rights to new entries and that they cannot assign rights to others.

[homes]
  comment = user home directories
  read only = no
  valid users = %S
  force create mode = 0700
  security mask = 0700
  force directory mode = 0700
  directory security mask = 0700
  inherit owner = yes

To view the user's account properties, you can then type:

pdbedit -v -L user

The Home Directory parameter already points to the relevant share on the server. The only thing missing is the parameter for Home Drive, which you can use to set the drive letter for the user directory. This parameter is set by the

pdbedit -D "H:" user

command. Now when users log in to the domain on a client, Explorer automatically takes them to their home directory and displays the directory content.

Roaming Profiles

Besides centralized management of home directories, management of the roaming profiles is another important task in user management. To manage the user profiles centrally, you must first check to see whether the filesystem on which the profiles reside supports access control lists (ACLs). Roaming profiles do not work without ACLs. On SUSE, all filesystems created by the installer have ACLs activated. On Debian and Ubuntu, you need to set this parameter in the /etc/fstab file, using:

UUID=ea1552d5-9756-4b13-9b1d-7e197e16e4b8/ ext3 errors=remount-ro,acl 0 1

and remount the filesystem with:

root@samba:~# mount -o remount,rw /

You should then be able to see the activated ACLs after typing mount.

It makes sense to mount all filesystems that need to be accessed via Windows with the acl option; in this case, a Windows client can later change the filesystem rights in the domain using Explorer.

When you create the directory for the profile share, be sure to set the rights so that others have all rights; otherwise, you cannot create the directory for the profile when the user logs in for the first time. Now all you need is a share for the profiles and to modify the users. The following configuration snippet shows the entry for the share in the smb.conf file:

[profile]
  comment = profile dir for users
  path = /profile
  browsable = no
  read only = no
  profile acls = yes

The profile acls = yes parameter is important in this share; Windows needs to set specific ACLs when creating the profile directory to be able to control exclusive access to the profile. If you now use the

pdbedit -p '\\admin-magazin\profile\user' user

command to modify the entry in the database, users can store their profiles centrally. New users are automatically assigned the right profile directory thanks to the -p parameter.

As in Windows, you can set account policies in a Samba domain to enhance password security. Policies here need to be edited, again using the pdbedit command (Listing 10 shows the changes to the values).

root@samba:/# pdbedit -P "maximum password age" -C 7776000
account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
account policy "maximum password age" value was: 4294967295
account policy "maximum password age" value is now: 7776000
root@samba:/# pdbedit -P "min password length" -C 5
account policy "min password length" description: Minimal password length (default: 5)
account policy "min password length" value was: 5
account policy "min password length" value is now: 5
root@samba:/# pdbedit -P "password history" -C 20
account policy "password history" description: Length of Password History Entries (default: 0 => off)
account policy "password history" value was: 0
account policy "password history" value is now: 20
root@samba:/# pdbedit -P "bad lockout attempt" -C 3
account policy "bad lockout attempt" description: Lockout users after bad logon attempts (default: 0 => off)
account policy "bad lockout attempt" value was: 0
account policy "bad lockout attempt" value is now: 3
root@samba:/# pdbedit -P "lockout duration" -C 180
account policy "lockout duration" description: Lockout duration in minutes (default: 30, -1 => forever)
account policy "lockout duration" value was: 30
account policy "lockout duration" value is now: 180

Of course, you can also use logon scripts in a Samba domain. To do this, create a batch file in the usual Windows style with the appropriate commands. It makes sense to create the batch file in Windows to be sure you have the right line-ending encoding. Then you need to create a share as in Listing 11 and copy the batch file to the share.

[NETLOGON]
  comment = Netlogon share
  path = /netlogon
  readonly = yes
  write list = administrator
  browsable = no

The share is read-only; only the domain administrator has explicit write permission, but users must have read and execute rights for the directory and the batch files.

Assigning the batch script to the users can be done in one of two ways. In the first case, you use the same script for all users; set this up in the [global] section using the logon script = <scriptname>.bat parameter – with the file name but without a path because the logon script will search relative to the Netlogon share. The second approach is to give each user a separate logon script. The pdbedit command does this:

pdbedit -S '\\admin-magazine\netlogon\<scriptname>.bat' <user>

but this time the full path is required.

Configuring Winbind

Up to this point, the PDC has been on its own in the domain with no other Windows or Samba server. If you will be adding another Samba or Windows server to the domain later on, or if you want to use the nested groups from the next section, then the winbind service is a must have.

Winbind is a standalone service but part of Samba. Once winbind is used, you will definitely need to stop the Name Service Caching Daemon (nscd) because the two services do not mix. On Debian and Ubuntu, Winbind is a separate package. To configure Winbind, modify the [global] section in smb.conf as follows:

[global]
  winbind separator = +
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  winbind enum users = yes
  winbind enum groups = yes
  winbind use default domain = yes

The parameters idmap uid and idmap gid serve to map the user and group IDs belonging to Windows users to Linux IDs.

Thanks to the winbind enum users and winbind enum groups parameters, the users and groups are then visible on the system when you type getent passwd and getent group and can be used to assign rights on the Linux system.

Toppings

Normally the users and groups that winbind integrates from a Windows system or from another Samba server are shown in the form of <domain>/<user>.

However, on Linux, you cannot use the forward slash (/) in this way because it is the path separator. Thus, it makes sense to replace the forward slash using the winbind separator **= **+ parameter. When you then run testparm to check the syntax, the warning 'winbind separator  =  +' might cause problems with group membership message appears. This warning is only relevant if you still use NIS.

If you have one domain on the network, instead of the winbind separator parameter, you use the winbind use default domain = yes parameter. Then the domain part of the user and group name is truncated, and the way these names are displayed on the system is identical to that for local users and groups.

In this case, it is important to ensure that the names are unique and do not exist both in the domain and locally. If multiple domains are used or if trusts to other domains exist, this parameter cannot be used because users are otherwise not unambiguously assigned to a domain.

Nested Groups

On Windows, it is common to collect users on the domain controller in a group and then assign this group to a local group on a file server. The local groups are then granted filesystem permissions. This also works with Samba; the procedure is known as nested groups. To use it, you must have a domain and Winbind must be configured. The steps also include modifying the /etc/nsswitch.conf file as follows:

passwd:    compat winbind
group:     compat winbind

In the [global] section of your smb.conf file, add winbind nested groups **= yes. Afterwards, you can set up nested groups (Listing 12). All of these steps are the responsibility of the domain administrator.

root@samba:~# net rpc group add localgroup -L -Uadministrator
Enter administrator's password:
Added alias 'localgroup'.
root@samba:~# net rpc group addmem localgroup domainusers -Uadministrator
Enter administrator's password:
root@samba:~# net rpc group members localgroup -Uadministrator
Enter administrator's password:
ADMINDOM\Domainusers

The first step uses the -L parameter to create a local group to which the domain groups are then added as members. The second step adds the domainusers group as a member of the localgroup. The third step checks the success. Now, when you assign rights for the filesystem to the local group, all members of the domainusers group also inherit this right for the filesystem. Because Linux does not support nested groups, getent group or wbinfo -g does not show the local group. All actions concerning the group need the net rpc group command.

An LDAPsam Back End

As promised, I will now look at configuring LDAP as a passdb back end. This undertaking requires a working LDAP server with the samba.schema in place because, in addition to POSIX attributes, you also need to create Samba attributes for the users.

The great benefit of using LDAP is that the users and groups only need to be created once. For user management, you can then use the smbldap-tools script collection [3] or do things graphically with the LDAP Account Manager [4], a web-based tool. Listing 13 shows how to modify the [global] section for the use of LDAP on both the PDC and all BDCs.

  passdb backend = ldapsam:ldap://samba.example.net
  ldap admin dn = cn=admin,dc=example,dc=net
  ldap suffix = dc=example,dc=net
  ldap group suffix = ou=groups
  ldap machine suffix = ou=hosts
  ldap user suffix = ou=users
  ldap passwd sync = yes
  ldap ssl = no

Samba now uses LDAP as the passdb back end. To also allow Samba to add the objects to LDAP, you need to add the password for the LDAP administrator to the secrets.tdb file. The command for this is smbpasswd -W. Samba will then create an LDAP object for the Samba domain. From this time on, Samba uses the LDAP server for user management.

The Future

Following the December release of version 4 of Samba, many things changed. Besides setting up Primary or Backup Domain Controllers, you can now also create Active Directory domain controllers, and you can set up Samba 4 as an additional AD controller. It is even possible to set up an entire Active Directory forest without the use of a Windows domain controller by Microsoft with Samba 4's own LDAP server that manages all the objects.

User and group management can also be handled with the Microsoft Windows Remote Server Administration Tools. You will need a Windows 7 machine to run the tools, but the software can be downloaded free of charge [5].