« Previous 1 2 3 4 Next »
Save money with Samba as the domain controller on a legacy Windows NT-style domain
Cost Control
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).
Listing 10
Account Policies
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.
Listing 11
Netlogon 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.
« Previous 1 2 3 4 Next »