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.