LPI 302: Mixed Environments

In this document you find information for the different objectives from the LPIC 302 exam. Before using this document you should check on the LPI site if the objectives are still the same. This document is provided as an aid in studying and is in noway a guaranty for passing the exam. Try to gain some practical knowledge (go configure a Samba server) and really understand the concepts how things work, that should help.

Topic 310: Concepts, Architecture and Design

310.1 Concepts (weight: 1)

Description:Candidates should be familiar with the fundamental concepts surrounding SMB/CIFS, file sharing and print services in a mixed environment

Key Knowledge Areas

  • Understand SMB/CIFS concepts
  • Understand file sharing concepts
  • Understand print services concepts

The following is a partial list of the used files, terms and utilities:

  • SMB
  • CIFS
  • smb.conf

SMB

Server Message Block (SMB) is an application-level network protocol mainly applied to shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated Inter-process communication mechanism. It is mainly used by Microsoft Windows equipped computers, where it's known simply as “Microsoft Windows Network”.

More information

CIFS

Microsoft and a group of other vendors (Digital Equipment, Data General, SCO, Network Appliance Corp, etc) are engaged in developing a public version of the SMB protocol. It is expected that CIFS 1.0 will be essentially NT LM 0.12 with some modifications for easier use over the Internet.

smb.conf

Main samba configuration file. Example

310.2 Samba Roles (weight: 1)

Description:Candidates should be aware of Samba's security modes, and the keys roles of the Samba daemons

Key Knowledge Areas

  • Understand Samba security modes
  • Identify roles of core Samba daemons
  • Manage Samba daemons

The following is a partial list of the used files, terms and utilities:

  • User Level Security
  • Share Level Security
  • Domain Security Mode
  • ADS Security Mode
  • smb.conf
  • smbd
  • nmbd
  • winbindd
  • smbcontrol

User Level Security

User-level security is the default setting for Samba. Even if the security = user directive is not listed in the smb.conf file, it is used by Samba. If the server accepts the client's username/password, the client can then mount multiple shares without specifying a password for each instance. Samba can also accept session-based username/password requests. The client maintains multiple authentication contexts by using a unique UID for each logon

[GLOBAL]
...
security = user
...

Share Level Security

With share-level security, the server accepts only a password without an explicit username from the client. The server expects a password for each share, independent of the username. There have been recent reports that Microsoft Windows clients have compatibility issues with share-level security servers. Samba developers strongly discourage use of share-level security.

[GLOBAL]
...
security = share
...

Domain Security Mode

In domain security mode, the Samba server has a machine account (domain security trust account) and causes all authentication requests to be passed through to the domain controllers.

[GLOBAL]
...
security = domain
workgroup = MARKETING
...

ADS Security Mode

If you have an Active Directory environment, it is possible to join the domain as a native Active Directory member. Even if a security policy restricts the use of NT-compatible authentication protocols, the Samba server can join an ADS using Kerberos. Samba in Active Directory member mode can accept Kerberos tickets.

[GLOBAL]
...
security = ADS
realm = EXAMPLE.COM
password server = kerberos.example.com 
...

smbd

smbd - server to provide SMB/CIFS services to clients

smbd is the server daemon that provides filesharing and printing services to Windows clients. The server provides filespace and printer services to clients using the SMB (or CIFS) protocol. his is compatible with the LanManager protocol, and can service LanManager clients.

-DIf specified, this parameter causes the server to operate as a daemon. That is, it detaches itself and runs in the background, fielding requests on the appropriate port. Operating the server as a daemon is the recommended way of running smbd for servers that provide more than casual use file and print services. This switch is assumed if smbd is executed on the command line of a shell.
-FIf specified, this parameter causes the main smbd process to not daemonize, i.e. double-fork and disassociate with the terminal. Child processes are still created as normal to service each connection request, but the main process does not exit. This operation mode is suitable for running smbd under process supervisors such as supervise and svscan from Daniel J. Bernstein's daemontools package, or the AIX process monitor.
-SIf specified, this parameter causes smbd to log to standard output rather than a file.
-iIf this parameter is specified it causes the server to run “interactively”, not as a daemon, even if the server is executed on the command line of a shell. Setting this parameter negates the implicit deamon mode when run from the command line. smbd also logs to standard output, as if the -S parameter had been given.
-VPrints the program version number.
-s <configuration file>The file specified contains the configuration details required by the server. The information in this file includes server-specific information such as what printcap file to use, as well as descriptions of all the services that the server is to provide. See smb.conf for more information. The default configuration file name is determined at compile time.
-d/–debuglevel=levellevel is an integer from 0 to 10. The default value if this parameter is not specified is zero. The higher this value, the more detail will be logged to the log files about the activities of the server. At level 0, only critical errors and serious warnings will be logged. Level 1 is a reasonable level for day-to-day running - it generates a small amount of information about operations carried out. Levels above 1 will generate considerable amounts of log data, and should only be used when investigating a problem. Levels above 3 are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic. Note that specifying this parameter here will override the parameter in the smb.conf file.
-l/–logfile=logdirectoryBase directory name for log/debug files. The extension ”.progname” will be appended (e.g. log.smbclient, log.smbd, etc…). The log file is never removed by the client.
-h/–helpPrint a summary of command line options.
-p/–port<port number(s)>port number(s) is a space or comma-separated list of TCP ports smbd should listen on. The default value is taken from the ports parameter in smb.conf. The default ports are 139 (used for SMB over NetBIOS over TCP) and port 445 (used for plain SMB over TCP).
-P/–profiling-level<profiling level>profiling level is a number specifying the level of profiling data to be collected. 0 turns off profiling, 1 turns on counter profiling only, 2 turns on complete profiling, and 3 resets all profiling data.

nmbd

nmbd - NetBIOS name server to provide NetBIOS over IP naming services to clients

nmbd is a server that understands and can reply to NetBIOS over IP name service requests, like those produced by SMB/CIFS clients such as Windows 95/98/ME, Windows NT, Windows 2000, Windows XP and LanManager clients. It also participates in the browsing protocols which make up the Windows “Network Neighborhood” view. SMB/CIFS clients, when they start up, may wish to locate an SMB/CIFS server. That is, they wish to know what IP number a specified host is using.

-DIf specified, this parameter causes nmbd to operate as a daemon. That is, it detaches itself and runs in the background, fielding requests on the appropriate port. By default, nmbd will operate as a daemon if launched from a command shell. nmbd can also be operated from the inetd meta-daemon, although this is not recommended.
-FIf specified, this parameter causes the main nmbd process to not daemonize, i.e. double-fork and disassociate with the terminal. Child processes are still created as normal to service each connection request, but the main process does not exit. This operation mode is suitable for running nmbd under process supervisors such as supervise and svscan from Daniel J. Bernstein's daemontools package, or the AIX process monitor.
-SIf specified, this parameter causes nmbd to log to standard output rather than a file.
-iIf this parameter is specified it causes the server to run “interactively”, not as a daemon, even if the server is executed on the command line of a shell. Setting this parameter negates the implicit daemon mode when run from the command line. nmbd also logs to standard output, as if the -S parameter had been given.
-h/–helpPrint a summary of command line options.
-H <filename>NetBIOS lmhosts file. The lmhosts file is a list of NetBIOS names to IP addresses that is loaded by the nmbd server and used via the name resolution mechanism name resolve order described in smb.conf(5) to resolve any NetBIOS name queries needed by the server. Note that the contents of this file are NOT used by nmbd to answer any name queries. Adding a line to this file affects name NetBIOS resolution from this host ONLY. The default path to this file is compiled into Samba as part of the build process. Common defaults are /usr/local/samba/lib/lmhosts, /usr/samba/lib/lmhosts or /etc/samba/lmhosts. See the lmhosts(5) man page for details on the contents of this file.
-VPrints the program version number.
-s <configuration file>The file specified contains the configuration details required by the server. The information in this file includes server-specific information such as what printcap file to use, as well as descriptions of all the services that the server is to provide. See smb.conf for more information. The default configuration file name is determined at compile time.
-d/–debuglevel=levellevel is an integer from 0 to 10. The default value if this parameter is not specified is zero. The higher this value, the more detail will be logged to the log files about the activities of the server. At level 0, only critical errors and serious warnings will be logged. Level 1 is a reasonable level for day-to-day running - it generates a small amount of information about operations carried out. Levels above 1 will generate considerable amounts of log data, and should only be used when investigating a problem. Levels above 3 are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic. Note that specifying this parameter here will override the parameter in the smb.conf file.
-l/–logfile=logdirectoryBase directory name for log/debug files. The extension ”.progname” will be appended (e.g. log.smbclient, log.smbd, etc…). The log file is never removed by the client.
-p <UDP port number>UDP port number is a positive integer value. This option changes the default UDP port number (normally 137) that nmbd responds to name queries on. Don't use this option unless you are an expert, in which case you won't need help!

winbindd

winbindd — Name Service Switch daemon for resolving names from NT servers

winbindd is a daemon that provides a number of services to the Name Service Switch capability found in most modern C libraries, to arbitrary applications via PAM and ntlm_auth and to Samba itself.

Even if winbind is not used for nsswitch, it still provides a service to smbd, ntlm_auth and the pam_winbind.so PAM module, by managing connections to domain controllers. In this configuraiton the idmap uid and idmap gid parameters are not required. (This is known as `netlogon proxy only mode'.)

The Name Service Switch allows user and system information to be obtained from different databases services such as NIS or DNS. The exact behaviour can be configured throught the /etc/nsswitch.conf file. Users and groups are allocated as they are resolved to a range of user and group ids specified by the administrator of the Samba system.

The service provided by winbindd is called `winbind' and can be used to resolve user and group information from a Windows NT server. The service can also provide authentication services via an associated PAM module.

-DIf specified, this parameter causes the server to operate as a daemon. That is, it detaches itself and runs in the background on the appropriate port. This switch is assumed if winbindd is executed on the command line of a shell.
hostsThis feature is only available on IRIX. User information traditionally stored in the hosts(5) file and used by gethostbyname(3) functions. Names are resolved through the WINS server or by broadcast.
passwdUser information traditionally stored in the passwd(5) file and used by getpwent(3) functions.
groupGroup information traditionally stored in the group(5) file and used by getgrent(3) functions.

For example, the following simple configuration in the /etc/nsswitch.conf file can be used to initially resolve user and group information from /etc/passwd and /etc/group and then from the Windows NT server.

passwd:         files winbind
group:          files winbind
## only available on IRIX; Linux users should us libnss_wins.so
hosts:          files dns winbind

The following simple configuration in the /etc/nsswitch.conf file can be used to initially resolve hostnames from /etc/hosts and then from the WINS server.

hosts:		files wins

smbcontrol

smbcontrol - send messages to smbd, nmbd or winbindd processes

smbcontrol is a very small program, which sends messages to a smbd(8), a nmbd(8), or a winbindd(8) daemon running on the system.

-h/–helpPrint a summary of command line options.
-s <configuration file>The file specified contains the configuration details required by the server. The information in this file includes server-specific information such as what printcap file to use, as well as descriptions of all the services that the server is to provide. See smb.conf for more information. The default configuration file name is determined at compile time.
-iRun interactively. Individual commands of the form destination message-type parameters can be entered on STDIN. An empty commandline or a “q” will quit the program.
destinationOne of nmbd, smbd or a process ID. The smbd destination causes the message to “broadcast” to all smbd daemons. The nmbd destination causes the message to be sent to the nmbd daemon specified in the nmbd.pid file. If a single process ID is given, the message is sent to only that process.
message-typeType of message to send. See the section MESSAGE-TYPES for details.
parametersany parameters required for the message-type

MESSAGE-TYPES

close-shareOrder smbd to close the client connections to the named share. Note that this doesn't affect client connections to any other shares. This message-type takes an argument of the share name for which client connections will be closed, or the “*” character which will close all currently open shares. This may be useful if you made changes to the access controls on the share. This message can only be sent to smbd.
debugSet debug level to the value specified by the parameter. This can be sent to any of the destinations.
force-electionThis message causes the nmbd daemon to force a new browse master election.
pingSend specified number of “ping” messages and wait for the same number of reply “pong” messages. This can be sent to any of the destinations.
profileChange profile settings of a daemon, based on the parameter. The parameter can be “on” to turn on profile stats collection, “off” to turn off profile stats collection, “count” to enable only collection of count stats (time stats are disabled), and “flush” to zero the current profile stats. This can be sent to any smbd or nmbd destinations.
debuglevelRequest debuglevel of a certain daemon and write it to stdout. This can be sent to any of the destinations.
profilelevelRequest profilelevel of a certain daemon and write it to stdout. This can be sent to any smbd or nmbd destinations.
printnotifyOrder smbd to send a printer notify message to any Windows NT clients connected to a printer. This message-type takes the following arguments:
queuepause printernameSend a queue pause change notify message to the printer specified.
queueresume printernameSend a queue resume change notify message for the printer specified.
jobpause printername unixjobidSend a job pause change notify message for the printer and unix jobid specified.
jobresume printername unixjobidSend a job resume change notify message for the printer and unix jobid specified.
jobdelete printername unixjobidSend a job delete change notify message for the printer and unix jobid specified.
Note that this message only sends notification that an event has occured. It doesn't actually cause the event to happen. This message can only be sent to smbd.
samsyncOrder smbd to synchronise sam database from PDC (being BDC). Can only be sent to smbd. Mat not work in all versions
samreplSend sam replication message, with specified serial. Can only be sent to smbd. Should not be used manually.
dmalloc-markSet a mark for dmalloc. Can be sent to both smbd and nmbd. Only available if samba is built with dmalloc support.
dmalloc-log-changedDump the pointers that have changed since the mark set by dmalloc-mark. Can be sent to both smbd and nmbd. Only available if samba is built with dmalloc support.
shutdownShut down specified daemon. Can be sent to both smbd and nmbd.
pool-usagePrint a human-readable description of all talloc(pool) memory usage by the specified daemon/process. Available for both smbd and nmbd.
drvupgradeForce clients of printers using specified driver to update their local version of the driver. Can only be sent to smbd.
reload-configForce daemon to reload smb.conf configuration file. Can be sent to smbd, nmbd, or winbindd.

310.3 Trivial Database Files (weight: 2)

Description: Candidates should understand the structure of trivial database files and know how to troubleshoot problems

Key Knowledge Areas

  • Backup TDB files
  • Restore TDB files
  • Identify TDB file corruption
  • Edit / list TDB file content

The following is a partial list of the used files, terms and utilities:

  • pdbedit
  • secrets.tdb
  • tdbbackup
  • tdbdump
  • tdbtool
  • smbpasswd

pdbedit

pdbedit - manage the SAM database (Database of Samba Users)

The pdbedit program is used to manage the users accounts stored in the sam database and can only be run by root. There are five main ways to use pdbedit: adding a user account, removing a user account, modifing a user account, listing user accounts, importing users accounts.

       -L
          This  option  lists  all the user accounts present in the users database. This option prints 
          a list of user/uid pairs separated by the ':' character.

          Example: pdbedit -L

          sorce:500:Simo Sorce
          samba:45:Test User

       -v
          This option enables the verbose listing format. It causes pdbedit to list the users in 
          the database, printing out the account fields in a descriptive format.

          Example: pdbedit -L -v

          ---------------
          username:       sorce
          user ID/Group:  500/500
          user RID/GRID:  2000/2001
          Full Name:      Simo Sorce
          Home Directory: \BERSERKERce
          HomeDir Drive:  H:
          Logon Script:   \BERSERKER0tlogonce.bat
          Profile Path:   \BERSERKERrofile
          ---------------
          username:       samba
          user ID/Group:  45/45
          user RID/GRID:  1090/1091
          Full Name:      Test User
          Home Directory: \BERSERKERba
          HomeDir Drive:
          Logon Script:
          Profile Path:   \BERSERKERrofile

       -w
          This option sets the "smbpasswd" listing format. It will make pdbedit list the users
          in the database,  printing  out  the  account fields in a format compatible with the 
          smbpasswd file format. (see the smbpasswd(5) for details)

          Example: pdbedit -L -w

          sorce:500:508818B733CE64BEAAD3B435B51404EE:
                    D2A2418EFC466A8A0F6B1DBB5C3DB80C:
                    [UX         ]:LCT-00000000:
          samba:45:0F2B255F7B67A7A9AAD3B435B51404EE:
                    BC281CE3F53B6A5146629CD4751D3490:
                    [UX         ]:LCT-3BFA1E8D:

       -u username
          This  option  specifies  the  username  to be used for the operation requested (listing, 
          adding, removing). It is required in add, remove and modify operations and optional in 
          list operations.

       -f fullname
          This option can be used while adding or modifing a user account. It will specify the 
          user's full name.

          Example: -f "Simo Sorce"

       -h homedir
          This option can be used while adding or modifing a user account. It will specify the 
          user's home directory network path.

          Example: -h "\\\\BERSERKER\\sorce"

       -D drive
          This option can be used while adding or modifing a user account. It will specify the 
          windows drive letter to be used to map the home directory.

          Example: -D "H:"

       -S script
          This option can be used while adding or modifing a user account. It will specify the 
          user's logon script path.

          Example: -S "\\\\BERSERKER\\netlogon\\sorce.bat"

       -p profile
          This option can be used while adding or modifing a user account. It will specify the user's 
          profile directory.

          Example: -p "\\\\BERSERKER\\netlogon"

       -G SID|rid
          This option can be used while adding or modifying a user account. It will specify the 
          users' new primary group SID (Security Identifier) or rid.

          Example: -G S-1-5-21-2447931902-1787058256-3961074038-1201

       -U SID|rid
          This option can be used while adding or modifying a user account. It will specify the 
          users' new SID (Security Identifier) or rid.

          Example: -U S-1-5-21-2447931902-1787058256-3961074038-5004

       -c account-control
          This  option  can  be used while adding or modifying a user account. It will specify the 
          users' account control property. Possible flags are listed below.

             N: No password required

             D: Account disabled

             H: Home directory required

             T: Temporary duplicate of other account

             U: Regular user account

             M: MNS logon user account

             W: Workstation Trust Account

             S: Server Trust Account

             L: Automatic Locking

             X: Password does not expire

             I: Domain Trust Account

             Example: -c "[X ]"

       -a
          This option is used to add a user into the database. This command needs a user name 
          specified with the -u switch.  When  adding a new user, pdbedit will also ask for 
          the password to be used.

          Example: pdbedit -a -u sorce

          new password:
          retype new password

          Note
          pdbedit  does not call the unix password syncronisation script if unix password sync has 
          been set. It only updates the data in the Samba user database.

          If you wish to add a user and synchronise the password that immediately, use smbpasswd's -a option.

       -t, --password-from-stdin
          This option causes pdbedit to read the password from standard input, rather than from 
          /dev/tty (like the passwd(1) program  does). The password has to be submitted twice 
          and terminated by a newline each.

       -r
          This option is used to modify an existing user in the database. This command needs a 
          user name specified with the -u switch. Other options can be specified to modify 
          the properties of the specified user. This flag is kept for backwards compatibility, 
          but it is no longer necessary to specify it.

      -m
          This  option  may only be used in conjunction with the -a option. It will make pdbedit 
          to add a machine trust account instead of a user account (-u username will provide 
          the machine name).

          Example: pdbedit -a -m -u w2k-wks

       -x
          This option causes pdbedit to delete an account from the database. It needs a username 
          specified with the -u switch.

          Example: pdbedit -x -u bob

       -i passdb-backend
          Use a different passdb backend to retrieve users than the one specified in smb.conf. Can be 
          used to import data  into  your  local user database.

          This option will ease migration from one passdb backend to another.

          Example: pdbedit -i smbpasswd:/etc/smbpasswd.old

       -e passdb-backend
          Exports all currently available users to the specified password database backend.

          This option will ease migration from one passdb backend to another and will ease backing up.

          Example: pdbedit -e smbpasswd:/root/samba-users.backup

       -g
          If you specify -g, then -i in-backend -e out-backend applies to the group mapping instead of 
          the user database.

          This option will ease migration from one passdb backend to another and will ease backing up.

       -b passdb-backend
          Use a different default passdb backend.

          Example: pdbedit -b xml:/root/pdb-backup.xml -l

       -P account-policy
          Display an account policy

          Valid  policies are: minimum password age, reset count minutes, disconnect time, user must
          logon to change password, password history, lockout duration, min password length, 
          maximum password age and bad lockout attempt.

          Example: pdbedit -P "bad lockout attempt"

          account policy value for bad lockout attempt is 0

       -C account-policy-value
          Sets an account policy to a specified value. This option may only be used in conjunction with
          the -P option.

          Example: pdbedit -P "bad lockout attempt" -C 3

          account policy value for bad lockout attempt was 0
          account policy value for bad lockout attempt is now 3
       -y
          If you specify -y, then -i in-backend -e out-backend applies to the account policies instead
          of the user database.

          This option will allow to migrate account policies from their default tdb-store into a passdb 
          backend,  e.g.  an  LDAP  directory server.

          Example: pdbedit -y -i tdbsam: -e ldapsam:ldap://my.ldap.host

       -h|--help
          Print a summary of command line options.

       -V
          Prints the program version number.

       -s <configuration file>
          The  file  specified  contains the configuration details required by the server. The information
          in this file includes server-specific information such as what printcap file to use, as well as 
          descriptions of all the services that the server  is  to  provide.
          See smb.conf for more information. The default configuration file name is determined at compile time.

       -d|--debuglevel=level
          level is an integer from 0 to 10. The default value if this parameter is not specified is zero.

          The higher this value, the more detail will be logged to the log files about the activities of the 
          server. At level 0, only critical errors and serious warnings will be logged. Level 1 is a 
          reasonable level for day-to-day running - it generates a small amount of information about 
          operations carried out.

          Levels  above 1 will generate considerable amounts of log data, and should only be used when 
          investigating a problem. Levels above 3 are designed for use only by developers and generate 
          HUGE amounts of log data, most of which is extremely cryptic.

          Note that specifying this parameter here will override the

          parameter in the smb.conf file.

       -l|--logfile=logdirectory
          Base directory name for log/debug files. The extension ".progname" will be appended (e.g. 
          log.smbclient,  log.smbd,  etc...).  The log file is never removed by the client.

secrets.tdb

In the secrets.tdb file samba stores the domain SID and when using the ldapsam backend, it also stores the ldap connect information (bind dn and password).

tdbbackup

tdbbackup — tool for backing up and for validating the integrity of samba .tdb files

tdbbackup is a tool that may be used to backup samba .tdb files. This tool may also be used to verify the integrity of the .tdb files prior to samba startup or during normal operation. If it finds file damage and it finds a prior backup the backup file will be restored.

-hGet help information.
-s suffixThe -s option allows the adminisistrator to specify a file backup extension. This way it is possible to keep a history of tdb backup files by using a new suffix for each backup.
-vThe -v will check the database for damages (currupt data) which if detected causes the backup to be restored.

tdbdump

tdbdump - tool for printing the contents of a TDB file

tdbdump is a very simple utility that 'dumps' the contents of a TDB (Trivial DataBase) file to standard output in a human-readable format.

tdbtool

tdbtool - manipulate the contents TDB files

tdbtool a tool for displaying and altering the contents of Samba TDB (Trivial DataBase) files. Each of the commands listed below can be entered interactively or provided on the command line.

Syntax: tdbtool TDBFILE [COMMANDS…]

create TDBFILECreate a new database named TDBFILE.
open TDBFILEOpen an existing database named TDBFILE.
eraseErase the current database.
dumpDump the current database as strings.
cdumpDump the current database as connection records.
keysDump the current database keys as strings.
hexkeysDump the current database keys as hex values.
infoPrint summary information about the current database.
insert KEY DATAInsert a record into the current database.
move KEY TDBFILEMove a record from the current database into TDBFILE.
store KEY DATAStore (replace) a record in the current database.
show KEYShow a record by key.
delete KEYDelete a record by key.
listPrint the current database hash table and free list.
freePrint the current database and free list.
! COMMANDExecute the given system command.
firstPrint the first record in the current database.
nextPrint the next record in the current database.
quitExit tdbtool.

smbpasswd

smbpasswd - change a user's SMB password

The smbpasswd program has several different functions, depending on whether it is run by the root user or not. When run as a normal user it allows the user to change the password used for their SMB sessions on any machines that store SMB passwords.

smbpasswd [options] username

-aAdd user
-xDelete user
-dDisable user
-eEnable disabled user
-nNo password (blank)
-r machinenameRemote machine to connect to
-mMachine account
-U usernameUsername to use when connecting to remote machine
-sSilence smbpasswd and to read its old and new passwords from standard input
-w passwordThis parameter is only available if Samba has been compiled with LDAP support. The -w switch is used to specify the password to be used with the ldap admin dn.
-WThis option is same as ”-w” except that the password should be entered using stdin.
-iinterdomain trust account
-LLocal mode

Topic 311: Compile and Install Samba

311.1 Configure and Build From Source (weight: 1)

Description:Candidates should be able to compile Samba from source and resolve dependencies

Key Knowledge Areas

  • Identify key Samba packages and content
  • Indentify and resolve dependencies
  • Describe Samba software structure
  • Knowledge of common Samba compilation options

The following is a partial list of the used files, terms and utilities:

  • gzip
  • gpg
  • make

Knowledge of common Samba compilation options

–with-ldapLDAP support
–with-adsActive Directory support
–with-pamInclude PAM support
–with-syslogInclude experimental SYSLOG support
–with-quotasInclude disk-quota support
–with-sys-quotasInclude lib/sysquotas.c support
–with-winbindBuild winbind

For more options see configure –help

311.2 Install and Upgrade Samba (weight: 1)

Description: Candidates should be able to install and upgrade Samba from source and from packages

Key Knowledge Areas

  • Install Samba from packages
  • Install Samba from source
  • Upgrade Samba

The following is a partial list of the used files, terms and utilities:

  • gpg
  • dpkg
  • rpm

dpkg

Install

dpkg -i samba-<version>.deb

Update

dpkg --update-avail samba-<version>.deb

rpm

Install

rpm -vih samba-<version>.rpm

Update

rpm -vUh samba-<version>.rpm

Source

Install

tar zxvf samba-<version>.tar.gz
cd samba-<version>
./configure
make
make install

Topic 312: Samba Configuration and Usage

312.1 Configure Samba (weight: 6)

Description: Candidates should be able to configure the Samba daemons for a wide variety of purposes

Key Knowledge Areas

  • Knowledge of Samba server configuration file structure
  • Knowledge of Samba variables and configuration parameters
  • Identify key TCP/UDP ports used with SMB/CIFS
  • Configure Samba logging
  • Troubleshoot and debug problems with Samba

The following is a partial list of the used files, terms and utilities:

  • smb.conf parameters
  • smb.conf variables
  • /etc/services
  • /var/log/samba/*
  • log level
  • debuglevel
  • testparm
  • smbtar
  • strace

smb.conf parameters

There are three special sections, [global], [homes] and [printers].

  • The [global] section: Parameters in this section apply to the server as a whole, or are defaults for sections that do not specifically define certain items.
  • The [homes] section: If a section called [homes] is included in the configuration file, services connecting clients to their home directories can be created on the fly by the server.
  • The [printers] section: This section works like [homes], but for printers.

smb.conf variables

# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options (perhaps too
# many!) most of which are not shown in this example
#
# Any line which starts with a ; (semi-colon) or a # (hash)
# is a comment and is ignored. In this example we will use a #
# for commentry and a ; for parts of the config file that you
# may wish to enable
#
# NOTE: Whenever you modify this file you should run the command "testparm"
# to check that you have not made any basic syntactic errors.
#
#======================= Global Settings =====================================
[global]

# workgroup = Make sure it matches YOUR OWN NT-Domain-Name or Workgroup-Name
	workgroup = workgroup

# server string is the equivalent of the NT Description field
	server string = Samba Server

# This option is important for security. It allows you to restrict
# connections to machines which are on your local network. The
# following example restricts access to two C class networks and
# the "loopback" interface. For more examples of the syntax see
# the smb.conf man page
;   hosts allow = 192.168.1. 192.168.2. 127.

# if you want to automatically load your printer list rather
# than setting them up individually then you'll need this
	printcap name = /etc/printcap
	load printers = yes

# It should not be necessary to spell out the print system type unless
# yours is non-standard. Currently supported print systems include:
# bsd, sysv, plp, lprng, aix, hpux, qnx
;   printing = bsd

# Uncomment this if you want a guest account, you must add this to /etc/passwd
# otherwise the user "nobody" is used
;  guest account = pcguest

# this tells Samba to use a separate log file for each machine
# that connects
	log file = /var/log/samba/%m.log
# all log information in one file
#   log file = /var/log/samba/smbd.log

# Put a capping on the size of the log files (in Kb).
	max log size = 50

# Security mode. Most people will want user level security. See
# security_level.txt for details.
# Use password server option only with security = server
;   password server = <NT-Server-Name>

# Password Level allows matching of _n_ characters of the password for
# all combinations of upper and lower case.
;  password level = 8
;  username level = 8

# You may wish to use password encryption. Please read
# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
;  encrypt passwords = yes
;  smb passwd file = /etc/samba/smbpasswd

# The following are needed to allow password changing from Windows to
# update the Linux system password also.
# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.
# NOTE2: You do NOT need these to allow workstations to change only
#        the encrypted SMB passwords. They allow the Unix password
#        to be kept in sync with the SMB password.
;  unix password sync = Yes
;  passwd program = /usr/bin/passwd %u
;  passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*

# Unix users can map to different SMB User names
;  username map = /etc/samba/smbusers

# Using the following line enables you to customise your configuration
# on a per machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
;   include = /etc/samba/smb.conf.%m

# Most people will find that this option gives better performance.
# See speed.txt and the manual pages for details
	socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# Configure Samba to use multiple interfaces
# If you have multiple network interfaces then you must list them
# here. See the man page for details.
;   interfaces = 192.168.12.2/24 192.168.13.2/24

# Configure remote browse list synchronisation here
#  request announcement to, or browse list sync from:
#	a specific host or from / to a whole subnet (see below)
;   remote browse sync = 192.168.3.25 192.168.5.255
# Cause this host to announce itself to local subnets here
;   remote announce = 192.168.1.255 192.168.2.44

# Browser Control Options:
# set local master to no if you don't want Samba to become a master
# browser on your network. Otherwise the normal election rules apply
;   local master = no

# OS Level determines the precedence of this server in master browser
# elections. The default value should be reasonable
;   os level = 33

# Domain Master specifies Samba to be the Domain Master Browser. This
# allows Samba to collate browse lists between subnets. Don't use this
# if you already have a Windows NT domain controller doing this job
;   domain master = yes

# Preferred Master causes Samba to force a local browser election on startup
# and gives it a slightly higher chance of winning the election
;   preferred master = yes

# Enable this if you want Samba to be a domain logon server for
# Windows95 workstations.
;   domain logons = yes

# if you enable domain logons then you may want a per-machine or
# per user logon script
# run a specific logon batch file per workstation (machine)
;   logon script = %m.bat
# run a specific logon batch file per username
;   logon script = %U.bat

# Where to store roving profiles (only for Win95 and WinNT)
#        %L substitutes for this servers netbios name, %U is username
#        You must uncomment the [Profiles] share below
;   logon path = \\%L\Profiles\%U

# All NetBIOS names must be resolved to IP Addresses
# 'Name Resolve Order' allows the named resolution mechanism to be specified
# the default order is "host lmhosts wins bcast". "host" means use the unix
# system gethostbyname() function call that will use either /etc/hosts OR
# DNS or NIS depending on the settings of /etc/host.config, /etc/nsswitch.conf
# and the /etc/resolv.conf file. "host" therefore is system configuration
# dependant. This parameter is most often of use to prevent DNS lookups
# in order to resolve NetBIOS names to IP Addresses. Use with care!
# The example below excludes use of name resolution for machines that are NOT
# on the local network segment
# - OR - are not deliberately to be known via lmhosts or via WINS.
; name resolve order = wins lmhosts bcast

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable it's WINS Server
;   wins support = yes

# WINS Server - Tells the NMBD components of Samba to be a WINS Client
#	Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
;   wins server = w.x.y.z

# WINS Proxy - Tells Samba to answer name resolution queries on
# behalf of a non WINS capable client, for this to work there must be
# at least one	WINS Server on the network. The default is NO.
;   wins proxy = yes

# DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names
# via DNS nslookups. The built-in default for versions 1.9.17 is yes,
# this has been changed in version 1.9.18 to no.
	dns proxy = no

# Case Preservation can be handy - system default is _no_
# NOTE: These can be set on a per share basis
;  preserve case = no
;  short preserve case = no
# Default case is normally upper case for all DOS files
;  default case = lower
# Be very careful with case sensitivity - it can break things!
;  case sensitive = no

#============================ Share Definitions ==============================
	idmap uid = 16777216-33554431
	idmap gid = 16777216-33554431
	template shell = /bin/false
	username map = /etc/samba/smbusers
	winbind use default domain = no
[homes]
	comment = Home Directories
	browseable = no
	writeable = yes

# Un-comment the following and create the netlogon directory for Domain Logons
; [netlogon]
;   comment = Network Logon Service
;   path = /home/netlogon
;   guest ok = yes
;   writable = no
;   share modes = no


# Un-comment the following to provide a specific roving profile share
# the default is to use the user's home directory
;[Profiles]
;    path = /home/profiles
;    browseable = no
;    guest ok = yes


# NOTE: If you have a BSD-style print system there is no need to
# specifically define each individual printer
[printers]
	comment = All Printers
	path = /var/spool/samba
	browseable = no
# Set public = yes to allow user 'guest account' to print
	printable = yes

# This one is useful for people to share files
;[tmp]
;   comment = Temporary file space
;   path = /tmp
;   read only = no
;   public = yes

# A publicly accessible directory, but read only, except for people in
# the "staff" group
;[public]
;   comment = Public Stuff
;   path = /home/samba
;   public = yes
;   read only = yes
;   write list = @staff

# Other examples.
#
# A private printer, usable only by fred. Spool data will be placed in fred's
# home directory. Note that fred must have write access to the spool directory,
# wherever it is.
;[fredsprn]
;   comment = Fred's Printer
;   valid users = fred
;   path = /homes/fred
;   printer = freds_printer
;   public = no
;   writable = no
;   printable = yes

# A private directory, usable only by fred. Note that fred requires write
# access to the directory.
;[fredsdir]
;   comment = Fred's Service
;   path = /usr/somewhere/private
;   valid users = fred
;   public = no
;   writable = yes
;   printable = no

# a service which has a different directory for each machine that connects
# this allows you to tailor configurations to incoming machines. You could
# also use the %u option to tailor it by user name.
# The %m gets replaced with the machine name that is connecting.
;[pchome]
;  comment = PC Directories
;  path = /usr/pc/%m
;  public = no
;  writable = yes

# A publicly accessible directory, read/write to all users. Note that all files
# created in the directory by users will be owned by the default user, so
# any user with access can delete any other user's files. Obviously this
# directory must be writable by the default user. Another user could of course
# be specified, in which case all files would be owned by that user instead.
;[public]
;   path = /usr/somewhere/else/public
;   public = yes
;   only guest = yes
;   writable = yes
;   printable = no

# The following two entries demonstrate how to share a directory so that two
# users can place files there that will be owned by the specific users. In this
# setup, the directory should be writable by both users and should have the
# sticky bit set on it to prevent abuse. Obviously this could be extended to
# as many users as required.
;[myshare]
;   comment = Mary's and Fred's stuff
;   path = /usr/somewhere/shared
;   valid users = mary fred
;   public = no
;   writable = yes
;   printable = no
;   create mask = 0765

/etc/services

  • TCP 139: SMB over NetBIOS
  • TCP 445: plain SMB

/var/log/samba/*

  • log.nmbd: log file from nmbd
  • log.smbd: log file from smbd
  • cores: coredumps

log level

The value of the parameter (a astring) allows the debug level (logging level) to be specified in the smb.conf file. This parameter has been extended since the 2.2.x series, now it allow to specify the debug level for multiple debug classes. This is to give greater flexibility in the configuration of the system.

The default will be the log level specified on the command line or level zero if none was specified.

Example: log level = 3 passdb:5 auth:10 winbind:2

debuglevel

This parameter is a synonym for log level.

testparm

testparm - check an smb.conf configuration file for internal correctness testparm is a very simple test program to check an smbd(8) configuration file for internal correctness. If this program reports no problems, you can use the configuration file with confidence that smbd will successfully load the configuration file.

smbtar

smbtar - shell script for backing up SMB/CIFS shares directly to UNIX tape drives

strace

strace - trace system calls and signals

strace is a useful diagnostic, instructional, and debugging tool. System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. Students, hackers and the overly-curious will find that a great deal can be learned about a system and its system calls by tracing even ordinary programs. And programmers will find that since system calls and signals are events that happen at the user/kernel interface, a close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture race conditions.

See the manual pages for more details.

312.2 File Services (weight: 4)

Description: Candidates should be able to create and configure file shares in a mixed environment

Key Knowledge Areas

  • Create and configure file sharing
  • Plan file service migration
  • Hide IPC$
  • Create scripts for user and group handling of file shares
  • smbcquotas
  • smbsh

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • [homes]
  • browseable, writeable, valid users
  • IPC$
  • mount, smbmount

[homes]

[homes]
	comment = Home Directories
	browseable = no
	writeable = yes

browseable, writeable, valid users

browseableThis controls whether this share is seen in the list of available shares in a net view and in the browse list.
writeableInverted synonym for read only, If this parameter is yes, then users of a service may create or modify files in the service’s directory.
valid usersThis is a list of users that should be allowed to login to this service. Use @ for groups

IPC$

well, the SMB IPC$ share is a generic mechanism that is used heavily for all kinds of RPC systems. typically, it is used in NT to provide “Named Pipes”. one such named pipe is LANMAN. this is a legacy service that provides a real botch-job RPC mechanism.

mount, smbmount

smbmount //server/share /localdir -o username=user,password=pass,uid=500,gid=500
mount -t smbfs -o username=user,password=pass //server/share /localdir

smbcquotas

smbcquotas - Set or get QUOTAs of NTFS 5 shares

smbsh

smbsh allows you to access an NT filesystem using UNIX commands such as ls, egrep, and rcp.

To use the smbsh command, execute smbsh from the prompt and enter the username and password that authenticates you to the machine running the Windows NT operating system.

system% smbsh
Username: user
Password: XXXXXXX

Any dynamically linked command you execute from this shell will access the /smb directory using the smb protocol. For example, the command ls /smb will show a list of workgroups. The command ls /smb/MYGROUP will show all the machines in the workgroup MYGROUP. The command ls /smb/MYGROUP/<machine-name> will show the share names for that machine. You could then, for example, use the cd command to change directories, vi to edit files, and rcp to copy files.

312.3 Print Services (weight: 2)

Description: Candidates should be able to create and manage print shares in a mixed environment

Key Knowledge Areas

  • Create and configure printer sharing
  • Configure integration between Samba and CUPS
  • Manage Windows print drivers and configure downloading of print drivers
  • Configure [print$]
  • Understand security concerns with printer sharing
  • Setup and manage print accounting

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • [print$]
  • CUPS
  • cupsd.conf
  • /var/spool/samba
  • print accounting
  • smbprngenpdf
  • smbspool

smb.conf

[global]
printcap name = /etc/printcap
load printers = yes
printcap name = CUPS
printing = CUPS

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

[ljet]
path = /var/spool/lpd/lp
printer name = lp
writable = yes
public = yes
printable = yes
print command = lpr -r -h -P %p %s

[print$]

[print$]
comment = Printer Drivers Share
path = /var/lib/samba/drivers
write list = root
printer admin = root

CUPS

Windows printer drivers format their output for the printer before sending it across the network. You must configure CUPS to accept the pre-formatted output by uncommenting the following line from /etc/cups/mime.convs:

application/octet-stream application/vnd.cups-raw 0 -

Also uncomment the following line from /etc/cups/mime.types:

application/octet-stream

Now CUPS must be told to allow connections from other machines on the network. Add these lines to /etc/cups/cupsd.conf:

<Location /printers> AuthType None Order Deny,Allow Deny From None Allow From All </Location>

As in the Samba configuration, this configuration allows any computer to connect to your printers and is not recommended for computers on untrusted networks. For information about tightening access control to your printers, see the cupsd.conf man page and the CUPS documentation.

/var/spool/samba

Location for queuing print jobs.

print accounting

FIXME

smbprngenpdf

PDF creator

[pdf]
comment = PDF creator
path = /var/tmp
printable = Yes
print command = /usr/bin/smbprngenpdf -J '%J' -c %c -s %s -u '%u' -z %z
create mask = 0600

smbspool

smbspool - send a print file to an SMB printer

smbspool smb://username:password@workgroup/server[:port]/printer 5 nobody title 1 x.txt
  • The job argument (argv[1]) contains the job ID number and is presently not used by smbspool.
  • The user argument (argv[2]) contains the print user’s name and is presently not used by smbspool.
  • The title argument (argv[3]) contains the job title string and is passed as the remote file name when sending the print job.
  • The copies argument (argv[4]) contains the number of copies to be printed of the named file. If no filename is provided then this argument is not used by smbspool.
  • The options argument (argv[5]) contains the print options in a single string and is currently not used by smbspool.
  • The filename argument (argv[6]) contains the name of the file to print. If this argument is not specified then the print file is read from the standard input.

312.4 Domain Control (weight: 4)

Description: Candidates should be able to setup and maintain primary and backup domain controllers, and manage Windows/Linux clients' access to the domain

Key Knowledge Areas

  • Understand domain membership
  • Create and maintain a primary domain controller
  • Create and maintain a backup domain controller
  • Add computers to an existing domain
  • Configure logon scripts
  • Configure roaming profiles
  • Configure system policies

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • primary domain controller
  • backup domain controller
  • domain membership
  • roaming profiles
  • system policies
  • logon scripts
  • Active Directory
  • LDAP
  • trust relationships

primary domain controller

Microsoft's network environment consists of domains. Each distinct domain is controlled by a Primary Domain Controller. This server is the authoritative repository for all user account information: passwords, real names, home directory locations, logon script definitions, etc etc. Each domain can have one or more Backup Domain Controller. A Backup Domain Controller helps lighten the load on the Primary Domain Controller by handling authentication requests, and can also tremendously speed up network activities. In a multi-site environment connected by a medium capacity link (say, a 56K circuit), a Backup Domain Controller at the remote facility will speed up the logon process for people at that remote site, minimize WAN traffic, and provide a level of fault tolerance to the entire network.

All domain controllers must run the netlogon service (domain logons in Samba). One domain controller must be configured with domain master = Yes (the PDC); on all BDCs set the parameter domain master = No.

[global]
domain logons = Yes
domain master = Yes

[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No

backup domain controller

[global]
domain logons = Yes
domain master = No

[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No

domain membership

First, you must edit your smb.conf file to tell Samba it should now use domain security.

Change (or add) your security line in the [global] section of your smb.conf to read:

security = domain

Note that if the parameter security = user is used, this machine would function as a standalone server and not as a domain member server. Domain security mode causes Samba to work within the domain security context.

Next change the workgroup line in the [global] section to read:

workgroup = MIDEARTH

This is the name of the domain we are joining.

You must also have the parameter encrypt passwords set to yes in order for your users to authenticate to the NT PDC. This is the default setting if this parameter is not specified. There is no need to specify this parameter, but if it is specified in the smb.conf file, it must be set to Yes.

Finally, add (or modify) a password server line in the [global] section to read:

password server = DOMPDC DOMBDC1 DOMBDC2

Alternatively, if you want smbd to determine automatically the list of domain controllers to use for authentication, you may set this line to be:

password server = *

To join the domain, run this command:

root# net rpc join -S DOMPDC -UAdministrator%password

If the -S DOMPDC argument is not given, the domain name will be obtained from smb.conf and the NetBIOS name of the PDC will be obtained either using a WINS lookup or via NetBIOS broadcast based name look up.

The machine is joining the domain DOM, and the PDC for that domain (the only machine that has write access to the domain SAM database) is DOMPDC; therefore, use the -S option. The Administrator%password is the login name and password for an account that has the necessary privilege to add machines to the domain. If this is successful, you will see the following message in your terminal window. Where the older NT4-style domain architecture is used:

Joined domain DOM.

roaming profiles

Roaming Profiles are profiles that are stored on a server and are downloaded to the workstation whenever a user logs into the machine. The profiles are then uploaded back to the central server when the user logs out.

In theory these types of profiles would be perfect in an environment where users jump from machine to machine, except for the fact that they are downloaded (copied) every time a user logs into a machine. Whenever you have multiple copies of a file you run the risk of losing data during the re-syncing of the data over a network. An offset hardware clock, corrupt sectors on a disk or faulty network wiring could cause data corruption.

Another drawback of Roaming Profiles is the fact that, by default, the user's documents and other application data are stored in the profile folder so the profile can grow to be huge. A profile of several hundred megabytes is common. Imagine if 50 users are logging into workstations at the same time, your network would quickly slow to a crawl. To make matters worse, when these users log out, this same data (slightly modified) is then copied back to the server.

To implement Roaming Profiles with Samba a few things must happen. First you must create a share to store these profiles, then you must set a few Samba directives to enable roaming profiles.

[profiles]
comment = Network Profiles Share
path = /srv/samba/profiles
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
browseable = no
guest ok = no
printable = no
hide files = /desktop.ini/outlook*.lnk/*Briefcase*/ 

Then ensure that everyone has write access to the directory listed as the path:

chmod o+rw /srv/samba/profiles 

The smb.conf settings required to use Roaming Profiles by default are:

logon path = \\%L\profiles\%U
logon home = \\%L\%U
logon drive = Z: 

system policies

In order to use System Policy Editor, you must first obtain it. Unfortunately, it is a proprietary tool so you must get it directly from the software maker, specifically Microsoft.

Once you create your Policy File, you must save it as “NTConfig.POL”, then copy it to the “NETLOGON” share of all of your Domain Controllers. To create a NETLOGON Share on a Samba Domain Controller, simply create a directory on your server, such as ”/srv/samba/netlogon”, change the permissions so that everyone has read-only rights (chmod o-wx or chmod o+r) then add the following to your shares section of your smb.conf file.

[netlogon]
comment = Network Logon Service
path = /srv/samba/netlogon
guest ok = Yes
browseable = No
# If you have problems, try adding the following line
# acl check permissions = no

Now just add the NTConfig.POL file to the share, and possibly a logon script. Also ensure that everyone has read access to the files you put in the share.

logon scripts

Samba supports the execution of Windows logon scripts, which are scripts (.BAT or .CMD) that are executed on the client when a user logs on to a Windows domain. Note that these scripts are stored on the Unix side, but are transported across the network to the client side and executed once a user logs on. These scripts are invaluable for dynamically setting up network configurations for users when they log on.

You can instruct Samba to use a logon script with the logon script option, as follows:

[global]
	domain logons = yes
	security = user
	workgroup = SIMPLE

	os level = 34
	local master = yes
	preferred master = yes
	domain master = yes
	logon script = %U.bat

[netlogon]
	comment = The domain logon service
	path = /export/samba/logon
	public = no
	writeable = no
	browsable = no

Note that this example uses the %U variable, which will individualize the script based on the user that is logging in. It is common to customize logon scripts based on the user or machine name that is logging onto the domain. These scripts can then be used to configure individual settings for users or clients.

Here is an example of a logon script that sets the current time to match that of the Samba server and maps two network drives, h and i, to individual shares on the server:

#  Reset the current time to that shown by the server.
#  We must have the "time server = yes" option in the
#  smb.conf for this to work.

echo Setting Current Time...
net time \\hydra /set /yes

#  Here we map network drives to shares on the Samba
#  server
echo Mapping Network Drives to Samba Server Hydra...
net use h: \\hydra\data
net use i: \\hydra\network

Active Directory

You must use at least the following three options in smb.conf:

realm = your.kerberos.REALM
security = ADS
# The following parameter need only be specified if present.
# The default setting if not present is Yes.
encrypt passwords = yes

In case samba cannot correctly identify the appropriate ADS server using the realm name, use the password server option in smb.conf:

password server = your.kerberos.server
Create the Computer Account

As a user who has write permission on the Samba private directory (usually root), run:

root#  net ads join -U Administrator%password

The Administrator account can be any account that has been designated in the ADS domain security settings with permission to add machines to the ADS domain.

LDAP

  • Make sure slapd has the “inetorgperson.schema” and “samba.schema”
  • Add the following indexes:
index           cn,sn,uid,displayName           pres,sub,eq
index           uidNumber,gidNumber             eq
index           sambaSID                        eq
index           sambaPrimaryGroupSID            eq
index           sambaDomainName                 eq
index           objectClass                     pres,eq
#               old 2.x samba attrs
index           rid,primaryGroupID              eq
#
index           default                         sub
  • Added or change the following line in smb.conf, this tells samba to use LDAP as backend.
passdb backend = ldapsam:"ldap://ldap-1.example.com ldap://ldap-2.example.com"
ldap suffix = o=smb,dc=unav,dc=es
ldap machine suffix = ou=Computers
ldap user suffix = ou=Users
ldap admin dn = "cn=root,o=smb,dc=unav,dc=es"
  • Setting the admin_dn password with smbpasswd
smbpasswd -w <ldappassword>
  • You also need to add the buildin accounts to the ldap backend:
Domain Admins
Domain Users
Domain Guests 
  • And map the groups.
root# net groupmap list
Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin
Domain Users (S-1-5-21-2547222302-1596225915-2414751004-513) -> domuser
Domain Guests (S-1-5-21-2547222302-1596225915-2414751004-514) -> domguest

More information

trust relationships

MS Windows NT3/4-type security domains employ a nonhierarchical security structure. The limitations of this architecture as it effects the scalability of MS Windows networking in large organizations is well known. Additionally, the flat namespace that results from this design significantly impacts the delegation of administrative responsibilities in large and diverse organizations.

Samba as the Trusted Domain

In order to set the Samba PDC to be the trusted party of the relationship, you first need to create a special account for the domain that will be the trusting party. To do that, you can use the smbpasswd utility. Creating the trusted domain account is similar to creating a trusted machine account. Suppose, your domain is called SAMBA, and the remote domain is called RUMBA. The first step will be to issue this command from your favorite shell:

root#  smbpasswd -a -i rumba
New SMB password: XXXXXXXX
Retype SMB password: XXXXXXXX
Added user rumba$

where -a means to add a new account into the passdb database and -i means to “create this account with the Interdomain trust flag”.

The account name will be “rumba$” (the name of the remote domain).

After issuing this command, you will be asked to enter the password for the account. You can use any password you want, but be aware that Windows NT will not change this password until 7 days following account creation. After the command returns successfully, you can look at the entry for the new account (in the standard way as appropriate for your configuration) and see that the account's name is really RUMBA$ and it has the “I” flag set in the flags field. Now you are ready to confirm the trust by establishing it from Windows NT Server.

Open User Manager for Domains and from the Policies menu, select Trust Relationships…. Beside the Trusted domains list box, click the Add… button. You will be prompted for the trusted domain name and the relationship password. Type in SAMBA, as this is the name of the remote domain and the password used at the time of account creation. Click on OK and, if everything went without incident, you will see the Trusted domain relationship successfully established message.

Samba as the Trusting Domain

This time activities are somewhat reversed. Again, we'll assume that your domain controlled by the Samba PDC is called SAMBA and the NT-controlled domain is called RUMBA.

The very first step is to add an account for the SAMBA domain on RUMBA's PDC.

Launch the Domain User Manager, then from the menu select Policies, Trust Relationships. Now, next to the Trusting Domains box, press the Add button and type in the name of the trusted domain (SAMBA) and the password to use in securing the relationship.

The password can be arbitrarily chosen. It is easy to change the password from the Samba server whenever you want. After you confirm the password, your account is ready for use. Now its Samba's turn.

Using your favorite shell while logged in as root, issue this command:

root# net rpc trustdom establish rumba

You will be prompted for the password you just typed on your Windows NT4 Server box. An error message, “NT_STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT,” that may be reported periodically is of no concern and may safely be ignored. It means the password you gave is correct and the NT4 server says the account is ready for interdomain connection and not for ordinary connection. After that, be patient; it can take a while (especially in large networks), but eventually you should see the Success message. Congratulations! Your trust relationship has just been established.

312.5 SWAT Configuration (weight: 1)

Description: Candidates should be able to install and configure the Samba web administration tool, and be comfortable with configuring changes to Samba within it

Key Knowledge Areas

  • Knowledge of SWAT features
  • Install and configure SWAT
  • Configure the Samba server via the SWAT interface

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • /usr/sbin/swat
  • internationalization
  • SSL
  • SWAT wizard

SWAT

There are many and varied opinions regarding the usefulness of SWAT. No matter how hard one tries to produce the perfect configuration tool, it remains an object of personal taste. SWAT is a tool that allows Web-based configuration of Samba. It has a wizard that may help to get Samba configured quickly, it has context-sensitive help on each smb.conf parameter, it provides for monitoring of current state of connection information, and it allows networkwide MS Windows network password management.

SWAT is a facility that is part of the Samba suite. The main executable is called swat and is invoked by the internetworking super daemon. See appropriate section for details.

SWAT uses integral Samba components to locate parameters supported by the particular version of Samba. Unlike tools and utilities that are external to Samba, SWAT is always up to date as known Samba parameters change. SWAT provides context-sensitive help for each configuration parameter, directly from man page entries.

Some network administrators believe that it is a good idea to write systems documentation inside configuration files, and for them SWAT will always be a nasty tool. SWAT does not store the configuration file in any intermediate form; rather, it stores only the parameter settings, so when SWAT writes the smb.conf file to disk, it writes only those parameters that are at other than the default settings. The result is that all comments, as well as parameters that are no longer supported, will be lost from the smb.conf file. Additionally, the parameters will be written back in internal ordering.

smb.conf

Before using SWAT, please be warned SWAT will completely replace your smb.conf with a fully optimized file that has been stripped of all comments you might have placed there and only nondefault settings will be written to the file.

/usr/sbin/swat

SWAT should be installed to run via the network super-daemon. Depending on which system your UNIX/Linux system has, you will have either an inetd- or xinetd-based system.

The control entry for the older style file might be:

# swat is the Samba Web Administration Tool
swat stream tcp nowait.400 root /usr/sbin/swat swat

A control file for the newer style xinetd could be:

# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
#              to configure your Samba server. To use SWAT, \
#              connect to port 901 with your favorite web browser.
service swat
{
	port    = 901
	socket_type     = stream
	wait    = no
	only_from = localhost
	user    = root
	server  = /usr/sbin/swat
	log_on_failure  += USERID
	disable = no
}

In the above, the default setting for disable is yes. This means that SWAT is disabled. To enable use of SWAT, set this parameter to no as shown.

internationalization

WAT can be configured to display its messages to match the settings of the language configurations of your Web browser. It will be passed to SWAT in the Accept-Language header of the HTTP request.

To enable this feature:

  • Install the proper msg files from the Samba source/po directory into $LIBDIR.
  • Set your browsers language setting.

The name of the msg file is the same as the language ID sent by the browser. For example, en means English, ja means Japanese, fr means French.

If you do not like some of messages, or there are no msg files for your locale, you can create them simply by copying the en.msg files to the directory for “your language ID.msg” and filling in proper strings to each “msgstr”. For example, in it.msg, the msg file for the Italian locale, just set:

msgid “Set Default” msgstr “Imposta Default”

and so on. If you find a mistake or create a new msg file, please email it to us so we will consider it in the next release of Samba. The msg file should be encoded in UTF-8.

Note that if you enable this feature and the display charset is not matched to your browser's setting, the SWAT display may be corrupted. In a future version of Samba, SWAT will always display messages with UTF-8 encoding. You will then not need to set this smb.conf file parameter.

SSL

Modifications to the SWAT setup are as follows:

 1. Install OpenSSL.
 2. Generate certificate and private key.
      root# /usr/bin/openssl req -new -x509 -days 365 -nodes -config \
      	/usr/share/doc/packages/stunnel/stunnel.cnf \
      	-out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem
 3. Remove SWAT entry from [x]inetd.
 4. Start stunnel.
      root# stunnel -p /etc/stunnel/stunnel.pem -d 901 \
      	 -l /usr/local/samba/bin/swat swat 

Afterward, simply connect to SWAT by using the URL https://myhost:901, accept the certificate, and the SSL connection is up.

SWAT wizard

The purpose of the SWAT Wizard is to help the Microsoft-knowledgeable network administrator to configure Samba with a minimum of effort.

The Wizard page provides a tool for rewriting the smb.conf file in fully optimized format. This will also happen if you press the Commit button. The two differ because the Rewrite button ignores any changes that may have been made, while the Commit button causes all changes to be affected.

The Edit button permits the editing (setting) of the minimal set of options that may be necessary to create a working Samba server.

Finally, there are a limited set of options that determine what type of server Samba will be configured for, whether it will be a WINS server, participate as a WINS client, or operate with no WINS support. By clicking one button, you can elect to expose (or not) user home directories.

312.6 Internationalization (weight: 1)

Description: Candidates should be able to work with internationalization character codes and code pages

Key Knowledge Areas

  • Understand internationalization character codes and code pages
  • Patch and build appropriate code conversion libraries
  • Understand the difference in the name space between Windows and Linux/Unix with respect to user and group naming in a non-English environment
  • Understand the difference in the name space between Windows and Linux/Unix with respect to computer naming in a non-English environment

The following is a partial list of the used files, terms and utilities:

  • internationalization
  • character codes
  • code pages
  • smb.conf
  • code conversion libraries

internationalization

Samba has a limited ability to speak foreign tongues: if you need to deal with characters that aren't in standard ASCII

OptionFunctionDefaultScope
client code pageSets a code page to expect from clients850Global
character setTranslates code pages into alternate UNIX character setsNoneGlobal
coding systemTranslates code page 932 into an Asian character setNoneGlobal
valid charsObsolete: formerly added individual characters to a code page, and had to be used after setting client code pageNoneGlobal
client code page

The character sets on Windows platforms hark back to the original concept of a code page. These code pages are used by DOS and Windows clients to determine rules for mapping lowercase letters to uppercase letters. Samba can be instructed to use a variety of code pages through the use of the global client code page option in order to match the corresponding code page in use on the client. This option loads a code-page definition file

You can set the client code page as follows:

[global]
	client code page = 852
character set

The global character set option can be used to convert filenames offered through a DOS code page (see the previous section, Section 8.3.1, client code page”) to equivalents that can be represented by Unix character sets other than those in the United States. For example, if you want to convert the Western European MS-DOS character set on the client to a Western European Unix character set on the server, you can use the following in your configuration file:

[global]
	client code page = 850
	character set = ISO8859-1

Note that you must include a client code page option to specify the character set from which you are converting.

Coding system

The coding system option is similar to the character set option. However, its purpose is to determine how to convert a Japanese Shift JIS code page into an appropriate Unix character set. In order to use this option, the client code page option described previously must be set to page 932.

valid chars

The valid chars option is an older Samba feature that will add individual characters to a code page. However, this option is being phased out in favor of more modern coding systems. You can use this option as follows:

valid chars = Î
valid chars = 0450:0420 0x0A20:0x0A00
valid chars = A:a

Each of the characters in the list specified should be separated by spaces. If there is a colon between two characters or their numerical equivalents, the data to the left of the colon is considered an uppercase character, while the data to the right is considered the lowercase character. You can represent characters both by literals (if you can type them) and by octal, hexidecimal, or decimal Unicode equivalents.

Topic 313: User and Group Management

313.1 Managing User Accounts and Groups (weight: 4)

Description: Candidates should be able to manage user and group accounts in a mixed environment

Key Knowledge Areas

  • Manage user and group accounts
  • Understand user and group mapping
  • Knowledge of user account management tools
  • Use of the smbpasswd program
  • Force ownership of file and directory objects

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • /usr/bin/smbpasswd
  • /etc/passwd
  • /etc/group
  • force user, force group
  • idmap

Manage user and group accounts

Add user

useradd -d /home/john -s /bin/false -n john
passwd john
smbpasswd -a john

OR

 The following demonstrates the addition of an account to the server FRODO:

root#  net rpc user add password jacko f4sth0rse -S FRODO -Uroot%not24get
Added user jacko

Remove user

smbpasswd -a john
userdel john

OR

 The following command will delete the user account jacko:

root#  net rpc user delete jacko -Uroot%not24get
Deleted user account

Add group

groupadd users
net rpc group add users

Remove group

net rpc group delete users
groupdel users

Understand user and group mapping

This step maps your Windows groups to your Unix groups. This is an important step if you want admin rights on your Windows clients once you have logged onto the client authorizing against the PDC.

First, view the list of Windows groups. This way you know what you're mapping.

root@localhost # net groupmap list
System Operators (S-1-5-32-549) -> -1
Replicators (S-1-5-32-552) -> -1
Guests (S-1-5-32-546) -> -1
Domain Guests (S-1-5-21-3885047494-3765334852-1543503842-514) -> nobody
Domain Admins (S-1-5-21-3885047494-3765334852-1543503842-512) -> ntadmins
Power Users (S-1-5-32-547) -> -1
Print Operators (S-1-5-32-550) -> -1
Administrators (S-1-5-32-544) -> 1
Account Operators (S-1-5-32-548) -> -1
Domain Users (S-1-5-21-3885047494-3765334852-1543503842-513) -> users
Backup Operators (S-1-5-32-551) -> -1
Users (S-1-5-32-545) -> -1

It is possible that for some reason your groupmap is empty. Although unfortunate, its not a big deal as we only need the 3 mapped groups in there. Just run the following commands:

net groupmap add rid=512 unixgroup=ntadmins ntgroup="Domain Admins"
net groupmap add rid=513 unixgroup=users ntgroup="Domain Users"
net groupmap add rid=514 unixgroup=nobody ntgroup="Domain Guests"

As you can see, I've only mapped 3 groups as this is all that I require on my domain. Additionally, I created a Unix group called “ntadmins”.

root@localhost # groupadd ntadmins

After you create your required Unix groups, you need to map them to your Windows groups replacing the ntgroup value with a Windows group listed above and unixgroup is the Unix group you wish to map the Windows group to (remember, the Unix group must already exist).

root@localhost # net groupmap modify ntgroup="Domain Admins" unixgroup=ntadmins

You'll need to perform this command for each Unix group you wish to map. You can now use your new groups for specific group parameters in either your global or service scopes

Force ownership of file and directory objects

force group (S)

This specifies a UNIX group name that will be assigned as the default primary group for all users connecting to this service. This is useful for sharing files by ensuring that all access to files on service will use the named group for their permissions checking. Thus, by assigning permissions for this group to the files and directories within this service the Samba administrator can restrict or allow sharing of these files.

force user (S)

This specifies a UNIX user name that will be assigned as the default user for all users connecting to this service. This is useful for sharing files. You should also use it carefully as using it incorrectly can cause security problems. This user name only gets used once a connection is established. Thus clients still need to connect as a valid user and supply a valid password. Once connected, all file operations will be performed as the “forced user”, no matter what username the client connected as. This can be very useful.

idmap

The IDMAP facility is of concern where more than one Samba server (or Samba network client) is installed in a domain. Where there is a single Samba server, do not be too concerned regarding the IDMAP infrastructure the default behavior of Samba is nearly always sufficient. Where mulitple Samba servers are used it is often necessary to move data off one server and onto another, and that is where the fun begins!

Where user and group account information is stored in an LDAP directory every server can have the same consistent UID and GID for users and groups. This is achieved using NSS and the nss_ldap tool. Samba can be configured to use only local accounts, in which case the scope of the IDMAP problem is somewhat reduced. This works reasonably well if the servers belong to a single domain, and interdomain trusts are not needed. On the other hand, if the Samba servers are NT4 domain members, or ADS domain members, or if there is a need to keep the security name-space separate (i.e., the user DOMINICUS\FJones must not be given access to the account resources of the user FRANCISCUS\FJones free from inadvertent cross-over, close attention should be given to the way that the IDMAP facility is configured.

The use of IDMAP is important where the Samba server will be accessed by workstations or servers from more than one domain, in which case it is important to run winbind so it can handle the resolution (ID mapping) of foreign SIDs to local UNIX UIDs and GIDs.

The use of the IDMAP facility requires the execution of the winbindd upon Samba startup.

idmap uid (G)

The idmap uid parameter specifies the range of user ids that are allocated for use in mapping UNIX users to NT user SIDs. This range of ids should have no existing local or NIS users within it as strange conflicts can occur otherwise.

idmap gid (G)

The idmap gid parameter specifies the range of group ids that are allocated for the purpose of mapping UNX groups to NT group SIDs. This range of group ids should have no existing local or NIS groups within it as strange conflicts can occur otherwise.

313.2 Authentication and Authorization (weight: 8)

Description: Candidates should understand the various authentication mechanisms and configure access control

Key Knowledge Areas

  • Setup a local password database
  • Knowledge of the smbpasswd file format
  • Perform password synchronization
  • Knowledge of alternative backend storage for passwords
  • Integrate Samba with LDAP
  • Understand access control lists

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • smbpasswd
  • passdb backend
  • security mask
  • PAM
  • NSS
  • password synchronization
  • LDAP

smbpasswd

The format of the smbpasswd file used by Samba 2.2 is very similar to the familiar Unix passwd(5) file. It is an ASCII file containing one line for each user. Each field ithin each line is separated from the next by a colon. Any entry beginning with '#' is ignored. The smbpasswd file contains the following information for each user:

nameThis is the user name. It must be a name that already exists in the standard UNIX passwd file.
uidThis is the UNIX uid. It must match the uid field for the same user entry in the standard UNIX passwd file. If this does not match then Samba will refuse to recognize this smbpasswd file entry as being valid for a user.
Lanman Password HashThis is the LANMAN hash of the user's password, encoded as 32 hex digits. The LANMAN hash is created by DES encrypting a well known string with the user's password as the DES key. This is the same password used by Windows 95/98 machines. Note that this password hash is regarded as weak as it is vulnerable to dictionary attacks and if two users choose the same password this entry will be identical (i.e. the password is not “salted” as the UNIX password is). If the user has a null password this field will contain the characters “NO PASSWORD” as the start of the hex string. If the hex string is equal to 32 'X' characters then the user's account is marked as disabled and the user will not be able to log onto the Samba server.
NT Password HashThis is the Windows NT hash of the user's password, encoded as 32 hex digits. The Windows NT hash is created by taking the user's password as represented in 16-bit, little-endian UNICODE and then applying the MD4 (internet rfc1321) hashing algorithm to it. This password hash is considered more secure than the LANMAN Password Hash as it preserves the case of the password and uses a much higher quality hashing algorithm. However, it is still the case that if two users choose the same password this entry will be identical (i.e. the password is not “salted” as the UNIX password is).
Account FlagsThis section contains flags that describe the attributes of the users account. This field is bracketed by '[' and ']' characters and is always 13 characters in length (including the '[' and ']' characters). The contents of this field may be any of the following characters: U - This means this is a “User” account, i.e. an ordinary user. N - This means the account has no password (the passwords in the fields LANMAN Password Hash and NT Password Hash are ignored). Note that this will only allow users to log on with no password if the null passwords parameter is set in the smb.conf(5) config file. D - This means the account is disabled and no SMB/CIFS logins will be allowed for this user. X - This means the password does not expire. W - This means this account is a “Workstation Trust” account. This kind of account is used in the Samba PDC code stream to allow Windows NT Workstations and Servers to join a Domain hosted by a Samba PDC. Other flags may be added as the code is extended in future. The rest of this field space is filled in with spaces. For further information regarding the flags that are supported please refer to the man page for the pdbedit command.
Last Change TimeThis field consists of the time the account was last modified. It consists of the characters 'LCT-' (standing for “Last Change Time”) followed by a numeric encoding of the UNIX time in seconds since the epoch (1970) that the last change was made.

All other colon separated fields are ignored at this time.

passdb backend

This option allows the administrator to chose which backend will be used for storing user and possibly group information. This allows you to swap between dfferent storage mechanisms without recompile.

  • smbpasswd - The default smbpasswd backend. Takes a path to the smbpasswd file as an optional argument.
  • tdbsam - The TDB based password storage backend. Takes a path to the TDB as an optional argument (defaults to passdb.tdb in the private dir directory.
  • ldapsam - The LDAP based passdb backend. Takes an LDAP URL as an optional argument (defaults to ldap://localhost)

security mask

This parameter controls what UNIX permission bits can be modified when a Windows NT client is manipulating the UNIX permission on a file using the native NT security dialog box. This parameter is applied as a mask (AND'ed with) to the changed permission bits, thus preventing any bits not in this mask from being modified. Make sure not to mix up this parameter with force security mode, which works in a manner similar to this one but uses a logical OR instead of an AND. Essentially, zero bits in this mask may be treated as a set of bits the user is not allowed to change. If not set explicitly this parameter is 0777, allowing a user to modify all the user/group/world permissions on a file. Note that users who can access the Samba server through other means can easily bypass this restriction, so it is primarily useful for standalone “appliance” systems. Administrators of most normal systems will probably want to leave it set to 0777.

PAM

A number of UNIX systems (e.g., Sun Solaris), as well as the xxxxBSD family and Linux, now utilize the Pluggable Authentication Modules (PAM) facility to provide all authentication, authorization, and resource control services. Prior to the introduction of PAM, a decision to use an alternative to the system password database (/etc/passwd) would require the provision of alternatives for all programs that provide security services. Such a choice would involve provision of alternatives to programs such as login, passwd, chown, and so on.

SMB Password

This module, called pam_smbpass.so, allows user authentication of the passdb backend that is configured in the Samba smb.conf file.

SMB Server

The pam_smb_auth.so module is the original MS Windows networking authentication tool. This module has been somewhat outdated by the Winbind module.

Winbind

The pam_winbind.so module allows Samba to obtain authentication from any MS Windows domain controller. It can just as easily be used to authenticate users for access to any PAM-enabled application.

Example

#%PAM-1.0
# The PAM configuration file for the “samba” service
#
auth       required     pam_smbpass.so nodelay
account    required     pam_pwdb.so audit nodelay
session    required     pam_pwdb.so nodelay
password   required     pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf

More information

password synchronization

pam_smbpass is a PAM module that can be used on conforming systems to keep the smbpasswd (Samba password) database in sync with the UNIX password file. PAM is an API supported under some UNIX operating systems, such as Solaris, HPUX, and Linux, that provides a generic interface to authentication mechanisms.

This module authenticates a local smbpasswd user database. If you require support for authenticating against a remote SMB server, or if you are concerned about the presence of SUID root binaries on your system, it is recommended that you use pam_winbind instead.

The following are examples of the use of pam_smbpass.so in the format of the Linux /etc/pam.d/ files structure. Those wishing to implement this tool on other platforms will need to adapt this appropriately. Password Synchronization Configuration

The following is a sample PAM configuration that shows the use of pam_smbpass to make sure private/smbpasswd is kept in sync when /etc/passwd (/etc/shadow) is changed. It is useful when an expired password might be changed by an application (such as ssh).

#%PAM-1.0
# password-sync
#
auth       requisite    pam_nologin.so
auth       required     pam_unix.so
account    required     pam_unix.so
password   requisite    pam_cracklib.so retry=3
password   requisite    pam_unix.so shadow md5 use_authtok try_first_pass
password   required     pam_smbpass.so nullok use_authtok try_first_pass
session    required     pam_unix.so

LDAP

Samba LDAP intergration is described in 312.4 You will also require system ldap integration (PAM and NSS).

PAM

For PAM LDAP configuration, the simplest solution is to edit the following files in the /etc/pam.d directory: login, password, samba, sshd and add the pam_ldap.so modules as shown here:

#%PAM-1.0
auth     required    pam_securetty.so
auth     required    pam_nologin.so
auth     sufficient  pam_ldap.so
auth     required    pam_unix2.so   nullok try_first_pass #set_secrpc
account  sufficient  pam_ldap.so
account  required    pam_unix2.so
password required    pam_pwcheck.so nullok
password required    pam_ldap.so    use_first_pass use_authtok
password required    pam_unix2.so   nullok use_first_pass use_authtok
session  required    pam_unix2.so   none # debug or trace
session  required    pam_limits.so
session  required    pam_env.so
session  optional    pam_mail.so

NSS

System Databases and Name Service Switch configuration file.

Configuration File for NSS LDAP Support /etc/ldap.conf

host 127.0.0.1

base dc=abmas,dc=biz

binddn cn=Manager,dc=abmas,dc=biz
bindpw not24get

timelimit 50
bind_timelimit 50
bind_policy hard

idle_timelimit 3600

pam_password exop

nss_base_passwd ou=People,dc=abmas,dc=biz?one
nss_base_shadow ou=People,dc=abmas,dc=biz?one
nss_base_group  ou=Groups,dc=abmas,dc=biz?one

ssl off

Edit the NSS control file (/etc/nsswitch.conf) so that the lines that control user and group resolution will obtain information from the normal system files as well as from ldap:

passwd: files ldap
shadow: files ldap
group:  files ldap
hosts:  files dns wins

313.3 Winbind (weight: 2)

Description: Candidates should be able to install and configure the Winbind service

Key Knowledge Areas

  • Install Winbind
  • Configure Winbind

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • winbindd
  • PAM
  • NSCD
  • SID
  • /etc/passwd
  • /etc/group
  • foreign SID

What is Winbind

Winbind unifies UNIX and Windows NT account management by allowing a UNIX box to become a full member of an NT domain. Once this is done, the UNIX box will see NT users and groups as if they were “native” UNIX users and groups, allowing the NT domain to be used in much the same manner that NIS+ is used within UNIX-only environments.

The end result is that whenever a program on the UNIX machine asks the operating system to look up a user or group name, the query will be resolved by asking the NT domain controller for the specified domain to do the lookup. Because Winbind hooks into the operating system at a low level (via the NSS name resolution modules in the C library), this redirection to the NT domain controller is completely transparent.

Users on the UNIX machine can then use NT user and group names as they would “native” UNIX names. They can chown files so they are owned by NT domain users or even login to the UNIX machine and run a UNIX X-Window session as a domain user.

The only obvious indication that Winbind is being used is that user and group names take the form DOMAIN\user and DOMAIN\group. This is necessary because it allows Winbind to determine that redirection to a domain controller is wanted for a particular lookup and which trusted domain is being referenced.

Additionally, Winbind provides an authentication service that hooks into the PAM system to provide authentication via an NT domain to any PAM-enabled applications. This capability solves the problem of synchronizing passwords between systems, since all passwords are stored in a single location (on the domain controller).

Install Winbind

The libraries needed to run the winbindd daemon through nsswitch need to be copied to their proper locations:

root# cp ../samba/source/nsswitch/libnss_winbind.so /lib

I also found it necessary to make the following symbolic link:

root# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2

And, in the case of Sun Solaris:

root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1
root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1
root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2

As root, edit /etc/nsswitch.conf to allow user and group entries to be visible from the winbindd daemon. My /etc/nsswitch.conf file looked like this after editing:

passwd:     files winbind
shadow:     files 
group:      files winbind

The libraries needed by the winbindd daemon will be automatically entered into the ldconfig cache the next time your system reboots, but it is faster (and you do not need to reboot) if you do it manually:

root# /sbin/ldconfig -v | grep winbind

This makes libnss_winbind available to winbindd and reports the current search path that is used by the dynamic link loader. The use of the grep filters the output of the ldconfig command so that we may see proof that this library is indeed recognized by the dynamic link loader.

Configure Winbind

Several parameters are needed in the smb.conf file to control the behavior of winbindd. These are described in more detail in the winbindd(8) man page. My smb.conf file, as shown in the smb.conf for Winbind Setup, was modified to include the necessary entries in the [global] section.

Example smb.conf for Winbind Setup

[global]
# separate domain and username with '\', like DOMAIN\username
winbind separator = \
# use uids from 10000 to 20000 for domain users
idmap uid = 10000-20000
# use gids from 10000 to 20000 for domain groups
idmap gid = 10000-20000
# allow enumeration of winbind users and groups
winbind enum users = yes
winbind enum groups = yes
# give winbind users a real shell (only needed if they have telnet access)
template homedir = /home/winnt/%D/%U
template shell = /bin/bash

Join the Samba Server to the PDC Domain

All machines that will participate in domain security should be members of the domain. This applies also to the PDC and all BDCs.

The process of joining a domain requires the use of the net rpc join command. This process communicates with the domain controller it will register with (usually the PDC) via MS DCE RPC. This means, of course, that the smbd process must be running on the target domain controller. It is therefore necessary to temporarily start Samba on a PDC so that it can join its own domain.

Enter the following command to make the Samba server join the domain, where PDC is the name of your PDC and Administrator is a domain user who has administrative privileges in the domain.

The use of the net rpc join facility is shown here:

root# /usr/local/samba/bin/net rpc join -S PDC -U Administrator

The proper response to the command should be “Joined the domain DOMAIN” where DOMAIN is your domain name.

Starting and Testing the winbindd Daemon

Eventually, you will want to modify your Samba startup script to automatically invoke the winbindd daemon when the other parts of Samba start, but it is possible to test out just the Winbind portion first. To start up Winbind services, enter the following command as root:

root# /usr/local/samba/sbin/winbindd

Use the appropriate path to the location of the winbindd executable file.

Winbindd can now also run in “dual daemon mode”. This will make it run as two processes. The first will answer all requests from the cache, thus making responses to clients faster. The other will update the cache for the query to which the first has just responded. The advantage of this is that responses stay accurate and are faster. You can enable dual daemon mode by adding -B to the command line:

root# /usr/local/samba/sbin/winbindd -B

Now, for the real test, try to get some information about the users on your PDC:

root# /usr/local/samba/bin/wbinfo -u

This should echo back a list of users on your Windows users on your PDC. For example, I get the following response:

CEO\Administrator
CEO\burdell
CEO\Guest
CEO\jt-ad
CEO\krbtgt
CEO\TsInternetUser

Obviously, I have named my domain “CEO” and my winbind separator is “\”.

You can do the same sort of thing to get group information from the PDC:

root# /usr/local/samba/bin/wbinfo -g
CEO\Domain Admins
CEO\Domain Users
CEO\Domain Guests
CEO\Domain Computers
CEO\Domain Controllers
CEO\Cert Publishers
CEO\Schema Admins
CEO\Enterprise Admins
CEO\Group Policy Creator Owners

The function getent can now be used to get unified lists of both local and PDC users and groups. Try the following command:

root# getent passwd

You should get a list that looks like your /etc/passwd list followed by the domain users with their new UIDs, GIDs, home directories, and default shells.

The same thing can be done for groups with the command:

root# getent group

NSCD

Nscd is a daemon that provides a cache for the most common name service requests. The default configuration file, /etc/nscd.conf, determines the behavior of the cache daemon. See nscd.conf(5).

Nscd provides cacheing for accesses of the passwd(5), group(5), and hosts(5) databases through standard libc interfaces, such as getpwnam(3), getpwuid(3), getgrnam(3), getgrgid(3), gethostbyname(3), and others.

There are two caches for each database: a positive one for items found, and a negative one for items not found. Each cache has a separate TTL (time-to-live) period for its data. Note that the shadow file is specifically not cached. getspnam(3) calls remain uncached as a result. As a result of this behavior there is not possible to change non-nscd user to another non-nscd user via su service when nscd is running.

Do not under any circumstances run nscd on any system on which winbindd is running.

If nscd is running on the UNIX/Linux system, then even though NSSWITCH is correctly configured, it will not be possible to resolve domain users and groups for file and directory controls.

SID

In the context of the Microsoft Windows NT line of operating systems, a Security Identifier (commonly abbreviated SID) is a unique name (an alphanumeric character string) which is assigned by a Windows Domain controller during the log on process that is used to identify an object, such as a user or a group of users in a network of NT/2000 systems. SIDs are not portable.

Windows grants or denies access and privileges to resources based on access control lists (ACLs), which use SIDs to uniquely identify users and their group memberships. When a user logs into a computer, an access token is generated that contains user and group SIDs and user privilege level. When a user requests access to a resource, the access token is checked by the ACL to permit or deny particular action on a particular object.

SIDs are useful for troubleshooting issues with security audits, Windows server and domain migrations.

SID has format as follows: S-1-5-12-7623811015-3361044348-030300820-1013

  S - The string is a SID.
  1 - The revision level.
  5 - The identifier authority value.
  12-7623811015-3361044348-030300820 - domain or local computer identifier
  1013 – a Relative ID (RID)

Any group or user that is not created by default will have a Relative ID of 1000 or greater.

foreign SID

The term foreign SID is often met with the reaction that it is not relevant to a particular environment. The following documents an interchange that took place on the Samba mailing list. It is a good example of the confusion often expressed regarding the use of winbind.

Fact: Winbind is needed to handle users who use workstations that are NOT part of the local domain.

Response: “Why? I've used Samba with workstations that are not part of my domains lots of times without using winbind. I thought winbind was for using Samba as a member server in a domain controlled by another Samba/Windows PDC.”

If the Samba server will be accessed from a domain other than the local Samba domain, or if there will be access from machines that are not local domain members, winbind will permit the allocation of UIDs and GIDs from the assigned pool that will keep the identity of the foreign user separate from users that are members of the Samba domain.

This means that winbind is eminently useful in cases where a single Samba PDC on a local network is combined with both domain member and domain non-member workstations. If winbind is not used, the user george on a Windows workstation that is not a domain member will be able to access the files of a user called george in the account database of the Samba server that is acting as a PDC. When winbind is used, the default condition is that the local user george will be treated as the account DOMAIN\george and the foreign (non-member of the domain) account will be treated as MACHINE\george because each has a different SID.

Topic 314: Working with CIFS, NetBIOS, and Active Directory

314.1 CIFS Integration (weight: 3)

Description: Candidates should be comfortable working with CIFS in a mixed environment

Key Knowledge Areas

  • Understand SMB/CIFS concepts
  • Mount remote CIFS shares from a Linux client
  • Understand features and benefits of CIFS

The following is a partial list of the used files, terms and utilities:

  • SMB
  • CIFS
  • mount, smbmount
  • smbclient
  • smb.conf
  • /etc/fstab

Understand SMB/CIFS concepts

See 310.1 for SMB and CIF concepts

Mount remote CIFS shares from a Linux client

Use the mount command as follows:

# mount -t cifs //ntserver/download -o username=vivek,password=myPassword /mnt/ntserver 

Using /etc/fstab

//server/share    /mountpoint    cifs   noauto,users,sync,user=username%<my_password>,uid=username2,gid=users,file_mod=0755,dir_mode=0755    0 0

Old style (smbfs)

An example would look like this:

smbmount //servername/sharename /mountdirectory -o username=mywindowsusername,password=mywindowspassword

The mount equivelant is:

mount -t smbfs //servername/sharename /mountdirectory -o username=mywindowsusername,password=mywindowspassword

smbclient - ftp-like client to access SMB/CIFS resources on server

# smbclient \\\\172.16.1.3\\c$ -U jwhittal
# put /etc/hosts
# get pdf995\setup.exe

This uploads /etc/hosts and downloads setup.exe from the pdf995 directory

Understand features and benefits of CIFS

Flexible File Locking

A powerful feature of CIFS is the ability for multiple users to access the same file simultaneously. Depending on the implementation of the protocol, several users may even update different parts of a single file at the same time.

Key to the concept of CIFS file locking is the idea of opportunistic locks. These locks ensure that no client reading a file caches information about the file that is out of date and that no two clients update the same portion of a file at the same time. As you can see, file locking works closely with the CIFS caching mechanisms described in the next section. The client’s role in opportunistic locking is to request the conservative opportunistic lock required and to follow the directives provided by the server (for example, to break an existing opportunistic lock). The server’s role is to monitor the opportunistic locks on all files within the file system, track who has locked what, and notify clients when an opportunistic lock must be broken for whatever reason.

Opportunistic locks are commonly referred to as oplocks. (Well, perhaps they’re not “commonly” referred to anywhere in the world besides my office. Nonetheless, that’s what I’m going to call them.) There are three different flavors of oplocks: exclusive, batch, and level II.

EXCLUSIVE OPLOCKS

Exclusive oplocks are quite simple. A single client opens a file and nobody else can touch it. This allows the client to update and cache however it sees fit, but it restricts anyone else from using that same file. Exclusive oplocks are the most efficient locking method when a client is performing extensive updates to a file. The server has the right to refuse a request from a client for an exclusive oplock, and it will do so if anyone else is accessing the file.

If another client attempts to access a file that has an exclusive oplock, the server may choose to break the exclusive oplock and allow the sharing of the file. To do this, the server notifies the client that has locked the file that it should send any updates that it has cached to the file. Further, because someone else may update the file, the client must empty any read cache. Once the updates are performed and the file is completely synchronized, the exclusive oplock is broken and the server may grant the request to the second client.

BATCH OPLOCKS

Traditionally, SMB file sharing has been inefficient when only small portions of a file are read at a time. Batch oplocks help to relieve this problem. Instead of opening a connection, reading data, closing the connection, reopening the connection, reading data, closing the connection, reopening the connection, and so on, the client may keep the same connection open and perform several reads at once.

The client may also choose to use read-ahead caching by anticipating the need for the next several lines of a file and reading them before they are actually required. These lines are likely to be transmitted in the same packet, reducing the total load on the network and increasing the perceived response time.

The disadvantage to batch oplocks appears when several clients wish to access the same file simultaneously. They may have to contend with locking conflicts, which are much less likely when a file is opened and closed for each access. To limit the effect of this problem, the server has the capability to notify a client with a batch oplock on a file that it must break the oplock. Thus, it will revert to the more pessimistic form of accessing the file–opening and closing the connection each time the file must be accessed.

LEVEL II OPLOCKS

On the public Internet, it is customary for many users to view the same file simultaneously. HTTP is well suited to this type of access because, traditionally, it is a read-only protocol and files are not kept open for an extended amount of time. Therefore, clients will never run into the problem of contention.

However, one of the problems encountered as file sharing moves onto the public Internet is the frequency of file updates. Additionally, users may keep files open for an extended amount of time. For example, if a user opens a file in Word, it may be kept open for the entire period that the user is working on the file. However, that same file may be opened in Netscape Navigator and only need to remain open long enough to transmit it across the internetwork.

Level II oplocks help to relieve these problems. Level II oplocks allow multiple clients to gain read access to the same file simultaneously. Theoretically, there can be no contention because no client may attempt to update the file. Therefore, all clients may read the identical file without concern for its becoming outdated.

This works well in theory, but the majority of clients (such as Microsoft Word) open a file by requesting read/write access to it, even if the file is opened strictly for read access. This heralds back to the day of standalone PCs, when applications never needed to be concerned about sharing their files with others. However, in the modern world, a single file on a network share may be accessed by dozens of people within a corporate network simultaneously. So how can CIFS help to ensure that applications do not request more privileges to a file than they actually require?

The level II oplocks built into CIFS enable the server to limit the client applications to read-only access when that is all they really need (regardless of what they request). Essentially, the client will still request read/write access when opening a file, but the server will respond with a message saying, “You don’t really need write access, do you? Others may want to share that file too, you know.” Assuming the client supports level II oplocks, it may choose to settle for read access, allowing other clients to read the file simultaneously.

Suppose a client actually does intend to write to a file, but several others already have level II oplocks to read the file. CIFS takes this into account. As part of the level II oplock functionality, CIFS can notify the read-only clients that their oplock has been broken. This allows the end user to modify a file that others are currently viewing and to rest assured that they will be notified of the changes and will not attempt to simultaneously update the file.

Robust Caching

To reduce the amount of traffic generated on the Internet and wide area networks, CIFS supports more robust caching than SMB ever did. This caching ensures that files remain synchronized while generating the least amount of network traffic possible. Several different forms of caching may be used, depending on how a file is being accessed.

Read-ahead caching allows a CIFS client to read a file across a network only once, though it may be accessed many times. The first time the file is read, the client will store the information in memory in case it needs to be used later. Read-ahead caching works well but can cause problems if the file on the server is updated–the client that caches the file will no longer have an accurate copy. CIFS takes this into account; read-ahead caching is considered a form of “safe caching” as long as all clients are accessing the file for reads only.

Write-behind caching speeds updates to a file by not transmitting them from the server to the client immediately–these updates are stored on the client and transmitted at a later time. This type of caching is considered “safe caching” as long as only a single client has requested write access to the file. Indeed, no clients may even request read access to a given file (or portion of the file) and still allow write-behind caching to be safe.

These caching mechanisms are implemented in the client portion of the conversation. It is strictly up to the client to determine when to cache and when to query the server for a portion of the file. However, the CIFS protocol builds in a communications mechanism that allows the server to notify the clients how many users are accessing a file and what type of accesses are being made. Using this information, the CIFS client is capable of making an informed decision about what caching mechanism should be used. Per the protocol, the client should only make use of caching that is considered “safe” at any given point in time.

To clarify this point, consider an organization with a CIFS file server located on the Internet. Bob, a user in the Atlanta office, wishes to view an accounting form located on the file server. Because he is the only user accessing the file at that time, the CIFS client on his computer uses safe read-ahead caching. However, one of the accountants in the New York office needs to update this file. The server knows that Bob’s computer may need to be informed that someone is trying to update the file so that it can use a less optimistic form of caching–so it notifies Bob’s CIFS client that writes may be occurring to the file. The accountant is able to update the file but cannot use write-behind caching because a user is currently reading the file; all updates must be sent immediately to the server.

Besides being cached on a per-access basis, files accessed using CIFS may be cached much as HTTP proxies cache information from other Web servers. To aid in this, CIFS enables servers to notify clients when a file is changed. This allows the client either to requery the file or to mark it as bad, so as not to inadvertently use an outdated version of a file.

Fault Tolerance

Fault tolerance is key to any scalable protocol, and CIFS has a robust set of fault-tolerant features implemented at both the client and server sides. Because the Internet is an unreliable network, file connections may come and go depending on the state of dial-up connections and leased lines. CIFS clients are capable of losing a connection to a file that is being read or modified and then automatically reopening the same file once the connection is reestablished.

The DFS protocols also provide for fault tolerance within CIFS. Because multiple servers may be listed as sources for a given network share, the client is capable of choosing a server that is still functioning if one or more of the alternates have failed. This feature will become easier to maintain when Windows NT 5.0 is released because it includes the ability to replicate files between servers, ensuring that duplicate copies of files remain duplicated.

Distributed File Services: DFS

When information on a network is tied to a specific server, this fact seriously limits the scalability of that network. Indeed, it may become necessary to move the files, rename the server, or replace the server. This has always been a problem with traditional SMB file sharing; normally, a client establishes a connection to a network share that resides on a specific server. If the file moves to a different server, the user must manually establish another network connection. If the user wishes to access files on a different server, another connection must be established.

To work around these problems, CIFS includes a feature called the distributed file system. DFS is not a new concept, but it is new to Microsoft networking. DFS allows for a single network share to act as the root of a network file system that may span many servers in many different locations. The client is allowed to access files on any of these servers, but the user never has to know that they are located in different places.

More information on DFS and Microsoft’s implementation of DFS is provided in the next chapter.

Flexible Naming

SMB is bound to the NetBIOS naming scheme. NetBIOS names do not work well on the Internet for many reasons, as described in Chapter 10, “NetBIOS: Friend or Foe,” Chapter 11, “WINS,” and Chapter 12, “DNS.” CIFS is more flexible than traditional SMB traffic because it allows for open addressing of servers. Therefore, the DNS namespace, which is typically much better suited for use on the Internet, may be used.

Several different naming methods are supported. Most of these are already supported within Windows NT 4.0: traditional NetBIOS naming, DNS hostnames, and IP addresses. When a client references a server using the DNS name, the hostname is separated, padded to 16 characters, and submitted to the server as a NetBIOS name. Clients that attempt to access a CIFS server using the IP address create a session using the generic name “*SMBSERVER.” Standard NetBIOS names merely need to be converted to uppercase before being submitted.

You’ll notice that NetBIOS names are still relied upon within the CIFS protocol itself. While this may prove to be a limitation in the future, the ability for the clients to initiate sessions without explicit knowledge of the CIFS server’s NetBIOS name greatly increases the flexibility of the protocol. This functionality is already present in Windows NT 4.0, Windows NT 5.0, and Windows 98. However, flexible name resolution is not available in MS-DOS or earlier versions of the Windows operating systems.

Source

314.2 NetBIOS and WINS (weight: 7)

Description: Candidates should be familiar with NetBIOS/WINS concepts and understand network browsing

Key Knowledge Areas

  • Understand WINS concepts
  • Understand NetBIOS concepts
  • Understand the role of a local master browser
  • Understand the role of a domain master browser
  • Understand the role of Samba as a WINS server
  • Understand name resolution
  • Configure Samba as a WINS server
  • Configure WINS replication
  • Understand NetBIOS browsing, service announcements and elections

The following is a partial list of the used files, terms and utilities:

  • NetBIOS
  • WINS
  • local master browser
  • domain master browser
  • service announcements
  • elections
  • node types
  • smbclient
  • findsmb
  • name resolve order
  • lmhosts
  • smbtree

NetBIOS

The NetBIOS name is specified when Windows networking is installed/configured. In order to connect to a computer running TCP/IP via its NetBIOS name, the name must be resolved to a network address, usually today this is an IP address (the NetBIOS name-IP address resolution is often done by either broadcasts or a WINS Server — NetBIOS Name Server). A computer's NetBIOS name is often the same as that computer's host name (see below), but it doesn't have to be. NetBios names can include almost any combination of alphanumeric characters except for spaces or the following characters: \ / : * ? ” ; |

A Windows machine's NetBIOS name is not to be confused with the computer's host name. Generally a computer running TCP/IP (whether it's a Windows machine or not) has a host name (also sometimes called a machine name or a DNS name). Generally the host name of a Windows computer is based on the NetBIOS name plus the Primary DNS Suffix, which are both set in the System Control Panel.

There may also be “connection specific suffixes” which can be viewed or changed on the DNS tab in Control Panel → Network → TCP/IP → Advanced Properties. Host names are used by applications such as telnet, ftp, web browsers, etc. In order to connect to a computer running the TCP/IP protocol using its HOST name, the host name must be resolved into an IP Address. Host name- or Fully Qualified Domain Name (FQDN)-IP address resolution is typically done by a Domain Name System (DNS) server.

WINS

Windows Internet Name Service (WINS) is Microsoft's implementation of NetBIOS Name Server (NBNS) on Windows, a name server and service for NetBIOS computer names. Effectively, WINS is to NetBIOS names, what DNS is to domain names - a central mapping of host names to network addresses. However, the mappings are dynamically updated (e.g. at workstation boot), so that when a client needs to contact another computer on the network it can get its up-to-date DHCP-allocated address. Networks normally have more than one WINS server and each WINS server should be in push/pull replication; the favored replication model is the hub and spoke, thus the WINS design is not central but distributed. Each WINS server holds a full copy of every other related WINS system's records. There is no hierarchy in WINS (unlike DNS), but like DNS its database can be queried for the address to contact rather than broadcasting a request for which address to contact. The system therefore reduces broadcast traffic on the network, however replication traffic can add to WAN / LAN traffic.

As of Windows 2000, DNS provides the favored alternative to WINS, as part of Active Directory. [1]

In theory, if DNS is available, WINS is only necessary if pre-Windows 2000 clients or servers need to resolve names. In reality, especially in large enterprise environments, Exchange Server 2000 and 2003 often still require WINS for full functionality.

Samba can also act as a WINS (NBNS) server.

local master browser

The basic way browsing works is that one computer in the network takes on the role of the master browser (also called local master browser, browse master, or browse server) and keeps a list of all the computers on the local subnet that are acting as SMB servers. The list of computers is called the browse list and includes all Samba servers, Windows NT/2000/XP systems, and any Windows 95/98/Me systems that have the “File and printer sharing for Microsoft Networks” networking component installed. The browse list also contains the names of all workgroups and domains. At this level, browsing is limited to the local subnet because the browsing protocol depends on broadcast packets, which are typically not forwarded to other subnets by routers.

A user at any Windows system can view the browse list by opening up the Network Neighborhood (or My Network Places). Or, the net view command can be used from a Windows command prompt:

C:\>net view
Server Name            Remark

-------------------------------------------------------------------------------
\\MAYA                 Windows 98
\\MIXTEC               Samba 2.2.5
\\OLMEC                Windows XP Pro on Pentium/ASUS
\\TOLTEC               Samba 2.2.5
\\YAQUI                Windows 95 on mixtec/VMware
\\ZAPOTEC
The command completed successfully.

In a Windows NT domain, the primary domain controller is always the local master browser, and if it fails, another Windows NT/2000 server (if one exists) will take over the role of local master browser. Other versions of Windows can function as backup browsers, but will never become a master browser if a Windows NT/2000 server is available.

More information

domain master browser

In addition to acting as the local master browser, the primary domain controller also acts as the domain master browser, which ties subnets together and allows browse lists to be shared between master and backup browsers on separate subnets. This is how browsing is extended to function beyond the local subnet. Each subnet functions as a separate browsing entity, and the domain master browser synchronizes the master browsers of each subnet. In a Windows-only network, browsing cannot function across subnets unless a Windows NT/2000 PDC exists on the network. Samba can act as a domain master browser and can perform that task even in a workgroup network, which means that the Windows PDC is not required for this task. (It is also possible to use the remote browse sync parameter to configure a Samba server to synchronize its browse list with a Samba server on another subnet. In this case, each server must be acting as the local master browser of its subnet.)

Unless it is configured never to act as a browser, each computer on the subnet is considered a potential browser and can be ordered by the browse master to become a backup browser, or it can identify itself as a backup browser and accept the role on its own.

service announcements

All systems announces to the network which services (shares) they offer. These announcements are collected by the WINS server and registered.

The job of the WINS server is to resolve NetBIOS names to the IP addresses of the systems that registered them. The Local Master Browser listens for service announcements, collects them into a list, and delivers them to clients when asked. The Browse Service uses the Name Service, but they're otherwise unrelated.

elections

When no master browser is running on the subnet, potential browsers choose a new master browser among themselves in a process called an election. An election is started by a computer in the subnet when it discovers that no master browser is currently running. If a master browser is shut down gracefully, it will broadcast an election request datagram, initiating an election by the remaining computers. If the master browser fails, the election can be started by a client computer that requests a list of backup browsers from the master browser or by a backup browser that requests to have its browse list updated from the master browser. In each case, the system fails to receive a reply from the master browser and initiates the election.

Browser elections are decided in multiple rounds of self-elimination. During each round, potential browsers broadcast election request datagrams containing their qualifications to notify other potential browsers that an election is happening and that if the recipient is more qualified, it should also broadcast a bid. When a potential browser receives an election request datagram from a more qualified opponent, it drops out, disqualifying itself from becoming the master browser. Otherwise, it responds with its own election request datagram. After a few rounds, only one potential browser is left in the election. After an additional four rounds of sending out an election request datagram and receiving no response, it becomes the master browser and sends a broadcast datagram announcing itself as the local master browser for the subnet. It then assigns runners-up in the election as backup browsers, as needed.

A potential browser's qualifications include the following:

  • Whether it has recently lost an election
  • The version of the election protocol it is running
  • Its election criteria
  • The amount of time the system has been up
  • The computer's NetBIOS name

If the potential browser has lost an election recently, it immediately disqualifies itself. The version of the election protocol it is running is checked, but so far, all Windows systems (and Samba) use the same election protocol, so the check is not very meaningful. The election criteria are usually what determine which computer becomes the local master browser. There are two parts to the election criteria.

Operating-system values in an election

Operating systemValue
Windows NT/2000 Server, running as PDC32
Windows NT/2000/XP, if not the PDC16
Windows 95/98/Me1
Windows for Workgroups1

Computer-role settings in an election

RoleValue
Domain master browser128
WINS client32
Preferred master8
Running master4
Recent backup browser2
Backup browser1

The operating-system type is compared first, and the system with the highest value wins. The values have been chosen to cause the primary domain controller, if there is one, to become the local master browser. Otherwise, a Windows NT/2000/XP system will win over a Windows for Workgroups or Windows 95/98/Me system.

When an operating-system type comparison results in a tie, the role of the computer is compared. A computer can have more than one of the values in Table 7-3, in which case the values are added.

A domain master browser has a role value of 128 to weight the election so heavily in its favor that it will also become the local master browser on its own subnet. Although the primary domain controller (which is always the domain master browser) will win the election based solely on its operating system value, sometimes there is no primary domain controller on the network, and the domain master browser would not otherwise be distinguished from other potential browsers.

Systems that are using a WINS server for name resolution are weighted heavily over ones that use broadcast name resolution with a role value of 32.

A preferred master is a computer that has been selected and configured manually by a system administrator to be favored as the choice master browser. When a preferred master starts up, it forces a browser election, even if an existing master browser is still active. A preferred master has a role value of 8, and the existing master browser gets a value of 4.

A backup browser that has recently been a master browser and still has an up-to-date browse list is given a role value of 2, and a potential browser that has been running as a backup browser gets a value of 1.

If comparing the operating-system type and role results in a tie, the computer that has been running the longest wins. In the unlikely event that the two have been up for the same amount of time, the computer that wins is the one with the NetBIOS name that sorts first alphabetically.

node types

Windows Server supports the following node types:

  • B-node (broadcast): it uses broadcasts for name resolution and registration. In a large network, a broadcast increases the load of the network. In addition, usually routers stop all broadcasts to forward, so only computers within the local network will respond.
  • P-node (peer-to-peer): it uses NetBIOS name server such as WINS to resolve names of the NetBIOS. P-node does not work with broadcasts, because it directly query with the name server, enabling computers to resolve NetBIOS name across routers. P-node requires that all computers should be configured with the NetBIOS name server IP address. If the NetBIOS name server is not functioning, computers will not be able to communicate.
  • M-node (mixed): combines B-node and P-node, but functions as B-node by default. If M-node cannot resolve name using broadcast, then it uses the NetBIOS name server of P-node.
  • H-node (hybrid): combines P-node and B-node, but functions as P-node by default. If H-node cannot resolve name using a NetBIOS name server, then for resolving a name broadcast is used.

smbclient

Example of browsing a machine using smbclient

bash-3.2$ smbclient -L 192.168.0.140
Password:
Domain=[UNIVERSE-IN] OS=[Unix] Server=[Samba 3.0.25b]

        Sharename       Type      Comment
        ---------       ----      -------
        netlogon        Disk      Network Logon Service
        IPC$            IPC       IPC Service (aphrael)
Domain=[UNIVERSE-IN] OS=[Unix] Server=[Samba 3.0.25b]

        Server               Comment
        ---------            -------
        APHRAEL              aphrael
        KAHLAN               Kahlan
        KALTEN

        Workgroup            Master
        ---------            -------
        UNIVERSE-IN          APHRAEL

findsmb

findsmb - list info about machines that respond to SMB name queries on a subnet

bash-3.2$ findsmb

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION
---------------------------------------------------------------------
192.168.0.140   APHRAEL       *[UNIVERSE-IN] [Unix] [Samba 3.0.25b]
192.168.0.141   KAHLAN         [UNIVERSE-IN] [Unix] [Samba 3.0.25b]

name resolve order

This option is used by the programs in the Samba suite to determine what naming services to use and in what order to resolve host names to IP addresses. Its main purpose to is to control how netbios name resolution is performed. The option takes a space separated string of name resolution options.

The options are: “lmhosts”, “host”, “wins” and “bcast”. They cause names to be resolved as follows:

  • lmhosts : Lookup an IP address in the Samba lmhosts file. If the line in lmhosts has no name type attached to the NetBIOS name (see the manpage for lmhosts for details) then any name type matches for lookup.
  • host : Do a standard host name to IP address resolution, using the system /etc/hosts , NIS, or DNS lookups. This method

of name resolution is operating system depended for instance on IRIX or Solaris this may be controlled by the /etc/nsswitch.conf file. Note that this method is used only if the NetBIOS name type being queried is the 0×20 (server) name type or 0x1c (domain controllers). The latter case is only useful for active directory domains and results in a DNS query for the SRV RR entry matching _ldap._tcp.domain.

  • wins : Query a name with the IP address listed in the WINSSERVER parameter. If no WINS server has been specified this method will be ignored.
  • bcast : Do a broadcast on each of the known local interfaces listed in the interfaces parameter. This is the least reliable of the name resolution methods as it depends on the target host being on a locally connected subnet.

lmhosts

LMHOSTS is the standard LAN Manager hosts file used to resolve names into IP addresses on the system. It is the NBT equivalent of the /etc/hosts file that is standard on all Unix systems. By default, the file is usually stored as /usr/local/samba/lib/LMHOSTS and shares a format similar to /etc/hosts. For example:

192.168.220.100    hydra
192.168.220.101    phoenix

The only difference is that the names on the right side of the entries are NetBIOS names instead of DNS names. Because they are NetBIOS names, you can assign resource types to them as well:

192.168.220.100    hydra#20
192.168.220.100    simple#1b
192.168.220.101    phoenix#20

Here, we've assigned the hydra machine to be the primary domain controller of the SIMPLE domain, as indicated by the resource type <1B> assigned to the name after hydra's IP address in the second line. The other two are standard workstations.

If you wish to place an LMHOSTS file somewhere other than the default location, you will need to notify the nmbd process upon start up, as follows:

nmbd -H /etc/samba/lmhosts -D

smbtree

smbtree is a smb browser program in text mode. It is similar to the “Network Neighborhood” found on Windows computers. It prints a tree with all the known domains, the servers in those domains and the shares on the servers.

bash-3.2$ smbtree
Password:
UNIVERSE-IN
        \\KAHLAN                        Kahlan
                \\KAHLAN\username               Users home directories
                \\KAHLAN\IPC$                   IPC Service (Kahlan)
                \\KAHLAN\storage2               Storage for users
                \\KAHLAN\storage1               Storage for users
        \\APHRAEL                       aphrael
                \\APHRAEL\IPC$                  IPC Service (aphrael)
                \\APHRAEL\netlogon              Network Logon Service

314.3 Integrating with Active Directory (weight: 2)

Description: Candidates should be able to integrate Linux servers into an environment where Active Directory is present

Key Knowledge Areas

  • List remove Active Directory / LDAP users
  • Configure Samba in ADS security mode
  • Knowledge of the DNS requirements for Active Directory

The following is a partial list of the used files, terms and utilities:

  • Active Directory
  • ADS Security Mode
  • DNS
  • LDAP
  • Windows' net command
  • Kerberos
  • domain
  • smb.conf
  • smbcalcs

List remove Active Directory / LDAP users

Administration is done using the samba net utility List users

# net ads user

Remove user

# net ads user DELETE jan

Configure Samba in ADS security mode

Kerberos Configuration

Edit /etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EDMONSON.KETSDS.NET
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
default_tgs_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC
default_tkt_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC
preferred_enctypes = DES-CBC-CRC DES-CBC-MD5 RC4-HMAC

[realms]
EDMONSON.KETSDS.NET = {
kdc = ed151000d1.edmonson.ketsds.net
admin_server = 10.76.16.50:749
default_domain = edmonson.ketsds.net
}

[domain_realm]
.example.com = EDMONSON.KETSDS.NET
example.com = EDMONSON.KETSDS.NET
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

Now it is a good idea to add your domain controller to your /etc/hosts file. That way if something happens to DNS you can still resolve out to it.

SAMBA Configuration

We are on to editing the /etc/samba/smb.conf file. There are several things to add and change here (again case is important and bolded items are what needs changed or added):

change: workgroup = EDMONSON
add: realm = EDMONSON.KETSDS.NET
change: server string = Linux Samba File Server
change: security = ADS
change: encrypt passwords = yes
change: preferred master = no
add: template shell = /bin/false
add: template homedir = /home/%D/%U
add: idmap uid = 10000-20000
add: idmap gid = 10000-20000
add: enhanced browsing = no
add: winbind use default domain = yes

After you get those edited then it is a good idea to run testparm and correct any errors that you get. With just the changes that I posted above there shouldn’t be any errors. Next start SAMBA and join the machine to the domain using the commands:

/etc/init.d/smb start
net ads join -U bnorris@EDMONSON.KETSDS.NET

Again case is important. The program should ask you for your network password and then it should join the box to the network. If all went well you need to stop SAMBA while you finish up the pieces:

/etc/init.d/smb stop

Winbind Configuration

Now we need to edit /etc/nsswitch.conf and tell the machine to use Winbind to authenticate people.

change: passwd: files winbind
change: group: files winbind

Now we can start Winbind and SAMBA back up:

/etc/init.d/winbind start
/etc/init.d/smb start

Test to make sure it is working using wbinfo:

wbinfo -u
wbinfo -g

Those commands should give you a list of users and groups from your domain. If you have a particularly complex domain with lots of trusts and such to you might want to limit wbinfo to one domain with the –domain=EDMONSON option. If wbinfo hangs and never returns then you will need to stop and start Winbind in order to get it working again.

You can also get some info about your connection to the domain with:

net ads info

More information

Knowledge of the DNS requirements for Active Directory

When you install Active Directory on a member server, the member server is promoted to a domain controller. Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers.

During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS, which are necessary for the successful functionality of the domain controller locator (Locator) mechanism.

To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS resource records of the domain controller, which provide the client with the names and IP addresses of the domain controllers. In this context, the SRV and A resource records are referred to as Locator DNS resource records.

When adding a domain controller to a forest, you are updating a DNS zone hosted on a DNS server with the Locator DNS resource records and identifying the domain controller. For this reason, the DNS zone must allow dynamic updates (RFC 2136) and the DNS server hosting that zone must support the SRV resource records (RFC 2782) to advertise the Active Directory directory service. For more information about RFCs, see DNS RFCs.

If the DNS server hosting the authoritative DNS zone is not a server running Windows 2000 or Windows Server 2003, contact your DNS administrator to determine if the DNS server supports the required standards. If the server does not support the required standards, or the authoritative DNS zone cannot be configured to allow dynamic updates, then modification is required to your existing DNS infrastructure.

smbcalcs

The smbcacls program manipulates NT Access Control Lists (ACLs) on SMB file shares.

314.4 Working with Windows Clients (weight: 4)

Description: Clients should be able to interact with remote Windows clients, and configure Windows workstations to access file and print services from Linux servers

Key Knowledge Areas

  • Knowledge of Windows clients
  • Explore browse lists and SMB clients from Windows
  • Share file / print resources from Windows
  • Use of the smbclient program
  • Use of the Windows net utility

The following is a partial list of the used files, terms and utilities:

  • Windows' net command
  • smbclient
  • mount, smbmount
  • control panel
  • rdesktop
  • workgroup
  • smbget

Explore browse lists and SMB clients from Windows

Just open “My Networklocations”

Share file / print resources from Windows

Set up Sharing

Now select folder/s that you want to share across the swerdna workgroup using explorer: R-click start, select explore, find the folder/s, R-click the folder, select sharing and share this folder on a network, fill in share name and perhaps allow users to change my files (write access in addition to read access).

Do the above for each workstation. When you have finished and restarted all computers you should be able to see all shared Microsoft folders across the swerdna (or whatever you called it) workgroup by using the Microsoft workstation network browsers called My Nework Places.

Print Server:

Now share the printer across the workgroup as follows: Install the printer on the chosen workstation. Navigate to the printer e.g open control panel and select printers and faxes. R-click the icon for the printer and select sharing. Assign a share name. Finish.

For each workstation that will access the printer server do this: Open My Network Places or Network Neighbourhood, select view workgroup computers, select the print server (workstation) and you will see the shared printer. R-click on the printer icon and select install/connect. In most cases that's all. Sometimes you will be asked for the driver via an install screen from within the workstation. If so, insert the driver CD and either click install/whtever after the CD autostarts or cancel that and navigate the install screen to the driver folder on the CD. Finished. Restart and Test the printing.

Source

Use of the smbclient program

smbclient - ftp-like client to access SMB/CIFS resources on server

# smbclient \\\\172.16.1.3\\c$ -U jwhittal # put /etc/hosts # get pdf995\setup.exe

This uploads /etc/hosts and downloads setup.exe from the pdf995 directory

Use of the Windows net utility

Some options

NET VIEWDisplays a list of computers in a specified workgroup or the shared resources available on a specified computer.
NET USEConnects or disconnects your computer from a shared resource or displays information about your connections.
NET TIMEDisplays the time on or synchronizes your computer's clock with the shared clock on a Microsoft Windows for Workgroups, Windows NT, Windows 95, or NetWare time server.

More information

rdesktop

rdesktop is a client for Remote Desktop Protocol (RDP), used in a number of Microsoft products including Windows NT Terminal Server, Windows 2000 Server, Windows XP and Windows 2003 Server.

rdesktop -u jan -d OFFICE 10.0.0.1

smbget

smbget is a simple utility with wget-like semantics, that can download files from SMB servers. You can specify the files you would like to download on the command-line.

# Recursively download 'src' directory
smbget -R smb://rhonwyn/jelmer/src
# Download FreeBSD ISO and enable resuming
smbget -r smb://rhonwyn/isos/FreeBSD5.1.iso
# Recursively download all ISOs
smbget -Rr smb://rhonwyn/isos
# Backup my data on rhonwyn
smbget -Rr smb://rhonwyn/

Topic 315: Security and Performance

315.1 Linux File System and Share/Service Permissions (weight: 3)

Description: Candidates should understand file permissions on a Linux file system in a mixed environment

Key Knowledge Areas

  • Knowledge of file / directory permission control
  • Understand how Samba interacts with Linux file system permissions

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • chmod
  • chown
  • mount, smbmount
  • create mask
  • directory mask

chmod

chmod changes the file mode bits of each given file according to mode, which can be either a symbolic representation of changes to make, or an octal number representing the bit pattern for the new mode bits.

The operator + causes the selected file mode bits to be added to the existing file mode bits of each file; - causes them to be removed; and = causes them to be added and causes unmentioned bits to be removed except that a directory’s unmentioned set user and group ID bits are not affected.

The letters rwxXst select file mode bits for the affected users: read ®, write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t). Instead of one or more of these letters, you can specify exactly one of the letters ugo: the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file’s group (g), and the permissions granted to users that are in neither of the two preceding categories (o).

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros, except that if the first digit is omitted, a directory’s set user and group ID bits are not affected. The first digit selects the set user ID (4) and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file: read (4), write (2), and execute (1); the third selects permissions for other users in the file’s group, with the same values; and the fourth for other users not in the file’s group, with the same values.

Example

# ls -al testfile
-rw-r--r-- 1 jan admins 0 2007-10-25 00:49 testfile
# chmod 750 testfile
# ls -al testfile
-rwxr-x--- 1 jan admins 0 2007-10-25 00:49 testfile

This will see the user jan has read, write and execute rights on the file testfile, everyone in the group admins has read and execute rights on the file, everyone else has no rights.

chown

chown changes the user and/or group ownership of each given file. If only an owner (a user name or numeric user ID) is given, that user is made the owner of each given file, and the files’ group is not changed. If the owner is followed by a colon and a group name (or numeric group ID), with no spaces between them, the group ownership of the files is changed as well. If a colon but no group name follows the user name, that user is made the owner of the files and the group of the files is changed to that user’s login group. If the colon and group are given, but the owner is omitted, only the group of the files is changed; in this case, chown performs the same function as chgrp. If only a colon is given, or if the entire operand is empty, neither the owner nor the group is changed.

Example

# ls -al testfile
-rwxr-x--- 1 jan admins 0 2007-10-25 00:49 testfile
# chown piet.accountants testfile
# ls -al testfile
-rwxr-x--- 1 piet accountants 0 2007-10-25 00:49 testfile

mount, smbmount

uid=<arg> sets the uid that will own all files on the mounted filesystem. It may be specified as either a username or a numeric uid.

gid=<arg> sets the gid that will own all files on the mounted filesystem. It may be specified as either a groupname or a numeric gid.

For more options see the manual pages from smbmount

create mask

When a file is created, the necessary permissions are calculated according to the mapping from DOS modes to UNIX permissions, and the resulting UNIX mode is then bit-wise 'AND'ed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will be removed from the modes set on a file when it is created.

The default value of this parameter removes the group and other write and execute bits from the UNIX modes.

Following this Samba will bit-wise 'OR' the UNIX mode created from this parameter with the value of the force create mode parameter which is set to 000 by default.

This parameter does not affect directory masks.

directory mask

This parameter is the octal modes which are used when converting DOS modes to UNIX modes when creating UNIX directories.

When a directory is created, the necessary permissions are calculated according to the mapping from DOS modes to UNIX permissions, and the resulting UNIX mode is then bit-wise 'AND'ed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a directory. Any bit not set here will be removed from the modes set on a directory when it is created.

The default value of this parameter removes the 'group' and 'other' write bits from the UNIX mode, allowing only the user who owns the directory to modify it.

Following this Samba will bit-wise 'OR' the UNIX mode created from this parameter with the value of the force directory mode parameter. This parameter is set to 000 by default (i.e. no extra mode bits are added).

315.2 Samba Security (weight: 2)

Description: Candidates should be able to secure Samba at both the firewall level, and the Samba daemons themselves

Key Knowledge Areas

  • Configure access to and from a Samba server at the firewall level
  • Configure security relate parameters in the smb.conf file

The following is a partial list of the used files, terms and utilities:

  • iptables
  • smb.conf
  • /etc/services
  • security modes

iptables

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains. Iptables can be used as an firewall to protect samba machines.

Example (on firewall)

iptables -A FORWARD -p tcp --dport 139 -d 10.0.0.1 -j DROP
iptables -A FORWARD -p tcp --dport 445 -d 10.0.0.1 -j DROP
iptables -A FORWARD -p udp --dport 137 -d 10.0.0.1 -j DROP
iptables -A FORWARD -p udp --dport 138 -d 10.0.0.1 -j DROP

This will drop all udp- and tcp-based NETBIOS/SMB traffic directed at the samba server with ip 10.0.0.1

smb.conf

Only listen on specified interfaces

        bind interfaces only = Yes
        hosts deny = ALL
        hosts allow = 192.168.1.0/24 127.
        interfaces = eth0 lo

Use encrypted passwords, do not allow empty passwords and disable guest user

        encrypt passwords = Yes
        map to guest = Never
        null passwords = Yes

security modes

See section 310.2

315.3 Performance Tuning (weight: 1)

Description: Candidates should be able to cluster services for load balancing and high availability purposes, and tune Samba settings for better server and network performance

Key Knowledge Areas

  • Measure Samba performance
  • Optimize Samba memory usage
  • Improve file transfer speed in a SMB/CIFS environment

The following is a partial list of the used files, terms and utilities:

  • smb.conf
  • 'max *' parameters
  • netstat
  • smbstatus
  • socket options

Measure Samba performance

Benchmarking is an arcane and somewhat black art, but the level of expertise needed for simple performance tuning is fairly low. Since the Samba server's goal in life is to transfer files, we will examine only throughput, not response time to particular events, under the benchmarking microscope. After all, it's relatively easy to measure file transfer speed, and Samba doesn't suffer too badly from response-time problems that would require more sophisticated techniques.

Our basic strategy for this work will be:

  • Find a reasonably-sized file to copy and a program that reports on copy speeds, such as smbclient.
  • Find a quiet (or typical) time to do the test.
  • Pre-run each test a few times to preload buffers.
  • Run tests several times and watch for unusual results.
  • Record each run in detail.
  • Compare the average of the valid runs to expected values.

After establishing a baseline using this method, we can adjust a single parameter and do the measurements all over again. An empty table for your tests is provided at the end of this chapter.

smb.conf

Log level

This is an obvious one. Increasing the logging level ( log level or debug level configuration options) is a good way to debug a problem, unless you happen to be searching for a performance problem! As mentioned in Chapter 4, Disk Shares , Samba produces a ton of debugging messages at level 3 and above, and writing them to disk or syslog is a slow operation. In our smbclient/ftp tests, raising the log level from 0 to 3 cut the untuned get speed from 645.3 to 622.2KB/s, or roughly 5 percent. Higher log levels were even worse.

read raw and write raw

These are important performance configuration options; they enable Samba to use large reads and writes to the network, of up to 64KB in a single SMB request. They also require the largest SMB packet structures, SMBreadraw and SMBwriteraw, from which the options take their names. Note that this is not the same as a Unix raw read. This Unix term usually refers to reading disks without using the files system, quite a different sense from the one described here for Samba.

In the past, some client programs failed if you tried to use read raw. As far as we know, no client suffers from this problem any more. Read and write raw default to yes, and should be left on unless you find you have one of the buggy clients.

Opportunistic locking

Opportunistic locks, or oplocks, allow clients to cache files locally, improving performance on the order of 30 percent. This option is now enabled by default. For read-only files, the fake oplocks provides the same functionality without actually doing any caching. If you have files that cannot be cached, oplocks can be turned off.

Database files should never be cached, nor should any files that are updated both on the server and the client and whose changes must be immediately visible. For these files, the veto oplock files option allows you to specify a list of individual files or a pattern containing wildcards to avoid caching. oplocks can be turned off on a share-by-share basis if you have large groups of files you don't want cached on clients.

The following Samba options will affect performance if they're set incorrectly, much like the debug level. They're mentioned here so you will know what to look out for:

hide filesProviding a pattern to identify files hidden by the Windows client hide files will result in any file matching the pattern being passed to the client with the DOS hidden attribute set. It requires a pattern match per file when listing directories, and slows the server noticeably.
lpq cache timeIf your lpq (printer queue contents) command takes a long time to complete, you should increase lpq cache time to a value higher than the actual time required for lpq to execute, so as to keep Samba from starting a new query when one's already running. The default is 10 seconds, which is reasonable.
strict lockingSetting the strict locking option causes Samba to check for locks on every access, not just when asked to by the client. The option is primarily a bug-avoidance feature, and can prevent ill-behaved DOS and Windows applications from corrupting shared files. However, it is slow and should typically be avoided.
strict syncSetting strict sync will cause Samba to write each packet to disk and wait for the write to complete whenever the client sets the sync bit in a packet. Windows 98 Explorer sets the bit in all packets transmitted, so if you turn this on, anyone with Windows 98 will think Samba servers are horribly slow.
sync alwaysSetting sync always causes Samba to flush every write to disk. This is good if your server crashes constantly, but the performance costs are immense. SMB servers normally use oplocks and automatic reconnection to avoid the ill effects of crashes, so setting this option is not normally necessary.
wide linksTurning off wide links prevents Samba from following symbolic links in one file share to files that are not in the share. It is turned on by default, since following links in Unix is not a security problem. Turning it off requires extra processing on every file open. If you do turn off wide links, be sure to turn on getwd cache to cache some of the required data. There is also a follow symlinks option that can be turned off to prevent following any symbolic links at all. However, this option does not pose a performance problem.
getwd cacheThis option caches the path to the current directory, avoiding long tree-walks to discover it. It's a nice performance improvement on a printer server or if you've turned off wide links.

A good example smb.conf

[global] 
	log level = 1                      # Default is 0 
	socket options = TCP_NODELAY IPTOS_LOWDELAY 
	read raw = yes                     # Default 
	write raw = yes                    # Default 
	oplocks = yes                      # Default 
	max xmit = 65535                   # Default 
	dead time = 15                     # Default is 0
	getwd cache = yes
	lpq cache = 30

'max *' parameters

max xmit

In Samba, the option that is directly related with the MTU and window size is max xmit. This option sets the largest block of data Samba will try to write at any one time. It's sometimes known as the write size, although that is not the name of the Samba configuration option.

Because the percentage of each block required for overhead falls as the blocks get larger, max xmit is conventionally set as large as possible. It defaults to the protocol's upper limit, which is 64 kilobytes. The smallest value that doesn't cause significant slowdowns is 2048. If it is set low enough, it willlimit the largest packet size that Samba will be able to negotiate. This can be used to simulate a small MTU if you need to test an unreliable network connection. However, such a test should not be used in production for reducing the effective MTU.

max mux (G)

This option controls the maximum number of outstanding simultaneous SMB operations that Samba tells the client it will allow. You should never need to set this parameter.

max open files (G)

This parameter limits the maximum number of open files that one smbd(8) file serving process may have open for a client at any one time. The default for this parameter is set very high (10,000) as Samba uses only one bit per unopened file.

The limit of the number of open files is usually set by the UNIX per-process file descriptor limit rather than this parameter so you should never need to touch this parameter.

max smbd processes (G)

This parameter limits the maximum number of smbd(8) processes concurrently running on a system and is intended as a stopgap to prevent degrading service to clients in the event that the server has insufficient resources to handle more than this number of connections. Remember that under normal operating conditions, each user will have an smbd(8) associated with him or her to handle connections to all shares from a given host.

max stat cache size (G)

This parameter limits the size in memory of any stat cache being used to speed up case insensitive name mappings. This parameter is the number of kilobyte (1024) units the stat cache can use. A value of zero means unlimited which is not advised a&#1109; it can use a lot of memory. You should not need to change this parameter.

max ttl (G)

This option tells nmbd(8) what the default 'time to live' of NetBIOS names should be (in seconds) when nmbd is requesting a name using either a broadcast packet or from a WINS server. You should never need to change this parameter. The default is 3 days.

max wins ttl (G)

This option tells smbd(8) when acting as a WINS server (wins support = yes) what the maximum 'time to live' of NetBIOS names that nmbd will grant will be (in seconds). You should never need to change this parameter. The default is 6 days (518400 seconds).

max connections (S)

This option allows the number of simultaneous connections to a service to be limited. If max connections is greater than 0 then connections will be refused if this number of connections to the service are already open. A value of zero mean an unlimited number of connections may be made. Record lock files are used to implement this feature. The lock files will be stored in the directory specified by the lock directory option.

max log size (G)

This option (an integer in kilobytes) specifies the max size the log file should grow to. Samba periodically checks the size and if it is exceeded it will rename the file, adding a .old extension. A size of 0 means no limit.

max print jobs (S)

This parameter limits the maximum number of jobs allowable in a Samba printer queue at any given moment. If this number is exceeded, smbd(8) will remote “Out of Space” to the client.

max protocol (G)

The value of the parameter (a string) is the highest protocol level that will be supported by the server.

max reported print jobs (S)

This parameter limits the maximum number of jobs displayed in a port monitor for Samba printer queue at any given moment. If this number is exceeded, the excess jobs will not be shown. A value of zero means there is no limit on the number of print jobs reported.

netstat

Print network connections, routing tables, interface statistics, masquerade connections, and multicast memberships

You can use netstat to list the connections to our server, which is help full to where the originate from.

# netstat -anp | grep smb
tcp        0      0 192.168.0.141:139       0.0.0.0:*               LISTEN      6836/smbd
tcp        0      0 192.168.0.141:445       0.0.0.0:*               LISTEN      6836/smbd
tcp        0      0 127.0.0.1:38649         127.0.0.1:389           ESTABLISHED 6836/smbd
# netstat -anp | grep nmbd
udp        0      0 192.168.0.141:137       0.0.0.0:*                           6828/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           6828/nmbd
udp        0      0 192.168.0.141:138       0.0.0.0:*                           6828/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           6828/nmbd

smbstatus

Same as netstat only from the viewpoint of samba.

# smbstatus

Samba version 3.0.25b
PID     Username      Group         Machine
-------------------------------------------------------------------

Service      pid     machine       Connected at
-------------------------------------------------------

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------

socket options

The next thing to look at are the socket options configuration options. These are really host system tuning options, but they're set on a per-connection basis, and can be reset by Samba on the sockets it employs by adding socket options = option to the [global] section of your smb.conf file. Not all of these options are supported by all vendors; check your vendor's manual pages on setsockopt (1) or socket (5) for details.

The main options are:

TCP_NODELAYHave the server send as many packets as necessary to keep delay low. This is used on telnet connections to give good response time, and is used - somewhat counter-intuitively - to get good speed even when doing small requests or when acknowledgments are delayed (as seems to occur with Microsoft TCP/IP). This is worth a 30-50 percent speedup by itself. Incidentally, in Samba 2.0.4, socket options = TCP_NODELAY became the default value for that option.
IPTOS_LOWDELAYThis is another option that trades off throughput for lower delay, but which affects routers and other systems, not the server. All the IPTOS options are new; they're not supported by all operating systems and routers. If they are supported, set IPTOS_LOWDELAY whenever you set TCP_NODELAY.
SO_SNDBUF and SO_RCVBUFThe send and receive buffers can often be the reset to a value higher than that of the operating system. This yields a marginal increase of speed (until it reaches a point of diminishing returns).
SO_KEEPALIVEThis initiates a periodic (four-hour) check to see if the client has disappeared. Expired connections are addressed somewhat better with Samba's keepalive and dead time options. All three eventually arrange to close dead connections, returning unused memory and process-table entries to the operating system.

There are several other socket options you might look at, (e.g., SO_SNDLOWAT), but they vary in availability from vendor to vendor. You probably want to look at TCP/IP Illustrated if you're interested in exploring more of these options for performance tuning with Samba

Acknowledgments

Most of the information in this document was collected from different sites on the internet and was copied (un)modified. Some text was created by me and my colleagues. The copyright of the text in document remains by their owners and is noway claimed by me. If you wrote some of the text we copied, I like to thank you for your excellent work.

Nothing in this document should be published for commercial purposes without gaining the permission of the original copyright owners.

For questions about this document or if you want to help keep this document up-to-date, you can contact me at webmaster@universe-network.net

 
wiki/certification/lpic302.txt · Last modified: 2007/10/30 16:21 by ferry
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki