From 55abd936a838a4410899db76cb5530b0c4694dc9 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Wed, 10 Oct 2001 17:19:10 +0000 Subject: mega-merge from 2.2 (This used to be commit c76bf8ed3275e217d1b691879153fe9137bcbe38) --- docs/htmldocs/Samba-HOWTO-Collection.html | 6693 ++++++++++++++++------------- 1 file changed, 3636 insertions(+), 3057 deletions(-) (limited to 'docs/htmldocs/Samba-HOWTO-Collection.html') diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html index c7393bc71b..c4e4b2c74b 100644 --- a/docs/htmldocs/Samba-HOWTO-Collection.html +++ b/docs/htmldocs/Samba-HOWTO-Collection.html @@ -34,10 +34,14 @@ NAME="AEN4" >

Abstract

Last Update : Tue Jul 31 15:58:03 CDT 2001

This book is a collection of HOWTOs added to Samba documentation over the years. I try to ensure that all are current, but sometimes the is a larger job than one person can maintain. The most recent version of this document @@ -62,34 +66,34 @@ CLASS="TOC" >

1. How to Install and Test SAMBA
1.1. Step 0: Read the man pages
1.2. Step 1: Building the Binaries
1.3. Step 2: The all important step
1.4. Step 3: Create the smb configuration file.
1.5. Step 4: Test your config file with
1.6. Step 5: Starting the smbd and nmbd
1.6.1. Step 5a: Starting from inetd.conf
1.6.2. Step 5b. Alternative: starting it as a daemon
1.7. Step 6: Try listing the shares available on your server
1.8. Step 7: Try connecting with the unix client
1.9. Step 8: Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client
1.10. What If Things Don't Work?
1.10.1. Diagnosing Problems
1.10.2. Scope IDs
1.10.3. Choosing the Protocol Level
1.10.4. Printing from UNIX to a Client PC
1.10.5. Locking
1.10.6. Mapping Usernames
1.10.7. Other Character Sets
2. Integrating MS Windows networks with Samba
2.1. Agenda
2.2. Name Resolution in a pure Unix/Linux world
2.2.1. /etc/hosts
2.2.2. /etc/resolv.conf
2.2.3. /etc/host.conf
2.2.4. /etc/nsswitch.conf
2.3. Name resolution as used within MS Windows networking
2.3.1. The NetBIOS Name Cache
2.3.2. The LMHOSTS file
2.3.3. HOSTS file
2.3.4. DNS Lookup
2.3.5. WINS Lookup
2.4. How browsing functions and how to deploy stable and dependable browsing using Samba
2.5. MS Windows security options and how to configure Samba for seemless integration
2.5.1. Use MS Windows NT as an authentication server
2.5.2. Make Samba a member of an MS Windows NT security domain
2.5.3. Configure Samba as an authentication server
2.5.3.1. Users
2.5.3.2. MS Windows NT Machine Accounts
2.6. Configuration of Samba as ...Conclusions
3. LanMan and NT Password Encryption in Samba 2.xConfiguring PAM for distributed but centrally +managed authentication
3.1. IntroductionSamba and PAM
3.2. How does it work?Distributed Authentication
3.3. Important Notes About SecurityPAM Configuration in smb.conf
4. Hosting a Microsoft Distributed File System tree on Samba
3.3.1. Advantages of SMB Encryption4.1. Instructions
3.3.2. Advantages of non-encrypted passwords4.1.1. Notes
3.4. The smbpasswd file
3.5. The smbpasswd Command5. UNIX Permission Bits and Windows NT Access Control Lists
3.6. Setting up Samba to support LanManager Encryption5.1. Viewing and changing UNIX permissions using the NT + security dialogs
4. 5.2. Hosting a Microsoft Distributed File System tree on SambaHow to view file security on a Samba share
4.1. 5.3. InstructionsViewing file ownership
5.4. Viewing file or directory permissions
4.1.1. 5.4.1. NotesFile Permissions
5.4.2. Directory Permissions
5.5. Modifying file or directory permissions
5.6. Interaction with the standard Samba create mask + parameters
5.7. Interaction with the standard Samba file attribute + mapping
5. 6. Printing Support in Samba 2.2.x
5.1. 6.1. Introduction
5.2. 6.2. Configuration
5.2.1. 6.2.1. Creating [print$]
5.2.2. 6.2.2. Setting Drivers for Existing Printers
5.2.3. 6.2.3. Support a large number of printers
5.2.4. 6.2.4. Adding New Printers via the Windows NT APW
5.2.5. 6.2.5. Samba and Printer Ports
5.3. 6.3. The Imprints Toolset
5.3.1. 6.3.1. What is Imprints?
5.3.2. 6.3.2. Creating Printer Driver Packages
5.3.3. 6.3.3. The Imprints server
5.3.4. 6.3.4. The Installation Client
5.4. 6.4.
6. 7. security = domain in Samba 2.x
6.1. 7.1. Joining an NT Domain with Samba 2.2
6.2. 7.2. Samba and Windows 2000 Domains
6.3. 7.3. Why is this better than security = server?
7. 8. How to Configure Samba 2.2 as a Primary Domain Controller
7.1. 8.1. Prerequisite Reading
7.2. 8.2. Background
7.3. 8.3. Configuring the Samba Domain Controller
7.4. 8.4. Creating Machine Trust Accounts and Joining Clients to the Domain
7.4.1. 8.4.1. Manually creating machine trust accounts
7.4.2. 8.4.2. Creating machine trust accounts "on the fly"
7.5. 8.5. Common Problems and Errors
7.6. 8.6. System Policies and Profiles
7.7. 8.7. What other help can I get ?
7.8. 8.8. Domain Control for Windows 9x/ME
7.8.1. 8.8.1. Configuration Instructions: Network Logons
7.8.2. 8.8.2. Configuration Instructions: Setting up Roaming User Profiles
7.8.2.1. 8.8.2.1. Windows NT Configuration
7.8.2.2. 8.8.2.2. Windows 9X Configuration
7.8.2.3. 8.8.2.3. Win9X and WinNT Configuration
7.8.2.4. 8.8.2.4. Windows 9X Profile Setup
7.8.2.5. 8.8.2.5. Windows NT Workstation 4.0
7.8.2.6. 8.8.2.6. Windows NT Server
7.8.2.7. 8.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0
7.9. 8.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba
8. Unifed Logons between Windows NT and UNIX using Winbind9. Unified Logons between Windows NT and UNIX using Winbind
8.1. 9.1. Abstract
8.2. 9.2. Introduction
8.3. 9.3. What Winbind Provides
8.3.1. 9.3.1. Target Uses
8.4. 9.4. How Winbind Works
8.4.1. 9.4.1. Microsoft Remote Procedure Calls
8.4.2. 9.4.2. Name Service Switch
8.4.3. 9.4.3. Pluggable Authentication Modules
8.4.4. 9.4.4. User and Group ID Allocation
8.4.5. 9.4.5. Result Caching
8.5. 9.5. Installation and Configuration
8.6. Limitations9.5.1. Introduction
8.7. Conclusion9.5.2. Requirements
9. UNIX Permission Bits and WIndows NT Access Control Lists9.5.3. Testing Things Out
9.1. Viewing and changing UNIX permissions using the NT - security dialogs9.5.3.1. Configure and compile SAMBA
9.2. How to view file security on a Samba share9.5.3.2. Configure nsswitch.conf and the winbind libraries
9.3. Viewing file ownership9.5.3.3. Configure smb.conf
9.4. Viewing file or directory permissions9.5.3.4. Join the SAMBA server to the PDC domain
9.4.1. File Permissions9.5.3.5. Start up the winbindd daemon and test it!
9.4.2. Directory Permissions9.5.3.6. Fix the /etc/rc.d/init.d/smb startup files
9.5. Modifying file or directory permissions9.5.3.7. Configure Winbind and PAM
9.6. Interaction with the standard Samba create mask - parametersLimitations
9.7. Interaction with the standard Samba file attribute - mappingConclusion
10. OS2 Client HOWTO
10.1. FAQs
10.1.1. How can I configure OS/2 Warp Connect or OS/2 Warp 4 as a client for Samba?
10.1.2. How can I configure OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x for Samba?
10.1.3. Are there any other issues when OS/2 (any version) is used as a client?
10.1.4. How do I get printer driver download working for OS/2 clients?
11. HOWTO Access Samba source code via CVS
11.1. Introduction
11.2. CVS Access to samba.org
11.2.1. Access via CVSweb
11.2.2. Access via cvs
Index

Chapter 1. How to Install and Test SAMBA

1.1. Step 0: Read the man pages

1.2. Step 1: Building the Binaries

first to see what special options you can enable. - Then exectuting

1.3. Step 2: The all important step

1.4. Step 3: Create the smb configuration file.

which would allow connections by anyone with an account on the server, using either their login name or "homes" as the service name. (Note that I also set the - workgroup that Samba is part of. See BROWSING.txt for defails)

Note that

1.5. Step 4: Test your config file with

Make sure it runs OK and that the services look - resonable before proceeding.

1.6. Step 5: Starting the smbd and nmbd

1.6.1. Step 5a: Starting from inetd.conf

/etc/inetd.conf to make them consistant.

to make them consistent.

NOTE: On many systems you may need to use the "interfaces" option in smb.conf to specify the IP address @@ -1220,7 +1256,7 @@ CLASS="COMMAND" CLASS="COMMAND" >nmbd tries to determine it at run - time, but fails on somunixes. See the section on "testing nmbd" + time, but fails on some unixes. See the section on "testing nmbd" for a method of finding if you need to do this.

!!!WARNING!!! Many unixes only accept around 5 @@ -1249,7 +1285,7 @@ CLASS="SECT2" >

1.6.2. Step 5b. Alternative: starting it as a daemon

1.7. Step 6: Try listing the shares available on your server

1.8. Step 7: Try connecting with the unix client

1.9. Step 8: Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client

1.10. What If Things Don't Work?

1.10.1. Diagnosing Problems

If you have instalation problems then go to +>If you have installation problems then go to DIAGNOSIS.txt

1.10.2. Scope IDs

1.10.3. Choosing the Protocol Level

1.10.4. Printing from UNIX to a Client PC

1.10.5. Locking

Samba supports "record locking" using the fcntl() unix system - call. This is often implemented using rpc calls to a rpc.lockd process - running on the system that owns the filesystem. Unfortunately many - rpc.lockd implementations are very buggy, particularly when made to - talk to versions from other vendors. It is not uncommon for the - rpc.lockd to crash.

There is also a problem translating the 32 bit lock - requests generated by PC clients to 31 bit requests supported - by most unixes. Unfortunately many PC applications (typically - OLE2 applications) use byte ranges with the top bit set - as semaphore sets. Samba attempts translation to support - these types of applications, and the translation has proved - to be quite successful.

Record locking semantics under Unix is very + different from record locking under Windows. Versions + of Samba before 2.2 have tried to use the native + fcntl() unix system call to implement proper record + locking between different Samba clients. This can not + be fully correct due to several reasons. The simplest + is the fact that a Windows client is allowed to lock a + byte range up to 2^32 or 2^64, depending on the client + OS. The unix locking only supports byte ranges up to + 2^31. So it is not possible to correctly satisfy a + lock request above 2^31. There are many more + differences, too many to be listed here.

Samba 2.2 and above implements record locking + completely independent of the underlying unix + system. If a byte range lock that the client requests + happens to fall into the range 0-2^31, Samba hands + this request down to the Unix system. All other locks + can not be seen by unix anyway.

Strictly a SMB server should check for locks before every read and write call on a file. Unfortunately with the @@ -1629,7 +1670,7 @@ NAME="AEN196" are set by an application when it opens a file to determine what types of access should be allowed simultaneously with its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE - or DENY_ALL. There are also special compatability modes called + or DENY_ALL. There are also special compatibility modes called DENY_FCB and DENY_DOS.

You can disable share modes using "share modes = no". @@ -1643,7 +1684,7 @@ CLASS="SECT2" >

1.10.6. Mapping Usernames

1.10.7. Other Character Sets

If you have problems using filenames with accented characters in them (like the German, French or Scandinavian - character sets) then I recommmend you look at the "valid chars" + character sets) then I recommend you look at the "valid chars" option in smb.conf and also take a look at the validchars package in the examples directory.

Chapter 2. Integrating MS Windows networks with Samba

2.1. Agenda

2.2. Name Resolution in a pure Unix/Linux world

The key configuration files :

The key configuration files covered in this section are:

  • /etc/hosts

  • /etc/resolv.conf

  • /etc/host.conf

  • /etc/nsswitch.conf

2.2.1. /etc/hosts

2.2.2. /etc/resolv.conf

2.2.3. /etc/host.conf

2.2.4. /etc/nsswitch.conf

2.3. Name resolution as used within MS Windows networking

2.3.1. The NetBIOS Name Cache

2.3.2. The LMHOSTS file

2.3.3. HOSTS file

2.3.4. DNS Lookup

2.3.5. WINS Lookup

Refer to above details for section DNS Lookups. A -WINS (Windows Internet Name Server) service is the equivaent of the +>A WINS (Windows Internet Name Server) service is the equivaent of the rfc1001/1002 specified NBNS (NetBIOS Name Server). A WINS server stores the names and IP addresses that are registered by a Windows client if the TCP/IP setup has been given at least one WINS Server IP Address.

	wins support = No
-	wins server = xxx.xxx.xxx.xxx

2.4. How browsing functions and how to deploy stable and dependable browsing using Samba

2.5. MS Windows security options and how to configure Samba for seemless integration

MS Windows clients may use encrypted passwords alone, or encrypted -as well as plain text passwords in the authentication process. It -should be realized that with the SMB protocol the password is passed -over the network either in plain text or encrypted. When encrypted -passwords are used a password that has been entered by the user is -encrypted in two ways:

MS Windows clients may use encrypted passwords as part of a +challenege/response authentication model (a.k.a. NTLMv1) or +alone, or clear text strings for simple password based +authentication. It should be realized that with the SMB +protocol the password is passed over the network either +in plain text or encrypted, but not both in the same +authentication requets.

When encrypted passwords are used a password that has been +entered by the user is encrypted in two ways:

  • The case preserved password is encrypted - using an MD5/DES one way hash +>An MD4 hash of the UNICODE of the password + string. This is known as the NT hash.

  • The case is converted to upper case and then - encrypted using an MD5/DES one way hash

    The password is converted to upper case, + and then padded or trucated to 14 bytes. This string is + then appended with 5 bytes of NULL characters and split to + form two 56 bit DES keys to encrypt a "magic" 8 byte value. + The resulting 16 bytes for the LanMan hash. +

Both of these enrypted passwords are sent over the network -in the one authentication datagram.

You should refer to the Password Encryption chapter in this HOWTO collection +for more details on the inner workings

MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0 pre-service pack 3 will use either mode of @@ -2461,8 +2538,10 @@ the remote authentication server does not support encrypted passwords. This means that it is definitely not a good idea to re-enable plain text password support in such clients.

It is recommended that the following parameters be added to the -smb.conf file:

The following parameters can be used to work around the +issue of Windows 9x client upper casing usernames and +password before transmitting them to the SMB server +when using clear text authentication.

	passsword level = 8
-	username level = 8
passsword level = integer + username level = integer

these configuration parameters will compensate for the fact that -in some circumstances MS Windows and MS DOS clients may twiddle the -password that has been supplied by the user by converting characters to -upper case. The above entries will try every combination of upper and -lower case for the first 8 characters. Please refer to the man page -for smb.conf for more information on use of these parameters.

By default Samba will lower case the username before attempting +to lookup the user in the database of local system accounts. +Because UNIX usernames conventionally only contain lower case +character, the username level parameter +is rarely even needed.

However, password on UNIX systems often make use of mixed case +characters. This means that in order for a user on a Windows 9x +client to connect to a Samba server using clear text authentication, +the password level must be set to the maximum +number of upper case letter which could appear +is a password. Note that is the server OS uses the traditional +DES version of crypt(), then a password level +of 8 will result in case insensitive passwords as seen from Windows +users. This will also result in longer login times as Samba +hash to compute the permutations of the password string and +try them one by one until a match is located (or all combinations fail).

The best option to adopt is to enable support for encrypted passwords where ever Samba is used. There are three configuration possibilities @@ -2494,7 +2619,7 @@ CLASS="SECT2" >

2.5.1. Use MS Windows NT as an authentication server

2.5.2. Make Samba a member of an MS Windows NT security domain

Use of this mode of authentication does require there to be -a standard Unix account for the user, this account can be -blocked to prevent logons by other than MS Windows clients.

/etc/passwd entry.

An alternative to assigning UIDs to Windows users on a +Samba member server is presented in the Winbind Overview chapter in +this HOWTO collection.

2.5.3. Configure Samba as an authentication server

	encrypt passwords = Yes
-	security = user
## please refer to the Samba PDC HOWTO chapter later in +## this collection for more details +[global] + encrypt passwords = Yes + security = user + domain logons = Yes + ; an OS level of 33 or more is recommended + os level = 33 + +[NETLOGON] + path = /somewhare/in/file/system + read only = yes

2.5.3.1. Users

	# useradd -s /bin/bash -d /home/"userid" -m
+>	# useradd -s /bin/bash -d /home/"userid" -m "userid"
 	# passwd "userid"
-	  Enter Password: pass
+	  Enter Password: <pw>
 	  
 	# smbpasswd -a "userid"
-	  Enter Password: pass

2.5.3.2. MS Windows NT Machine Accounts

	# useradd -a /bin/false -d /dev/null "machine_name"\$
+>	# useradd -s /bin/false -d /dev/null "machine_name"\$
 	# passwd -l "machine_name"\$
 	# smbpasswd -a -m "machine_name"

2.6. Configuration of Samba as ...2.6. Conclusions

Samba provides a flexible means to operate as...

  • An MS Windows NT 3.x/4.0 security domain member - - Refer to the previous section(s) above. +>An MS Windows NT 3.x/4.0 security domain member.

  • An alternative to an MS Windows NT 3.x/4.0 - Domain Controller - In the smb.conf file the following parameters - should be added:

## please refer to the Samba PDC HOWTO chapter later in 
-## this collection for more details
-[global]
-	domain logons = Yes
-	; an OS level of 33 or more is recommended
-	os level = 33
-
-	[NETLOGON]
-		path = /somewhare/in/file/system
-		read only = yes
-		available = yes

Chapter 3. LanMan and NT Password Encryption in Samba 2.xChapter 3. Configuring PAM for distributed but centrally +managed authentication

3.1. Introduction

With the development of LanManager and Windows NT - compatible password encryption for Samba, it is now able - to validate user connections in exactly the same way as - a LanManager or Windows NT server.

This document describes how the SMB password encryption - algorithm works and what issues there are in choosing whether - you want to use it. You should read it carefully, especially - the part about security and the "PROS and CONS" section.

3.2. How does it work?3.1. Samba and PAM

LanManager encryption is somewhat similar to UNIX - password encryption. The server uses a file containing a - hashed value of a user's password. This is created by taking - the user's plaintext password, capitalising it, and either - truncating to 14 bytes or padding to 14 bytes with null bytes. - This 14 byte value is used as two 56 bit DES keys to encrypt - a 'magic' eight byte value, forming a 16 byte value which is - stored by the server and client. Let this value be known as - the "hashed password".

Windows NT encryption is a higher quality mechanism, - consisting of doing an MD4 hash on a Unicode version of the user's - password. This also produces a 16 byte hash value that is - non-reversible.

When a client (LanManager, Windows for WorkGroups, Windows - 95 or Windows NT) wishes to mount a Samba drive (or use a Samba - resource), it first requests a connection and negotiates the - protocol that the client and server will use. In the reply to this - request the Samba server generates and appends an 8 byte, random - value - this is stored in the Samba server after the reply is sent - and is known as the "challenge". The challenge is different for - every client connection.

The client then uses the hashed password (16 byte values - described above), appended with 5 null bytes, as three 56 bit - DES keys, each of which is used to encrypt the challenge 8 byte - value, forming a 24 byte value known as the "response".

In the SMB call SMBsessionsetupX (when user level security - is selected) or the call SMBtconX (when share level security is - selected), the 24 byte response is returned by the client to the - Samba server. For Windows NT protocol levels the above calculation - is done on both hashes of the user's password and both responses are - returned in the SMB call, giving two 24 byte values.

The Samba server then reproduces the above calculation, using - its own stored value of the 16 byte hashed password (read from the - A number of Unix systems (eg: 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 (smbpasswd file - described later) and the challenge - value that it kept from the negotiate protocol reply. It then checks - to see if the 24 byte value it calculates matches the 24 byte value - returned to it from the client.

If these values match exactly, then the client knew the - correct password (or the 16 byte hashed value - see security note - below) and is thus allowed access. If not, then the client did not - know the correct password and is denied access.

/etc/passwd) +would require the provision of alternatives for all programs that provide +security services. Such a choice would involve provision of +alternatives to such programs as: login, +passwd, chown, etc.

Note that the Samba server never knows or stores the cleartext - of the user's password - just the 16 byte hashed values derived from - it. Also note that the cleartext password or 16 byte hashed values - are never transmitted over the network - thus increasing security.

3.3. Important Notes About Security

PAM provides a mechanism that disconnects these security programs +from the underlying authentication/authorization infrastructure. +PAM is configured either through one file /etc/pam.conf (Solaris), +or by editing individual files that are located in /etc/pam.d.

The unix and SMB password encryption techniques seem similar - on the surface. This similarity is, however, only skin deep. The unix - scheme typically sends clear text passwords over the nextwork when - logging in. This is bad. The SMB encryption scheme never sends the - cleartext password over the network but it does store the 16 byte - hashed values on disk. This is also bad. Why? Because the 16 byte hashed - values are a "password equivalent". You cannot derive the user's - password from them, but they could potentially be used in a modified - client to gain access to a server. This would require considerable - technical knowledge on behalf of the attacker but is perfectly possible. - You should thus treat the smbpasswd file as though it contained the - cleartext passwords of all your users. Its contents must be kept - secret, and the file should be protected accordingly.

Ideally we would like a password scheme which neither requires - plain text passwords on the net or on disk. Unfortunately this - is not available as Samba is stuck with being compatible with - other SMB systems (WinNT, WfWg, Win95 etc).

The following is an example /etc/pam.d/login configuration file. +This example had all options been uncommented is probably not usable +as it stacks many conditions before allowing successful completion +of the login process. Essentially all conditions can be disabled +by commenting them out except the calls to pam_pwdb.so.

Warning
#%PAM-1.0
+# The PAM configuration file for the `login' service
+#
+auth 		required	pam_securetty.so
+auth 		required	pam_nologin.so
+# auth 		required	pam_dialup.so
+# auth 		optional	pam_mail.so
+auth		required	pam_pwdb.so shadow md5
+# account    	requisite  	pam_time.so
+account		required	pam_pwdb.so
+session		required	pam_pwdb.so
+# session 	optional	pam_lastlog.so
+# password   	required   	pam_cracklib.so retry=3
+password	required	pam_pwdb.so shadow md5

Note that Windows NT 4.0 Service pack 3 changed the - default for permissible authentication so that plaintext - passwords are never sent over the wire. - The solution to this is either to switch to encrypted passwords - with Samba or edit the Windows NT registry to re-enable plaintext - passwords. See the document WinNT.txt for details on how to do - this.

Other Microsoft operating systems which also exhibit - this behavior includes

  • MS DOS Network client 3.0 with - the basic network redirector installed

  • Windows 95 with the network redirector - update installed

  • Windows 98 [se]

  • Windows 2000

PAM allows use of replacable modules. Those available on a +sample system include:

Note :All current release of - Microsoft SMB/CIFS clients support authentication via the - SMB Challenge/Response mechanism described here. Enabling - clear text authentication does not disable the ability - of the client to particpate in encrypted authentication.

$ /bin/ls /lib/security
+pam_access.so    pam_ftp.so          pam_limits.so     
+pam_ncp_auth.so  pam_rhosts_auth.so  pam_stress.so     
+pam_cracklib.so  pam_group.so        pam_listfile.so   
+pam_nologin.so   pam_rootok.so       pam_tally.so      
+pam_deny.so      pam_issue.so        pam_mail.so       
+pam_permit.so    pam_securetty.so    pam_time.so       
+pam_dialup.so    pam_lastlog.so      pam_mkhomedir.so  
+pam_pwdb.so      pam_shells.so       pam_unix.so       
+pam_env.so       pam_ldap.so         pam_motd.so       
+pam_radius.so    pam_smbpass.so      pam_unix_acct.so  
+pam_wheel.so     pam_unix_auth.so    pam_unix_passwd.so
+pam_userdb.so    pam_warn.so         pam_unix_session.so

3.3.1. Advantages of SMB Encryption

  • plain text passwords are not passed across - the network. Someone using a network sniffer cannot just - record passwords going to the SMB server.

  • WinNT doesn't like talking to a server - that isn't using SMB encrypted passwords. It will refuse - to browse the server if the server is also in user level - security mode. It will insist on prompting the user for the - password on each connection, which is very annoying. The - only things you can do to stop this is to use SMB encryption. -

3.3.2. Advantages of non-encrypted passwords

  • plain text passwords are not kept - on disk.

  • uses same password file as other unix - services such as login and ftp

  • you are probably already using other - services (such as telnet and ftp) which send plain text - passwords over the net, so sending them for SMB isn't - such a big deal.

3.4. The smbpasswd file

In order for Samba to participate in the above protocol - it must be able to look up the 16 byte hashed values given a user name. - Unfortunately, as the UNIX password value is also a one way hash - function (ie. it is impossible to retrieve the cleartext of the user's - password given the UNIX hash of it), a separate password file - containing this 16 byte value must be kept. To minimise problems with - these two password files, getting out of sync, the UNIX /etc/passwd and the The following example for the login program replaces the use of +the smbpasswd file, - a utility, mksmbpasswd.sh, is provided to generate - a smbpasswd file from a UNIX pam_pwdb.so module which uses the system +password database (/etc/passwd file. -

To generate the smbpasswd file from your , +/etc/passwd - file use the following command :

$ cat /etc/passwd | mksmbpasswd.sh - > /usr/local/samba/private/smbpasswd

If you are running on a system that uses NIS, use

$ ypcat passwd | mksmbpasswd.sh - > /usr/local/samba/private/smbpasswd

The mksmbpasswd.sh program is found in - the Samba source directory. By default, the smbpasswd file is - stored in :

/etc/shadow, /etc/group) with +the module pam_smbpass.so which uses the Samba +database which contains the Microsoft MD4 encrypted password +hashes. This database is stored in either +/usr/local/samba/private/smbpasswd

The owner of the , +/usr/local/samba/private/ - directory should be set to root, and the permissions on it should - be set to 0500 (chmod 500 /usr/local/samba/private). -

Likewise, the smbpasswd file inside the private directory should - be owned by root and the permissions on is should be set to 0600 - (/etc/samba/smbpasswd, or in +/etc/samba.d/smbpasswd, depending on the +Samba implementation for your Unix/Linux system. The +pam_smbpass.so module is provided by +Samba version 2.2.1 or later. It can be compiled only if the +--with-pam --with-pam_smbpass options are both +provided to the Samba chmod 600 smbpasswd).

The format of the smbpasswd file is (The line has been - wrapped here. It should appear as one entry per line in - your smbpasswd file.)

configure program.

username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
-	[Account type]:LCT-<last-change-time>:Long name
-
#%PAM-1.0 +# The PAM configuration file for the `login' service +# +auth required pam_smbpass.so nodelay +account required pam_smbpass.so nodelay +session required pam_smbpass.so nodelay +password required pam_smbpass.so nodelay

Although only the username, - uid, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, - [Account type] and last-change-time sections are significant - and are looked at in the Samba code.

It is VITALLY important that there by 32 - 'X' characters between the two ':' characters in the XXX sections - - the smbpasswd and Samba code will fail to validate any entries that - do not have 32 characters between ':' characters. The first XXX - section is for the Lanman password hash, the second is for the - Windows NT version.

When the password file is created all users have password entries - consisting of 32 'X' characters. By default this disallows any access - as this user. When a user has a password set, the 'X' characters change - to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii - representation of the 16 byte hashed value of a user's password.

To set a user to have no password (not recommended), edit the file - using vi, and replace the first 11 characters with the ascii text - "NO PASSWORD" (minus the quotes).

For example, to clear the password for user bob, his smbpasswd file - entry would look like :

The following is the PAM configuration file for a particular +Linux system. The default condition uses pam_pwdb.so.

	bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U          ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
-
#%PAM-1.0 +# The PAM configuration file for the `samba' service +# +auth required /lib/security/pam_pwdb.so nullok nodelay shadow audit +account required /lib/security/pam_pwdb.so audit nodelay +session required /lib/security/pam_pwdb.so nodelay +password required /lib/security/pam_pwdb.so shadow md5

If you are allowing users to use the smbpasswd command to set - their own passwords, you may want to give users NO PASSWORD initially - so they do not have to enter a previous password when changing to their - new password (not recommended). In order for you to allow this the - smbpasswd program must be able to connect to the - smbd daemon as that user with no password. Enable this - by adding the line :

In the following example the decision has been made to use the +smbpasswd database even for basic samba authentication. Such a +decision could also be made for the passwd program and would +thus allow the smbpasswd passwords to be changed using the passwd +program.

null passwords = yes
#%PAM-1.0
+# The PAM configuration file for the `samba' service
+#
+auth       required     /lib/security/pam_smbpass.so nodelay
+account    required     /lib/security/pam_pwdb.so audit nodelay
+session    required     /lib/security/pam_pwdb.so nodelay
+password   required     /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf

to the [global] section of the smb.conf file (this is why - the above scenario is not recommended). Preferably, allocate your - users a default password to begin with, so you do not have - to enable this on your server.

Note : This file should be protected very - carefully. Anyone with access to this file can (with enough knowledge of - the protocols) gain access to your SMB server. The file is thus more - sensitive than a normal unix Note: PAM allows stacking of authentication mechanisms. It is +also possible to pass information obtained within on PAM module through +to the next module in the PAM stack. Please refer to the documentation for +your particular system implementation for details regarding the specific +capabilities of PAM in this environment. Some Linux implmentations also +provide the /etc/passwd file.

pam_stack.so module that allows all +authentication to be configured in a single central file. The +pam_stack.so method has some very devoted followers +on the basis that it allows for easier administration. As with all issues in +life though, every decision makes trade-offs, so you may want examine the +PAM documentation for further helpful information.

3.5. The smbpasswd Command3.2. Distributed Authentication

The smbpasswd command maintains the two 32 byte password fields - in the smbpasswd file. If you wish to make it similar to the unix - passwd or yppasswd programs, - install it in /usr/local/samba/bin/ (or your - main Samba binary directory).

Note that as of Samba 1.9.18p4 this program MUST NOT - BE INSTALLED setuid root (the new The astute administrator will realize from this that the +combination of pam_smbpass.so, +smbpasswd - code enforces this restriction so it cannot be run this way by - accident).

winbindd, and smbpasswd now works in a client-server mode - where it contacts the local smbd to change the user's password on its - behalf. This has enormous benefits - as follows.

  • smbpasswd no longer has to be setuid root - - an enormous range of potential security problems is - eliminated.

  • smbpasswd now has the capability - to change passwords on Windows NT servers (this only works when - the request is sent to the NT Primary Domain Controller if you - are changing an NT Domain user's password).

To run smbpasswd as a normal user just type :

$ smbpasswd

Old SMB password: <type old value here - - or hit return if there was no old password>

New SMB Password: <type new value> -

Repeat New SMB Password: <re-type new value -

If the old value does not match the current value stored for - that user, or the two new values do not match each other, then the - password will not be changed.

If invoked by an ordinary user it will only allow the user - to change his or her own Samba password.

If run by the root user smbpasswd may take an optional - argument, specifying the user name whose SMB password you wish to - change. Note that when run as root smbpasswd does not prompt for - or check the old password value, thus allowing root to set passwords - for users who have forgotten their passwords.

smbpasswd is designed to work in the same way - and be familiar to UNIX users who use the passwd or - yppasswd commands.

For more details on using smbpasswd refer - to the man page which will always be the definitive reference.

rsync (see +http://rsync.samba.org/) +will allow the establishment of a centrally managed, distributed +user/password database that can also be used by all +PAM (eg: Linux) aware programs and applications. This arrangement +can have particularly potent advantages compared with the +use of Microsoft Active Directory Service (ADS) in so far as +reduction of wide area network authentication traffic.

3.6. Setting up Samba to support LanManager Encryption3.3. PAM Configuration in smb.conf

This is a very brief description on how to setup samba to - support password encryption.

  1. There is an option in smb.conf called obey pam restrictions. +The following is from the on-line help for this option in SWAT;

    compile and install samba as usual

  2. When Samba 2.2 is configure to enable PAM support (i.e. +--with-pam), this parameter will +control whether or not Samba should obey PAM's account +and session management directives. The default behavior +is to use PAM for clear text authentication only and to +ignore any account or session management. Note that Samba always +ignores PAM for authentication in the case of +encrypt passwords = yes. +The reason is that PAM modules cannot support the challenge/response +authentication mechanism needed in the presence of SMB +password encryption.

    enable encrypted passwords in smb.conf by adding the line Default: encrypt - passwords = yes in the [global] section

  3. create the initial smbpasswd - password file in the place you specified in the Makefile - (--prefix=<dir>). See the notes under the The smbpasswd File - section earlier in the document for details.

Note that you can test things using smbclient.

obey pam restrictions = no

Chapter 4. Hosting a Microsoft Distributed File System tree on Samba

4.1. Instructions

4.1.1. Notes

Chapter 5. Printing Support in Samba 2.2.xChapter 5. UNIX Permission Bits and Windows NT Access Control Lists

5.1. Introduction5.1. Viewing and changing UNIX permissions using the NT + security dialogs

Beginning with the 2.2.0 release, Samba supports -the native Windows NT printing mechanisms implemented via -MS-RPC (i.e. the SPOOLSS named pipe). Previous versions of -Samba only supported LanMan printing calls.

The additional functionality provided by the new -SPOOLSS support includes:

  • Support for downloading printer driver - files to Windows 95/98/NT/2000 clients upon demand. -

  • Uploading of printer drivers via the - Windows NT Add Printer Wizard (APW) or the - Imprints tool set (refer to http://imprints.sourceforge.net). -

  • Support for the native MS-RPC printing - calls such as StartDocPrinter, EnumJobs(), etc... (See - the MSDN documentation at http://msdn.microsoft.com/ - for more information on the Win32 printing API) -

  • Support for NT Access Control Lists (ACL) - on printer objects

  • Improved support for printer queue manipulation - through the use of an internal databases for spooled job - information

There has been some initial confusion about what all this means -and whether or not it is a requirement for printer drivers to be -installed on a Samba host in order to support printing from Windows -clients. A bug existed in Samba 2.2.0 which made Windows NT/2000 clients -require that the Samba server possess a valid driver for the printer. -This is fixed in Samba 2.2.1 and once again, Windows NT/2000 clients -can use the local APW for installing drivers to be used with a Samba -served printer. This is the same behavior exhibited by Windows 9x clients. -As a side note, Samba does not use these drivers in any way to process -spooled files. They are utilized entirely by the clients.

New in the Samba 2.0.4 release is the ability for Windows + NT clients to use their native security settings dialog box to + view and modify the underlying UNIX permissions.

The following MS KB article, may be of some help if you are dealing with -Windows 2000 clients: How to Add Printers with No User -Interaction in Windows 2000

Note that this ability is careful not to compromise + the security of the UNIX host Samba is running on, and + still obeys all the file permission rules that a Samba + administrator can set.

In Samba 2.0.4 and above the default value of the + parameter http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP

nt acl support has been changed from + false to true, so + manipulation of permissions is turned on by default.

5.2. Configuration5.2. How to view file security on a Samba share

From an NT 4.0 client, single-click with the right + mouse button on any file or directory in a Samba mounted + drive letter or UNC path. When the menu pops-up, click + on the Properties entry at the bottom of + the menu. This brings up the normal file properties dialog + box, but with Samba 2.0.4 this will have a new tab along the top + marked Security. Click on this tab and you + will see three buttons, Permissions, + Auditing, and Ownership. + The Auditing button will cause either + an error message A requested privilege is not held + by the client to appear if the user is not the + NT Administrator, or a dialog which is intended to allow an + Administrator to add auditing requirements to a file if the + user is logged on as the NT Administrator. This dialog is + non-functional with a Samba share at this time, as the only + useful button, the Add button will not currently + allow a list of users to be seen.

5.3. Viewing file ownership

[print$] vs. [printer$]
Clicking on the "Ownership" button + brings up a dialog box telling you who owns the given file. The + owner name will be of the form :

Previous versions of Samba recommended using a share named [printer$]. -This name was taken from the printer$ service created by Windows 9x -clients when a printer was shared. Windows 9x printer servers always have -a printer$ service which provides read-only access via no -password in order to support printer driver downloads.

"SERVER\user (Long name)"

However, the initial implementation allowed for a -parameter named Where printer driver locationSERVER -to be used on a per share basis to specify the location of -the driver files associated with that printer. Another -parameter named is the NetBIOS name of + the Samba server, printer driveruser provided -a means of defining the printer driver name to be sent to -the client.

is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). Click on the Close + button to remove this dialog.

These parameters, including If the parameter printer driver -filent acl support parameter, are being depreciated and should not -be used in new installations. For more information on this change, -you should refer to the Migration section -of this document.

false then the file owner will + be shown as the NT user "Everyone".

The Take Ownership button will not allow + you to change the ownership of this file to yourself (clicking on + it will display a dialog box complaining that the user you are + currently logged onto the NT client cannot be found). The reason + for this is that changing the ownership of a file is a privileged + operation in UNIX, available only to the root + user. As clicking on this button causes NT to attempt to change + the ownership of a file to the current user logged into the NT + client this will not work with Samba at this time.

There is an NT chown command that will work with Samba + and allow a user with Administrator privilege connected + to a Samba 2.0.4 server as root to change the ownership of + files on both a local NTFS filesystem or remote mounted NTFS + or Samba drive. This is available as part of the Seclib + NT security library written by Jeremy Allison of + the Samba Team, available from the main Samba ftp site.

5.2.1. Creating [print$]

In order to support the uploading of printer driver -files, you must first configure a file share named [print$]. -The name of this share is hard coded in Samba's internals so -the name is very important (print$ is the service used by -Windows NT print servers to provide support for printer driver -download).

5.4. Viewing file or directory permissions

You should modify the server's smb.conf file to create the -following file share (of course, some of the parameter values, -such as 'path' are arbitrary and should be replaced with -appropriate values for your site):

The third button is the "Permissions" + button. Clicking on this brings up a dialog box that shows both + the permissions and the UNIX owner of the file or directory. + The owner is displayed in the form :

[print$]
-    path = /usr/local/samba/printers
-    guest ok = yes
-    browseable = yes
-    read only = yes
-    ; since this share is configured as read only, then we need
-    ; a 'write list'.  Check the file system permissions to make
-    ; sure this account can copy files to the share.  If this
-    ; is setup to a non-root account, then it should also exist
-    ; as a 'printer admin'
-    write list = ntadmin
"SERVER\user (Long name)"

The Where write listSERVER is used to allow administrative -level user accounts to have write access in order to update files -on the share. See the smb.conf(5) -man page for more information on configuring file shares.

is the NetBIOS name of + the Samba server, user is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database).

The requirement for If the parameter nt acl support + is set to false then the file owner will + be shown as the NT user guest -ok = yes depends upon how your -site is configured. If users will be guaranteed to have -an account on the Samba host, then this is a non-issue.

"Everyone" and the + permissions will be shown as NT "Full Control".

The permissions field is displayed differently for files + and directories, so I'll describe the way file permissions + are displayed first.

5.4.1. File Permissions

Author's Note: The non-issue is that if all your Windows NT users are guaranteed to be -authenticated by the Samba server (such as a domain member server and the NT -user has already been validated by the Domain Controller in -order to logon to the Windows NT console), then guest access -is not necessary. Of course, in a workgroup environment where -you just want to be able to print without worrying about -silly accounts and security, then configure the share for -guest access. You'll probably want to add The standard UNIX user/group/world triple and + the corresponding "read", "write", "execute" permissions + triples are mapped by Samba into a three element NT ACL + with the 'r', 'w', and 'x' bits mapped into the corresponding + NT permissions. The UNIX world permissions are mapped into + the global NT group map to guest = Bad User in the [global] section as well. Make sure -you understand what this parameter does before using it -though. --jerry

In order for a Windows NT print server to support -the downloading of driver files by multiple client architectures, -it must create subdirectories within the [print$] service -which correspond to each of the supported client architectures. -Samba follows this model as well.

Next create the directory tree below the [print$] share -for each architecture you wish to support.

Everyone, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + user icon and an NT local + group icon respectively followed by the list + of permissions allowed for the UNIX user and group.

[print$]-----
-        |-W32X86           ; "Windows NT x86"
-        |-WIN40            ; "Windows 95/98"
-        |-W32ALPHA         ; "Windows NT Alpha_AXP"
-        |-W32MIPS          ; "Windows NT R4000"
-        |-W32PPC           ; "Windows NT PowerPC"

As many UNIX permission sets don't map into common + NT names such as "read", "change" or "full control" then + usually the permissions will be prefixed by the words "Special Access" in the NT display list.

But what happens if the file has no permissions allowed + for a particular UNIX user group or world component ? In order + to allow "no permissions" to be seen and modified then Samba + overloads the NT "Take Ownership" ACL attribute + (which has no meaning in UNIX) and reports a component with + no permissions as having the NT "O" bit set. + This was chosen of course to make it look like a zero, meaning + zero permissions. More details on the decision behind this will + be given below.

5.4.2. Directory Permissions

ATTENTION! REQUIRED PERMISSIONS
Directories on an NT NTFS file system have two + different sets of permissions. The first set of permissions + is the ACL set on the directory itself, this is usually displayed + in the first set of parentheses in the normal "RW" + NT style. This first set of permissions is created by Samba in + exactly the same way as normal file permissions are, described + above, and is displayed in the same way.

In order to currently add a new driver to you Samba host, -one of two conditions must hold true:

The second set of directory permissions has no real meaning + in the UNIX permissions world and represents the "inherited" permissions that any file created within + this directory would inherit.

  • Samba synthesises these inherited permissions for NT by + returning as an NT ACL the UNIX permission mode that a new file + created by Samba on this share would receive.

    5.5. Modifying file or directory permissions

    The account used to connect to the Samba host - must have a uid of 0 (i.e. a root account)

  • Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the OK button. However, there are + limitations that a user needs to be aware of, and also interactions + with the standard Samba permission masks and mapping of DOS + attributes that need to also be taken into account.

    The account used to connect to the Samba host - must be a member of the If the parameter printer - adminnt acl support list.

+ is set to false then any attempt to set + security permissions will fail with an "Access Denied" + message.

Of course, the connected account must still possess access -to add files to the subdirectories beneath [print$]. Remember -that all file shares are set to 'read only' by default.

The first thing to note is that the "Add" + button will not return a list of users in Samba 2.0.4 (it will give + an error message of "The remote procedure call failed + and did not execute"). This means that you can only + manipulate the current user/group/world permissions listed in + the dialog box. This actually works quite well as these are the + only permissions that UNIX actually has.

Once you have created the required [print$] service and -associated subdirectories, simply log onto the Samba server using -a root (or printer admin) account -from a Windows NT 4.0 client. Navigate to the "Printers" folder -on the Samba server. You should see an initial listing of printers -that matches the printer shares defined on your Samba host.

If a permission triple (either user, group, or world) + is removed from the list of permissions in the NT dialog box, + then when the "OK" button is pressed it will + be applied as "no permissions" on the UNIX side. If you then + view the permissions again the "no permissions" entry will appear + as the NT "O" flag, as described above. This + allows you to add permissions back to a file or directory once + you have removed them from a triple component.

As UNIX supports only the "r", "w" and "x" bits of + an NT ACL then if other NT security attributes such as "Delete + access" are selected then they will be ignored when applied on + the Samba server.

When setting permissions on a directory the second + set of permissions (in the second set of parentheses) is + by default applied to all files within that directory. If this + is not what you want you must uncheck the "Replace + permissions on existing files" checkbox in the NT + dialog before clicking "OK".

If you wish to remove all permissions from a + user/group/world component then you may either highlight the + component and click the "Remove" button, + or set the component to only have the special "Take + Ownership" permission (displayed as "O" + ) highlighted.

5.2.2. Setting Drivers for Existing Printers

5.6. Interaction with the standard Samba create mask + parameters

The initial listing of printers in the Samba host's -Printers folder will have no real printer driver assigned -to them. By default, in Samba 2.2.0 this driver name was set to -NO PRINTER DRIVER AVAILABLE FOR THIS PRINTER. -Later versions changed this to a NULL string to allow the use -tof the local Add Printer Wizard on NT/2000 clients. -Attempting to view the printer properties for a printer -which has this default driver assigned will result in -the error message:

Note that with Samba 2.0.5 there are four new parameters + to control this interaction. These are :

Device settings cannot be displayed. The driver -for the specified printer is not installed, only spooler -properties will be displayed. Do you want to install the -driver now?security mask

Click "No" in the error dialog and you will be presented with -the printer properties window. The way assign a driver to a -printer is to either

force security mode

  • Use the "New Driver..." button to install - a new printer driver, or

  • Select a driver from the popup list of - installed drivers. Initially this list will be empty.

If you wish to install printer drivers for client -operating systems other than "Windows NT x86", you will need -to use the "Sharing" tab of the printer properties dialog.

Assuming you have connected with a root account, you -will also be able modify other printer properties such as -ACLs and device settings using this dialog box.

A few closing comments for this section, it is possible -on a Windows NT print server to have printers -listed in the Printers folder which are not shared. Samba does -not make this distinction. By definition, the only printers of -which Samba is aware are those which are specified as shares in -smb.conf.

Another interesting side note is that Windows NT clients do -not use the SMB printer share, but rather can print directly -to any printer on another Windows NT host using MS-RPC. This -of course assumes that the printing client has the necessary -privileges on the remote host serving the printer. The default -permissions assigned by Windows NT to a printer gives the "Print" -permissions to the "Everyone" well-known group.

5.2.3. Support a large number of printers

One issue that has arisen during the development -phase of Samba 2.2 is the need to support driver downloads for -100's of printers. Using the Windows NT APW is somewhat -awkward to say the list. If more than one printer are using the -same driver, the rpcclient's -setdriver command can be used to set the driver -associated with an installed driver. The following is example -of how this could be accomplished:

 
-$ rpcclient pogo -U root%secret -c "enumdrivers"
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
- 
-[Windows NT x86]
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 4000 Series PS]
- 
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 2100 Series PS]
- 
-Printer Driver Info 1:
-     Driver Name: [HP LaserJet 4Si/4SiMX PS]
-				  
-$ rpcclient pogo -U root%secret -c "enumprinters"
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
-     flags:[0x800000]
-     name:[\\POGO\hp-print]
-     description:[POGO\\POGO\hp-print,NO DRIVER AVAILABLE FOR THIS PRINTER,]
-     comment:[]
-				  
-$ rpcclient pogo -U root%secret \
->  -c "setdriver hp-print \"HP LaserJet 4000 Series PS\""
-Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
-Successfully set hp-print to driver HP LaserJet 4000 Series PS.

5.2.4. Adding New Printers via the Windows NT APW

By default, Samba offers all printer shares defined in smb.conf -in the "Printers..." folder. Also existing in this folder is the Windows NT -Add Printer Wizard icon. The APW will be show only if

directory security mask

In order to be able to use the APW to successfully add a printer to a Samba -server, the If not set explicitly this parameter is set to the same value as + the add -printer commandcreate mask + must have a defined value. The program -hook must successfully add the printer to the system (i.e. -/etc/printcap or appropriate files) and -smb.conf if necessary.

parameter to provide compatibility with Samba 2.0.4 + where this permission change facility was introduced. To allow a user to + modify all the user/group/world permissions on a file, set this parameter + to 0777.

When using the APW from a client, if the named printer share does -not exist, smbd will execute the Next Samba checks the changed permissions for a file against + the bits set in the add printer -commandforce security mode and reparse to the smb.conf -to attempt to locate the new printer share. If the share is still not defined, -an error of "Access Denied" is returned to the client. Note that the - parameter. Any bits + that were changed that correspond to bits set to '1' in this parameter + are forced to be set.

Essentially, bits set in the add printer programforce security mode + is executed under the context -of the connected user, not necessarily a root account.

parameter may be treated as a set of bits that, when + modifying security on a file, the user has always set to be 'on'.

There is a complementing If not set explicitly this parameter is set to the same value + as the delete -printer commandforce + create mode for removing entries from the "Printers..." -folder.

5.2.5. Samba and Printer Ports

Windows NT/2000 print servers associate a port with each printer. These normally -take the form of LPT1:, COM1:, FILE:, etc... Samba must also support the -concept of ports associated with a printer. By default, only one printer port, -named "Samba Printer Port", exists on a system. Samba does not really a port in -order to print, rather it is a requirement of Windows clients.

parameter to provide compatibility + with Samba 2.0.4 where the permission change facility was introduced. + To allow a user to modify all the user/group/world permissions on a file + with no restrictions set this parameter to 000.

Note that Samba does not support the concept of "Printer Pooling" internally -either. This is when a logical printer is assigned to multiple ports as -a form of load balancing or fail over.

The security mask and force + security mode parameters are applied to the change + request in that order.

If you require that multiple ports be defined for some reason, -smb.conf possesses a For a directory Samba will perform the same operations as + described above for a file except using the parameter directory security mask instead of security + mask, and force directory security mode + parameter instead of force security mode + .

The directory security mask parameter + by default is set to the same value as the directory mask + parameter and the force directory security + mode parameter by default is set to the same value as + the force directory mode parameter to provide + compatibility with Samba 2.0.4 where the permission change facility + was introduced.

In this way Samba enforces the permission restrictions that + an administrator can set on a Samba share, whilst still allowing users + to modify the permission bits within that restriction.

If you want to set up a share that allows users full control + in modifying the permission bits on their files and directories and + doesn't force any particular bits to be set 'on', then set the following + parameters in the smb.conf(5) + file in that share specific section :

enumports -commandsecurity mask = 0777 which can be used to define an external program -that generates a listing of ports on a system.

force security mode = 0

directory security mask = 0777

force directory security mode = 0

As described, in Samba 2.0.4 the parameters :

create mask

force create mode

directory mask

force directory mode

were used instead of the parameters discussed here.

5.3. The Imprints Toolset5.7. Interaction with the standard Samba file attribute + mapping

The Imprints tool set provides a UNIX equivalent of the - Windows NT Add Printer Wizard. For complete information, please - refer to the Imprints web site at http://imprints.sourceforge.net/ as well as the documentation - included with the imprints source distribution. This section will - only provide a brief introduction to the features of Imprints.

Samba maps some of the DOS attribute bits (such as "read + only") into the UNIX permissions of a file. This means there can + be a conflict between the permission bits set via the security + dialog and the permission bits set by the file attribute mapping. +

One way this can show up is if a file has no UNIX read access + for the owner it will show up as "read only" in the standard + file attributes tabbed dialog. Unfortunately this dialog is + the same one that contains the security info in another tab.

What this can mean is that if the owner changes the permissions + to allow themselves read access using the security dialog, clicks + "OK" to get back to the standard attributes tab + dialog, and then clicks "OK" on that dialog, then + NT will set the file permissions back to read-only (as that is what + the attributes still say in the dialog). This means that after setting + permissions and clicking "OK" to get back to the + attributes dialog you should always hit "Cancel" + rather than "OK" to ensure that your changes + are not overridden.

5.3.1. What is Imprints?

Chapter 6. Printing Support in Samba 2.2.x

6.1. Introduction

Imprints is a collection of tools for supporting the goals - of

Beginning with the 2.2.0 release, Samba supports +the native Windows NT printing mechanisms implemented via +MS-RPC (i.e. the SPOOLSS named pipe). Previous versions of +Samba only supported LanMan printing calls.

The additional functionality provided by the new +SPOOLSS support includes:

  • Providing a central repository information - regarding Windows NT and 95/98 printer driver packages

    Support for downloading printer driver + files to Windows 95/98/NT/2000 clients upon demand. +

  • Providing the tools necessary for creating - the Imprints printer driver packages.

    Uploading of printer drivers via the + Windows NT Add Printer Wizard (APW) or the + Imprints tool set (refer to http://imprints.sourceforge.net). +

  • Providing an installation client which - will obtain and install printer drivers on remote Samba - and Windows NT 4 print servers.

    Support for the native MS-RPC printing + calls such as StartDocPrinter, EnumJobs(), etc... (See + the MSDN documentation at http://msdn.microsoft.com/ + for more information on the Win32 printing API) +

5.3.2. Creating Printer Driver Packages

  • The process of creating printer driver packages is beyond - the scope of this document (refer to Imprints.txt also included - with the Samba distribution for more information). In short, - an Imprints driver package is a gzipped tarball containing the - driver files, related INF files, and a control file needed by the - installation client.

    • 5.3.3. The Imprints server

    The Imprints server is really a database server that - may be queried via standard HTTP mechanisms. Each printer - entry in the database has an associated URL for the actual - downloading of the package. Each package is digitally signed - via GnuPG which can be used to verify that package downloaded - is actually the one referred in the Imprints database. It is - not recommended that this security check - be disabled.

    5.3.4. The Installation Client

    More information regarding the Imprints installation client - is available in the Imprints-Client-HOWTO.ps - file included with the imprints source package.

    The Imprints installation client comes in two forms.

    • a set of command line Perl scripts

      Support for NT Access Control Lists (ACL) + on printer objects

    • a GTK+ based graphical interface to - the command line perl scripts

      Improved support for printer queue manipulation + through the use of an internal databases for spooled job + information

    The installation client (in both forms) provides a means - of querying the Imprints database server for a matching - list of known printer model names as well as a means to - download and install the drivers on remote Samba and Windows - NT print servers.

    The basic installation process is in four steps and - perl code is wrapped around smbclient - and rpcclient.

    There has been some initial confusion about what all this means +and whether or not it is a requirement for printer drivers to be +installed on a Samba host in order to support printing from Windows +clients. A bug existed in Samba 2.2.0 which made Windows NT/2000 clients +require that the Samba server possess a valid driver for the printer. +This is fixed in Samba 2.2.1 and once again, Windows NT/2000 clients +can use the local APW for installing drivers to be used with a Samba +served printer. This is the same behavior exhibited by Windows 9x clients. +As a side note, Samba does not use these drivers in any way to process +spooled files. They are utilized entirely by the clients.

    	
-foreach (supported architecture for a given driver)
-{
-     1.  rpcclient: Get the appropriate upload directory 
-         on the remote server
-     2.  smbclient: Upload the driver files
-     3.  rpcclient: Issues an AddPrinterDriver() MS-RPC
-}
-	
-4.  rpcclient: Issue an AddPrinterEx() MS-RPC to actually
-    create the printer
    The following MS KB article, may be of some help if you are dealing with +Windows 2000 clients: How to Add Printers with No User +Interaction in Windows 2000

    One of the problems encountered when implementing - the Imprints tool set was the name space issues between - various supported client architectures. For example, Windows - NT includes a driver named "Apple LaserWriter II NTX v51.8" - and Windows 95 callsits version of this driver "Apple - LaserWriter II NTX"

    The problem is how to know what client drivers have - been uploaded for a printer. As astute reader will remember - that the Windows NT Printer Properties dialog only includes - space for one printer driver name. A quick look in the - Windows NT 4.0 system registry at

    HKLM\System\CurrentControlSet\Control\Print\Environment - http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP

    will reveal that Windows NT always uses the NT driver - name. This is ok as Windows NT always requires that at least - the Windows NT version of the printer driver is present. - However, Samba does not have the requirement internally. - Therefore, how can you use the NT driver name if is has not - already been installed?

    The way of sidestepping this limitation is to require - that all Imprints printer driver packages include both the Intel - Windows NT and 95/98 printer drivers and that NT driver is - installed first.

    5.4. Migration to from Samba 2.0.x to 2.2.x6.2. Configuration

    Given that printer driver management has changed (we hope improved) in -2.2 over prior releases, migration from an existing setup to 2.2 can -follow several paths.

    Windows clients have a tendency to remember things for quite a while. -For example, if a Windows NT client has attached to a Samba 2.0 server, -it will remember the server as a LanMan printer server. Upgrading -the Samba host to 2.2 makes support for MSRPC printing possible, but -the NT client will still remember the previous setting.

    In order to give an NT client printing "amesia" (only necessary if you -want to use the newer MSRPC printing functionality in Samba), delete -the registry keys associated with the print server contained in -[HKLM\SYSTEM\CurrentControlSet\Control\Print]. The -spooler service on the client should be stopped prior to doing this:

    C:\WINNT\ > net stop spooler

    All the normal disclaimers about editing the registry go -here. Be careful, and know what you are doing.

    The spooler service should be restarted after you have finished -removing the appropriate registry entries by replacing the -stop command above with start.

    Windows 9x clients will continue to use LanMan printing calls -with a 2.2 Samba server so there is no need to perform any of these -modifications on non-NT clients.

    Achtung![print$] vs. [printer$]

    The following smb.conf parameters are considered to be depreciated and will -be removed soon. Do not use them in new installations

    • Previous versions of Samba recommended using a share named [printer$]. +This name was taken from the printer$ service created by Windows 9x +clients when a printer was shared. Windows 9x printer servers always have +a printer$ service which provides read-only access via no +password in order to support printer driver downloads.

      However, the initial implementation allowed for a +parameter named printer driver file (G)printer driver location -

    • +to be used on a per share basis to specify the location of +the driver files associated with that printer. Another +parameter named printer driver (S)printer driver -

    • provided +a means of defining the printer driver name to be sent to +the client.

      These parameters, including printer driver location (S)printer driver +file parameter, are being depreciated and should not +be used in new installations. For more information on this change, +you should refer to the Migration section -

    6.2.1. Creating [print$]

    In order to support the uploading of printer driver +files, you must first configure a file share named [print$]. +The name of this share is hard coded in Samba's internals so +the name is very important (print$ is the service used by +Windows NT print servers to provide support for printer driver +download).

    Here are the possible scenarios for supporting migration:

    You should modify the server's smb.conf file to add the global +parameters and to create the +following file share (of course, some of the parameter values, +such as 'path' are arbitrary and should be replaced with +appropriate values for your site):

    [global]
+    ; members of the ntadmin group should be able
+    ; to add drivers and set printer properties
+    ; root is implicitly a 'printer admin'
+    printer admin = @ntadmin
+
+[print$]
+    path = /usr/local/samba/printers
+    guest ok = yes
+    browseable = yes
+    read only = yes
+    ; since this share is configured as read only, then we need
+    ; a 'write list'.  Check the file system permissions to make
+    ; sure this account can copy files to the share.  If this
+    ; is setup to a non-root account, then it should also exist
+    ; as a 'printer admin'
+    write list = @ntadmin,root

    • If you do not desire the new Windows NT - print driver support, nothing needs to be done. - All existing parameters work the same.

    • The write list is used to allow administrative +level user accounts to have write access in order to update files +on the share. See the smb.conf(5) +man page for more information on configuring file shares.

      If you want to take advantage of NT printer - driver support but do not want to migrate the - 9x drivers to the new setup, the leave the existing - printers.def file. When smbd attempts to locate a - 9x driver for the printer in the TDB and fails it - will drop down to using the printers.def (and all - associated parameters). The The requirement for make_printerdef - tool will also remain for backwards compatibility but will - be moved to the "this tool is the old way of doing it" - pile.

      • guest +ok = yes depends upon how your +site is configured. If users will be guaranteed to have +an account on the Samba host, then this is a non-issue.

      Author's Note: The non-issue is that if all your Windows NT users are guaranteed to be +authenticated by the Samba server (such as a domain member server and the NT +user has already been validated by the Domain Controller in +order to logon to the Windows NT console), then guest access +is not necessary. Of course, in a workgroup environment where +you just want to be able to print without worrying about +silly accounts and security, then configure the share for +guest access. You'll probably want to add map to guest = Bad User in the [global] section as well. Make sure +you understand what this parameter does before using it +though. --jerry

      In order for a Windows NT print server to support +the downloading of driver files by multiple client architectures, +it must create subdirectories within the [print$] service +which correspond to each of the supported client architectures. +Samba follows this model as well.

      Next create the directory tree below the [print$] share +for each architecture you wish to support.

      [print$]-----
+        |-W32X86           ; "Windows NT x86"
+        |-WIN40            ; "Windows 95/98"
+        |-W32ALPHA         ; "Windows NT Alpha_AXP"
+        |-W32MIPS          ; "Windows NT R4000"
+        |-W32PPC           ; "Windows NT PowerPC"

      ATTENTION! REQUIRED PERMISSIONS

      In order to currently add a new driver to you Samba host, +one of two conditions must hold true:

      • If you install a Windows 9x driver for a printer - on your Samba host (in the printing TDB), this information will - take precedence and the three old printing parameters - will be ignored (including print driver location).

        The account used to connect to the Samba host + must have a uid of 0 (i.e. a root account)

      • If you want to migrate an existing printers.def - file into the new setup, the current only solution is to use the Windows - NT APW to install the NT drivers and the 9x drivers. This can be scripted - using smbclient and rpcclient. See the - Imprints installation client at The account used to connect to the Samba host + must be a member of the http://imprints.sourceforge.net/ - for an example. -

        printer + admin list.

      Of course, the connected account must still possess access +to add files to the subdirectories beneath [print$]. Remember +that all file shares are set to 'read only' by default.

      Once you have created the required [print$] service and +associated subdirectories, simply log onto the Samba server using +a root (or printer admin) account +from a Windows NT 4.0 client. Navigate to the "Printers" folder +on the Samba server. You should see an initial listing of printers +that matches the printer shares defined on your Samba host.

    Chapter 6. security = domain in Samba 2.x

    6.1. Joining an NT Domain with Samba 2.2

    6.2.2. Setting Drivers for Existing Printers

    In order for a Samba-2 server to join an NT domain, - you must first add the NetBIOS name of the Samba server to the - NT domain on the PDC using Server Manager for Domains. This creates - the machine account in the domain (PDC) SAM. Note that you should - add the Samba server as a "Windows NT Workstation or Server", - NOT as a Primary or backup domain controller.

    The initial listing of printers in the Samba host's +Printers folder will have no real printer driver assigned +to them. By default, in Samba 2.2.0 this driver name was set to +NO PRINTER DRIVER AVAILABLE FOR THIS PRINTER. +Later versions changed this to a NULL string to allow the use +tof the local Add Printer Wizard on NT/2000 clients. +Attempting to view the printer properties for a printer +which has this default driver assigned will result in +the error message:

    Assume you have a Samba-2 server with a NetBIOS name of - SERV1 and are joining an NT domain called - DOM, which has a PDC with a NetBIOS name - of DOMPDC and two backup domain controllers - with NetBIOS names DOMBDC1 and DOMBDC2 - .

    Device settings cannot be displayed. The driver +for the specified printer is not installed, only spooler +properties will be displayed. Do you want to install the +driver now?

    In order to join the domain, first stop all Samba daemons - and run the command:

    Click "No" in the error dialog and you will be presented with +the printer properties window. The way assign a driver to a +printer is to either

    root# smbpasswd -j DOM -r DOMPDC -

    • as we are joining the domain DOM and the PDC for that domain - (the only machine that has write access to the domain SAM database) - is DOMPDC. If this is successful you will see the message:

      Use the "New Driver..." button to install + a new printer driver, or

    • smbpasswd: Joined domain DOM. -

      in your terminal window. See the smbpasswd(8) man page for more details.

      Select a driver from the popup list of + installed drivers. Initially this list will be empty.

    There is existing development code to join a domain - without having to create the machine trust account on the PDC - beforehand. This code will hopefully be available soon - in release branches as well.

    If you wish to install printer drivers for client +operating systems other than "Windows NT x86", you will need +to use the "Sharing" tab of the printer properties dialog.

    This command goes through the machine account password - change protocol, then writes the new (random) machine account - password for this Samba server into a file in the same directory - in which an smbpasswd file would be stored - normally :

    Assuming you have connected with a root account, you +will also be able modify other printer properties such as +ACLs and device settings using this dialog box.

    A few closing comments for this section, it is possible +on a Windows NT print server to have printers +listed in the Printers folder which are not shared. Samba does +not make this distinction. By definition, the only printers of +which Samba is aware are those which are specified as shares in +/usr/local/samba/private

    smb.conf.

    In Samba 2.0.x, the filename looks like this:

    Another interesting side note is that Windows NT clients do +not use the SMB printer share, but rather can print directly +to any printer on another Windows NT host using MS-RPC. This +of course assumes that the printing client has the necessary +privileges on the remote host serving the printer. The default +permissions assigned by Windows NT to a printer gives the "Print" +permissions to the "Everyone" well-known group.

    6.2.3. Support a large number of printers

    <NT DOMAIN NAME>.<Samba - Server Name>.macOne issue that has arisen during the development +phase of Samba 2.2 is the need to support driver downloads for +100's of printers. Using the Windows NT APW is somewhat +awkward to say the list. If more than one printer are using the +same driver, the rpcclient's +setdriver command can be used to set the driver +associated with an installed driver. The following is example +of how this could be accomplished:

     
+$ rpcclient pogo -U root%secret -c "enumdrivers"
+Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
+ 
+[Windows NT x86]
+Printer Driver Info 1:
+     Driver Name: [HP LaserJet 4000 Series PS]
+ 
+Printer Driver Info 1:
+     Driver Name: [HP LaserJet 2100 Series PS]
+ 
+Printer Driver Info 1:
+     Driver Name: [HP LaserJet 4Si/4SiMX PS]
+				  
+$ rpcclient pogo -U root%secret -c "enumprinters"
+Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
+     flags:[0x800000]
+     name:[\\POGO\hp-print]
+     description:[POGO\\POGO\hp-print,NO DRIVER AVAILABLE FOR THIS PRINTER,]
+     comment:[]
+				  
+$ rpcclient pogo -U root%secret \
+>  -c "setdriver hp-print \"HP LaserJet 4000 Series PS\""
+Domain=[NARNIA] OS=[Unix] Server=[Samba 2.2.0-alpha3]
+Successfully set hp-print to driver HP LaserJet 4000 Series PS.

    6.2.4. Adding New Printers via the Windows NT APW

    The By default, Samba offers all printer shares defined in .mac suffix stands for machine account - password file. So in our example above, the file would be called:

    smb.conf +in the "Printers..." folder. Also existing in this folder is the Windows NT +Add Printer Wizard icon. The APW will be show only if

    DOM.SERV1.mac

    • In Samba 2.2, this file has been replaced with a TDB - (Trivial Database) file named secrets.tdb. +>The connected user is able to successfully + execute an OpenPrinterEx(\\server) with administrative + privileges (i.e. root or printer admin).

    • This file is created and owned by root and is not - readable by any other user. It is the key to the domain-level - security for your system, and should be treated as carefully - as a shadow password file.

      Now, before restarting the Samba daemons you must - edit your smb.conf(5) - file to tell Samba it should now use domain security.

      Change (or add) your security =show + add printer wizard = yes line in the [global] section - of your smb.conf to read:

      security = domain

      (the default). +

    Next change the In order to be able to use the APW to successfully add a printer to a Samba +server, the workgroup =add +printer command line in the [global] section to read:

    must have a defined value. The program +hook must successfully add the printer to the system (i.e. +/etc/printcap or appropriate files) and +smb.conf if necessary.

    When using the APW from a client, if the named printer share does +not exist, workgroup = DOM

    as this is the name of the domain we are joining.

    You must also have the parameter smbd will execute the encrypt passwordsadd printer +command set to yes - in order for your users to authenticate to the NT PDC.

    Finally, add (or modify) a and reparse to the smb.conf +to attempt to locate the new printer share. If the share is still not defined, +an error of "Access Denied" is returned to the client. Note that the +password server =add printer program line in the [global] - section to read:

    password server = DOMPDC DOMBDC1 DOMBDC2

    These are the primary and backup domain controllers Samba - will attempt to contact in order to authenticate users. Samba will - try to contact each of these servers in order, so you may want to - rearrange this list in order to spread out the authentication load - among domain controllers.

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

    password server = *

    This method, which was introduced in Samba 2.0.6, - allows Samba to use exactly the same mechanism that NT does. This - method either broadcasts or uses a WINS database in order to - find domain controllers to authenticate against.

    Finally, restart your Samba daemons and get ready for - clients to begin using domain security!

    6.2. Samba and Windows 2000 Domains

    Many people have asked regarding the state of Samba's ability to participate in -a Windows 2000 Domain. Samba 2.2 is able to act as a member server of a Windows -2000 domain operating in mixed or native mode.

    There is much confusion between the circumstances that require a "mixed" mode -Win2k DC and a when this host can be switched to "native" mode. A "mixed" mode -Win2k domain controller is only needed if Windows NT BDCs must exist in the same -domain. By default, a Win2k DC in "native" mode will still support -NetBIOS and NTLMv1 for authentication of legacy clients such as Windows 9x and -NT 4.0. Samba has the same requirements as a Windows NT 4.0 member server.

    is executed under the context +of the connected user, not necessarily a root account.

    The steps for adding a Samba 2.2 host to a Win2k domain are the same as those -for adding a Samba server to a Windows NT 4.0 domain. The only exception is that -the "Server Manager" from NT 4 has been replaced by the "Active Directory Users and -Computers" MMC (Microsoft Management Console) plugin.

    There is a complementing delete +printer command for removing entries from the "Printers..." +folder.

    6.3. Why is this better than security = server?

    Currently, domain security in Samba doesn't free you from - having to create local Unix users to represent the users attaching - to your server. This means that if domain user DOM\fred - attaches to your domain security Samba server, there needs - to be a local Unix user fred to represent that user in the Unix - filesystem. This is very similar to the older Samba security mode - security = server, - where Samba would pass through the authentication request to a Windows - NT server in the same way as a Windows 95 or Windows 98 server would. -

    Please refer to the Winbind - paper for information on a system to automatically - assign UNIX uids and gids to Windows NT Domain users and groups. - This code is available in development branches only at the moment, - but will be moved to release branches soon.

    The advantage to domain-level security is that the - authentication in domain-level security is passed down the authenticated - RPC channel in exactly the same way that an NT server would do it. This - means Samba servers now participate in domain trust relationships in - exactly the same way NT servers do (i.e., you can add Samba servers into - a resource domain and have the authentication passed on from a resource - domain PDC to an account domain PDC.

    6.2.5. Samba and Printer Ports

    In addition, with security = server every Samba - daemon on a server has to keep a connection open to the - authenticating server for as long as that daemon lasts. This can drain - the connection resources on a Microsoft NT server and cause it to run - out of available connections. With security = domain, - however, the Samba daemons connect to the PDC/BDC only for as long - as is necessary to authenticate the user, and then drop the connection, - thus conserving PDC connection resources.

    Windows NT/2000 print servers associate a port with each printer. These normally +take the form of LPT1:, COM1:, FILE:, etc... Samba must also support the +concept of ports associated with a printer. By default, only one printer port, +named "Samba Printer Port", exists on a system. Samba does not really a port in +order to print, rather it is a requirement of Windows clients.

    And finally, acting in the same manner as an NT server - authenticating to a PDC means that as part of the authentication - reply, the Samba server gets the user identification information such - as the user SID, the list of NT groups the user belongs to, etc. All - this information will allow Samba to be extended in the future into - a mode the developers currently call appliance mode. In this mode, - no local Unix users will be necessary, and Samba will generate Unix - uids and gids from the information passed back from the PDC when a - user is authenticated, making a Samba server truly plug and play - in an NT domain environment. Watch for this code soon.

    Note that Samba does not support the concept of "Printer Pooling" internally +either. This is when a logical printer is assigned to multiple ports as +a form of load balancing or fail over.

    NOTE: Much of the text of this document - was first published in the Web magazine - LinuxWorld as the article If you require that multiple ports be defined for some reason, +smb.conf possesses a Doing - the NIS/NT Samba.

    enumports +command which can be used to define an external program +that generates a listing of ports on a system.

    Chapter 7. How to Configure Samba 2.2 as a Primary Domain Controller

    7.1. Prerequisite Reading6.3. The Imprints Toolset

    Before you continue readingin this chapter, please make sure -that you are comfortable with configuring basic files services -in smb.conf and how to enable and administrate password -encryption in Samba. Theses two topics are covered in the -smb.conf(5) -manpage and the The Imprints tool set provides a UNIX equivalent of the + Windows NT Add Printer Wizard. For complete information, please + refer to the Imprints web site at Encryption chapter -of this HOWTO Collection.

    http://imprints.sourceforge.net/ as well as the documentation + included with the imprints source distribution. This section will + only provide a brief introduction to the features of Imprints.

    7.2. Background

    Note: Author's Note : This document is a combination -of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ. -Both documents are superceeded by this one.

    6.3.1. What is Imprints?

    Version of Samba prior to release 2.2 had marginal capabilities to -act as a Windows NT 4.0 Primary Domain Controller (PDC). Beginning with -Samba 2.2.0, we are proud to announce official support for Windows NT 4.0 -style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through -SP1) clients. This article outlines the steps necessary for configuring Samba -as a PDC. It is necessary to have a working Samba server prior to implementing the -PDC functionality. If you have not followed the steps outlined in - UNIX_INSTALL.html, please make sure -that your server is configured correctly before proceeding. Another good -resource in the smb.conf(5) man -page. The following functionality should work in 2.2:

    Imprints is a collection of tools for supporting the goals + of

    • domain logons for Windows NT 4.0/2000 clients. -

      Providing a central repository information + regarding Windows NT and 95/98 printer driver packages

    • placing a Windows 9x client in user level security -

      Providing the tools necessary for creating + the Imprints printer driver packages.

    • retrieving a list of users and groups from a Samba PDC to - Windows 9x/NT/2000 clients -

      Providing an installation client which + will obtain and install printer drivers on remote Samba + and Windows NT 4 print servers.

    6.3.2. Creating Printer Driver Packages

    roving (roaming) user profiles -

    The process of creating printer driver packages is beyond + the scope of this document (refer to Imprints.txt also included + with the Samba distribution for more information). In short, + an Imprints driver package is a gzipped tarball containing the + driver files, related INF files, and a control file needed by the + installation client.

    6.3.3. The Imprints server

    The Imprints server is really a database server that + may be queried via standard HTTP mechanisms. Each printer + entry in the database has an associated URL for the actual + downloading of the package. Each package is digitally signed + via GnuPG which can be used to verify that package downloaded + is actually the one referred in the Imprints database. It is + not recommended that this security check + be disabled.

    6.3.4. The Installation Client

    More information regarding the Imprints installation client + is available in the Imprints-Client-HOWTO.ps + file included with the imprints source package.

    The Imprints installation client comes in two forms.

    • a set of command line Perl scripts

    • Windows NT 4.0 style system policies -

      a GTK+ based graphical interface to + the command line perl scripts

    The installation client (in both forms) provides a means + of querying the Imprints database server for a matching + list of known printer model names as well as a means to + download and install the drivers on remote Samba and Windows + NT print servers.

    The basic installation process is in four steps and + perl code is wrapped around smbclient + and rpcclient.

    Windows 2000 Service Pack 2 Clients

    Samba 2.2.1 is required for PDC functionality when using Windows 2000 - SP2 clients. - 

    	
+foreach (supported architecture for a given driver)
+{
+     1.  rpcclient: Get the appropriate upload directory 
+         on the remote server
+     2.  smbclient: Upload the driver files
+     3.  rpcclient: Issues an AddPrinterDriver() MS-RPC
+}
+	
+4.  rpcclient: Issue an AddPrinterEx() MS-RPC to actually
+    create the printer

    One of the problems encountered when implementing + the Imprints tool set was the name space issues between + various supported client architectures. For example, Windows + NT includes a driver named "Apple LaserWriter II NTX v51.8" + and Windows 95 calls its version of this driver "Apple + LaserWriter II NTX"

    The problem is how to know what client drivers have + been uploaded for a printer. As astute reader will remember + that the Windows NT Printer Properties dialog only includes + space for one printer driver name. A quick look in the + Windows NT 4.0 system registry at

    HKLM\System\CurrentControlSet\Control\Print\Environment +

    will reveal that Windows NT always uses the NT driver + name. This is ok as Windows NT always requires that at least + the Windows NT version of the printer driver is present. + However, Samba does not have the requirement internally. + Therefore, how can you use the NT driver name if is has not + already been installed?

    The way of sidestepping this limitation is to require + that all Imprints printer driver packages include both the Intel + Windows NT and 95/98 printer drivers and that NT driver is + installed first.

    6.4. Migration to from Samba 2.0.x to 2.2.x

    The following pieces of functionality are not included in the 2.2 release:

    Given that printer driver management has changed (we hope improved) in +2.2 over prior releases, migration from an existing setup to 2.2 can +follow several paths. Here are the possible scenarios for +migration:

    • Windows NT 4 domain trusts -

      If you do not desire the new Windows NT + print driver support, nothing needs to be done. + All existing parameters work the same.

    • SAM replication with Windows NT 4.0 Domain Controllers - (i.e. a Samba PDC and a Windows NT BDC or vice versa) -

      If you want to take advantage of NT printer + driver support but do not want to migrate the + 9x drivers to the new setup, the leave the existing + printers.def file. When smbd attempts + to locate a + 9x driver for the printer in the TDB and fails it + will drop down to using the printers.def (and all + associated parameters). The make_printerdef + tool will also remain for backwards compatibility but will + be removed in the next major release.

    • Adding users via the User Manager for Domains -

      If you install a Windows 9x driver for a printer + on your Samba host (in the printing TDB), this information will + take precedence and the three old printing parameters + will be ignored (including print driver location).

    • Acting as a Windows 2000 Domain Controller (i.e. Kerberos and - Active Directory) +>If you want to migrate an existing printers.def + file into the new setup, the current only solution is to use the Windows + NT APW to install the NT drivers and the 9x drivers. This can be scripted + using smbclient and rpcclient. See the + Imprints installation client at http://imprints.sourceforge.net/ + for an example.

    Please note that Windows 9x clients are not true members of a domain -for reasons outlined in this article. Therefore the protocol for -support Windows 9x style domain logons is completely different -from NT4 domain logons and has been officially supported for some -time.

    Achtung!

    Implementing a Samba PDC can basically be divided into 2 broad -steps.

    The following smb.conf parameters are considered to +be deprecated and will be removed soon. Do not use them in new +installations

      • Configuring the Samba PDC +>printer driver file (G)

      • Creating machine trust accounts and joining clients - to the domain +>printer driver (S)

  • There are other minor details such as user profiles, system -policies, etc... However, these are not necessarily specific -to a Samba PDC as much as they are related to Windows NT networking -concepts. They will be mentioned only briefly here.

    7.3. Configuring the Samba Domain Controllerprinter driver location (S) +

    • The have been two new parameters add in Samba 2.2.2 to for +better support of Samba 2.0.x backwards capability (disable +spoolss) and for using local printers drivers on Windows +NT/2000 clients (use client driver). Both of +these options are described in the smb.coinf(5) man page and are +disabled by default.

    Chapter 7. security = domain in Samba 2.x

    7.1. Joining an NT Domain with Samba 2.2

    In order for a Samba-2 server to join an NT domain, + you must first add the NetBIOS name of the Samba server to the + NT domain on the PDC using Server Manager for Domains. This creates + the machine account in the domain (PDC) SAM. Note that you should + add the Samba server as a "Windows NT Workstation or Server", + NOT as a Primary or backup domain controller.

    Assume you have a Samba-2 server with a NetBIOS name of + SERV1 and are joining an NT domain called + DOM, which has a PDC with a NetBIOS name + of DOMPDC and two backup domain controllers + with NetBIOS names DOMBDC1 and DOMBDC2 + .

    In order to join the domain, first stop all Samba daemons + and run the command:

    root# smbpasswd -j DOM -r DOMPDC +

    as we are joining the domain DOM and the PDC for that domain + (the only machine that has write access to the domain SAM database) + is DOMPDC. If this is successful you will see the message:

    smbpasswd: Joined domain DOM. +

    in your terminal window. See the smbpasswd(8) man page for more details.

    There is existing development code to join a domain + without having to create the machine trust account on the PDC + beforehand. This code will hopefully be available soon + in release branches as well.

    This command goes through the machine account password + change protocol, then writes the new (random) machine account + password for this Samba server into a file in the same directory + in which an smbpasswd file would be stored - normally :

    /usr/local/samba/private

    In Samba 2.0.x, the filename looks like this:

    <NT DOMAIN NAME>.<Samba + Server Name>.mac

    The .mac suffix stands for machine account + password file. So in our example above, the file would be called:

    DOM.SERV1.mac

    In Samba 2.2, this file has been replaced with a TDB + (Trivial Database) file named secrets.tdb. +

    This file is created and owned by root and is not + readable by any other user. It is the key to the domain-level + security for your system, and should be treated as carefully + as a shadow password file.

    Now, before restarting the Samba daemons you must + edit your smb.conf(5) + 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

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

    workgroup = DOM

    as 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.

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

    password server = DOMPDC DOMBDC1 DOMBDC2

    These are the primary and backup domain controllers Samba + will attempt to contact in order to authenticate users. Samba will + try to contact each of these servers in order, so you may want to + rearrange this list in order to spread out the authentication load + among domain controllers.

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

    password server = *

    This method, which was introduced in Samba 2.0.6, + allows Samba to use exactly the same mechanism that NT does. This + method either broadcasts or uses a WINS database in order to + find domain controllers to authenticate against.

    Finally, restart your Samba daemons and get ready for + clients to begin using domain security!

    7.2. Samba and Windows 2000 Domains

    Many people have asked regarding the state of Samba's ability to participate in +a Windows 2000 Domain. Samba 2.2 is able to act as a member server of a Windows +2000 domain operating in mixed or native mode.

    There is much confusion between the circumstances that require a "mixed" mode +Win2k DC and a when this host can be switched to "native" mode. A "mixed" mode +Win2k domain controller is only needed if Windows NT BDCs must exist in the same +domain. By default, a Win2k DC in "native" mode will still support +NetBIOS and NTLMv1 for authentication of legacy clients such as Windows 9x and +NT 4.0. Samba has the same requirements as a Windows NT 4.0 member server.

    The steps for adding a Samba 2.2 host to a Win2k domain are the same as those +for adding a Samba server to a Windows NT 4.0 domain. The only exception is that +the "Server Manager" from NT 4 has been replaced by the "Active Directory Users and +Computers" MMC (Microsoft Management Console) plugin.

    7.3. Why is this better than security = server?

    Currently, domain security in Samba doesn't free you from + having to create local Unix users to represent the users attaching + to your server. This means that if domain user DOM\fred + attaches to your domain security Samba server, there needs + to be a local Unix user fred to represent that user in the Unix + filesystem. This is very similar to the older Samba security mode + security = server, + where Samba would pass through the authentication request to a Windows + NT server in the same way as a Windows 95 or Windows 98 server would. +

    Please refer to the Winbind + paper for information on a system to automatically + assign UNIX uids and gids to Windows NT Domain users and groups. + This code is available in development branches only at the moment, + but will be moved to release branches soon.

    The advantage to domain-level security is that the + authentication in domain-level security is passed down the authenticated + RPC channel in exactly the same way that an NT server would do it. This + means Samba servers now participate in domain trust relationships in + exactly the same way NT servers do (i.e., you can add Samba servers into + a resource domain and have the authentication passed on from a resource + domain PDC to an account domain PDC.

    In addition, with security = server every Samba + daemon on a server has to keep a connection open to the + authenticating server for as long as that daemon lasts. This can drain + the connection resources on a Microsoft NT server and cause it to run + out of available connections. With security = domain, + however, the Samba daemons connect to the PDC/BDC only for as long + as is necessary to authenticate the user, and then drop the connection, + thus conserving PDC connection resources.

    And finally, acting in the same manner as an NT server + authenticating to a PDC means that as part of the authentication + reply, the Samba server gets the user identification information such + as the user SID, the list of NT groups the user belongs to, etc. All + this information will allow Samba to be extended in the future into + a mode the developers currently call appliance mode. In this mode, + no local Unix users will be necessary, and Samba will generate Unix + uids and gids from the information passed back from the PDC when a + user is authenticated, making a Samba server truly plug and play + in an NT domain environment. Watch for this code soon.

    NOTE: Much of the text of this document + was first published in the Web magazine + LinuxWorld as the article Doing + the NIS/NT Samba.

    Chapter 8. How to Configure Samba 2.2 as a Primary Domain Controller

    8.1. Prerequisite Reading

    Before you continue reading in this chapter, please make sure +that you are comfortable with configuring basic files services +in smb.conf and how to enable and administer password +encryption in Samba. Theses two topics are covered in the +smb.conf(5) +manpage and the Encryption chapter +of this HOWTO Collection.

    8.2. Background

    Note: Author's Note : This document is a combination +of David Bannon's Samba 2.2 PDC HOWTO and the Samba NT Domain FAQ. +Both documents are superseded by this one.

    Version of Samba prior to release 2.2 had marginal capabilities to +act as a Windows NT 4.0 Primary DOmain Controller (PDC). Beginning with +Samba 2.2.0, we are proud to announce official support for Windows NT 4.0 +style domain logons from Windows NT 4.0 (through SP6) and Windows 2000 (through +SP1) clients. This article outlines the steps necessary for configuring Samba +as a PDC. It is necessary to have a working Samba server prior to implementing the +PDC functionality. If you have not followed the steps outlined in + UNIX_INSTALL.html, please make sure +that your server is configured correctly before proceeding. Another good +resource in the smb.conf(5) man +page. The following functionality should work in 2.2:

    • domain logons for Windows NT 4.0/2000 clients. +

    • placing a Windows 9x client in user level security +

    • retrieving a list of users and groups from a Samba PDC to + Windows 9x/NT/2000 clients +

    • roving (roaming) user profiles +

    • Windows NT 4.0 style system policies +

    Windows 2000 Service Pack 2 Clients

    Samba 2.2.1 is required for PDC functionality when using Windows 2000 + SP2 clients. +

    The following pieces of functionality are not included in the 2.2 release:

    • Windows NT 4 domain trusts +

    • SAM replication with Windows NT 4.0 Domain Controllers + (i.e. a Samba PDC and a Windows NT BDC or vice versa) +

    • Adding users via the User Manager for Domains +

    • Acting as a Windows 2000 Domain Controller (i.e. Kerberos and + Active Directory) +

    Please note that Windows 9x clients are not true members of a domain +for reasons outlined in this article. Therefore the protocol for +support Windows 9x style domain logons is completely different +from NT4 domain logons and has been officially supported for some +time.

    Implementing a Samba PDC can basically be divided into 2 broad +steps.

    1. Configuring the Samba PDC +

    2. Creating machine trust accounts and joining clients + to the domain +

    There are other minor details such as user profiles, system +policies, etc... However, these are not necessarily specific +to a Samba PDC as much as they are related to Windows NT networking +concepts. They will be mentioned only briefly here.

    8.3. Configuring the Samba Domain Controller

    The first step in creating a working Samba PDC is to @@ -5364,16 +5903,11 @@ CLASS="FILENAME" >As Samba 2.2 does not offer a complete implementation of group mapping between Windows NT groups and UNIX groups (this is really quite complicated to explain in a short space), you should refer to the domain -admin users and domain admin group smb.conf parameters for information of creating a Domain Admins +> smb.conf parameter for information of creating "Domain Admins" style accounts.

    7.4. Creating Machine Trust Accounts and Joining Clients +NAME="AEN1180" +>8.4. Creating Machine Trust Accounts and Joining Clients to the Domain

    A machine trust account is a samba user account owned by a computer. The account password acts as the shared secret for secure communication with the Domain Controller. This is a security feature -to prevent an unauthorized machine with the same netbios name from +to prevent an unauthorized machine with the same NetBIOS name from joining the domain and gaining access to domain user/group accounts. Hence a Windows 9x host is never a true member of a domain because it does not posses a machine trust account, and thus has no shared secret with the DC.

    Manual creation before joining the client to the domain. In this case, the password is set to a known value -- the lower case of the - machine's netbios name. + machine's NetBIOS name.

  • 7.4.1. Manually creating machine trust accounts8.4.1. Manually creating machine trust accounts

    The first step in creating a machine trust account by hand is to @@ -5458,9 +5992,20 @@ CLASS="PROMPT" >/usr/sbin/useradd -g 100 -d /dev/null -c machine_nickname"machine +nickname" -s /bin/false machine_name -m -s /bin/false $

    root# passwd -l machine_namemachine_name absolutely must be -the netbios name of the pc to be added to the domain. The "$" must append the netbios +the NetBIOS name of the pc to be added to the domain. The "$" must append the NetBIOS name of the pc or samba will not recognize this as a machine account

    Now that the UNIX account has been created, the next step is to create @@ -5539,7 +6084,7 @@ CLASS="REPLACEABLE" >machine_name is the machine's netbios +> is the machine's NetBIOS name.

    7.4.2. Creating machine trust accounts "on the fly"8.4.2. Creating machine trust accounts "on the fly"

    The second, and most recommended way of creating machine trust accounts @@ -5615,7 +6160,7 @@ an entry in smbpasswd for . The password SHOULD be set to s different password that the +> be set to a different password that the associated /etc/passwd

    7.5. Common Problems and Errors8.5. Common Problems and Errors

    smbpasswd -e %user%, this is normaly done, when you create an account. +>, this is normally done, when you create an account.

    In order to work around this problem in 2.2.0, configure the @@ -5826,8 +6371,8 @@ CLASS="SECT1" >

    7.6. System Policies and Profiles8.6. System Policies and Profiles

    Much of the information necessary to implement System Policies and @@ -5890,7 +6435,7 @@ CLASS="FILENAME" CLASS="COMMAND" >servicepackname /x, - ie thats Nt4sp6ai.exe /x for service pack 6a. The policy editor, @@ -5983,8 +6528,8 @@ CLASS="SECT1" >

    7.7. What other help can I get ?8.7. What other help can I get ?

    There are many sources of information available in the form @@ -6003,7 +6548,7 @@ general SMB topics such as browsing.

    One of the best diagnostic tools for debugging problems is Samba itself. - You can use the -d option for both smbd and nmbd to specifiy what + You can use the -d option for both smbd and nmbd to specify what 'debug level' at which to run. See the man pages on smbd, nmbd and smb.conf for more information on debugging options. The debug level can range from 1 (the default) to 10 (100 for debugging passwords). @@ -6059,7 +6604,7 @@ TARGET="_top" (aka. netmon) is available on the Microsoft Developer Network CD's, the Windows NT Server install CD and the SMS CD's. The version of netmon that ships with SMS allows for dumping packets between any two - computers (ie. placing the network interface in promiscuous mode). + computers (i.e. placing the network interface in promiscuous mode). The version on the NT Server install CD will only allow monitoring of network traffic directed to the local NT box and broadcasts on the local subnet. Be aware that Ethereal can read and write netmon @@ -6311,7 +6856,7 @@ TARGET="_top" >

  • Don't cross post. Work out which is the best list to post to - and see what happens, ie don't post to both samba-ntdom and samba-technical. + and see what happens, i.e. don't post to both samba-ntdom and samba-technical. Many people active on the lists subscribe to more than one list and get annoyed to see the same message two or more times. Often someone will see a message and thinking it would be better dealt @@ -6379,8 +6924,8 @@ CLASS="SECT1" >

    7.8. Domain Control for Windows 9x/ME8.8. Domain Control for Windows 9x/ME

  • The client then connects to the user's home share and searches for the - user's profile. As it turns out, you can specify the users home share as + user's profile. As it turns out, you can specify the user's home share as a sharename and path. For example, \\server\fred\.profile. If the profiles are found, they are implemented.

    7.8.1. Configuration Instructions: Network Logons8.8.1. Configuration Instructions: Network Logons

    To use domain logons and profiles you need to do the following:

  • you will probabaly find that your clients automatically mount the +> you will probably find that your clients automatically mount the \\SERVER\NETLOGON share as drive z: while logging in. You can put some useful programs there to execute from the batch files.

    7.8.2. Configuration Instructions: Setting up Roaming User Profiles8.8.2. Configuration Instructions: Setting up Roaming User Profiles

    Win9X clients send a NetUserGetInfo request to the server to get the user's profiles location. However, the response does not have room for a separate -profiles location field, only the users home share. This means that Win9X +profiles location field, only the user's home share. This means that Win9X profiles are restricted to being in the user's home directory.

    WinNT clients send a NetSAMLogon RPC request, which contains many fields, @@ -6751,8 +7296,8 @@ CLASS="SECT3" >

    7.8.2.1. Windows NT Configuration8.8.2.1. Windows NT Configuration

    To support WinNT clients, inn the [global] section of smb.conf set the @@ -6795,8 +7340,8 @@ CLASS="SECT3" >

    7.8.2.2. Windows 9X Configuration8.8.2.2. Windows 9X Configuration

    To support Win9X clients, you must use the "logon home" parameter. Samba has @@ -6835,8 +7380,8 @@ CLASS="SECT3" >

    7.8.2.3. Win9X and WinNT Configuration8.8.2.3. Win9X and WinNT Configuration

    You can support profiles for both Win9X and WinNT clients by setting both the @@ -6873,8 +7418,8 @@ CLASS="SECT3" >

    7.8.2.4. Windows 9X Profile Setup8.8.2.4. Windows 9X Profile Setup

    When a user first logs in on Windows 9X, the file user.DAT is created, @@ -6882,7 +7427,7 @@ as are folders "Start Menu", "Desktop", "Programs" and "Nethood". These directories and their contents will be merged with the local versions stored in c:\windows\profiles\username on subsequent logins, taking the most recent from each. You will need to use the [global] -options "preserve case = yes", "short case preserve = yes" and +options "preserve case = yes", "short preserve case = yes" and "case sensitive = no" in order to maintain capital letters in shortcuts in any of the profile folders.

  • search for the user's .PWL password-cacheing file in the c:\windows +> search for the user's .PWL password-caching file in the c:\windows directory, and delete it.

    • 7.8.2.5. Windows NT Workstation 4.08.8.2.5. Windows NT Workstation 4.0

    When a user first logs in to a Windows NT Workstation, the profile @@ -7091,11 +7636,11 @@ case, or whether there is some configuration issue, as yet unknown, that makes NT Workstation _think_ that the link is a slow one is a matter to be resolved].

    [lkcl 20aug97 - after samba digest correspondance, one user found, and +>[lkcl 20aug97 - after samba digest correspondence, one user found, and another confirmed, that profiles cannot be loaded from a samba server unless "security = user" and "encrypt passwords = yes" (see the file ENCRYPTION.txt) or "security = server" and "password server = ip.address. -of.yourNTserver" are used. either of these options will allow the NT +of.yourNTserver" are used. Either of these options will allow the NT workstation to access the samba server using LAN manager encrypted passwords, without the user intervention normally required by NT workstation for clear-text passwords].

    7.8.2.6. Windows NT Server8.8.2.6. Windows NT Server

    There is nothing to stop you specifying any path that you like for the @@ -7125,8 +7670,8 @@ CLASS="SECT3" >

    7.8.2.7. Sharing Profiles between W95 and NT Workstation 4.08.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0

    7.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba8.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba

    The User database is called the SAM (Security Access Manager) database and is used for all user authentication as well as for authentication of inter- -process authentication (ie: to ensure that the service action a user has +process authentication (i.e. to ensure that the service action a user has requested is permitted within the limits of that user's privileges).

    The Samba team have produced a utility that can dump the Windows NT SAM into @@ -7298,7 +7843,7 @@ to Samba systems.

    Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers can participate in a Domain security system that is controlled by Windows NT -servers that have been correctly configured. At most every domain will have +servers that have been correctly configured. Almost every domain will have ONE Primary Domain Controller (PDC). It is desirable that each domain will have at least one Backup Domain Controller (BDC).

    Chapter 8. Unifed Logons between Windows NT and UNIX using WinbindChapter 9. Unified Logons between Windows NT and UNIX using Winbind

    8.1. Abstract9.1. Abstract

    Integration of UNIX and Microsoft Windows NT through a unified logon has been considered a "holy grail" in heterogeneous - computing environments for a long time. We present winbind - , a component of the Samba suite of programs as a - solution to the unied logon problem. Winbind uses a UNIX implementation + computing environments for a long time. We present + winbind, a component of the Samba suite + of programs as a solution to the unified logon problem. Winbind + uses a UNIX implementation of Microsoft RPC calls, Pluggable Authentication Modules, and the Name Service Switch to allow Windows NT domain users to appear and operate as UNIX users on a UNIX machine. This paper describes the winbind @@ -7341,8 +7887,8 @@ CLASS="SECT1" >

    8.2. Introduction9.2. Introduction

    It is well known that UNIX and Microsoft Windows NT have @@ -7356,11 +7902,11 @@ NAME="AEN1542" and use the Samba suite of programs to provide file and print services between the two. This solution is far from perfect however, as adding and deleting users on both sets of machines becomes a chore - and two sets of passwords are required both of which which + and two sets of passwords are required both of which can lead to synchronization problems between the UNIX and Windows systems and confusion for users.

    We divide the unifed logon problem for UNIX machines into +>We divide the unified logon problem for UNIX machines into three smaller problems:

    8.3. What Winbind Provides9.3. What Winbind Provides

    Winbind unifies UNIX and Windows NT account management by @@ -7409,7 +7955,7 @@ NAME="AEN1555" >The end result is that whenever any program on the UNIX machine asks the operating system to lookup a user or group name, the query will be resolved by asking the - NT domain controller for the specied domain to do the lookup. + 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 @@ -7426,28 +7972,28 @@ NAME="AEN1555" that redirection to a domain controller is wanted for a particular lookup and which trusted domain is being referenced.

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

    8.3.1. Target Uses9.3.1. Target Uses

    Winbind is targeted at organizations that have an existing NT based domain infrastructure into which they wish to put UNIX workstations or servers. Winbind will allow these organizations to deploy UNIX workstations without having to - maintain a separate account infrastructure. This greatly simplies - the administrative overhead of deploying UNIX workstations into - a NT based organization.

    Another interesting way in which we expect Winbind to be used is as a central part of UNIX based appliances. Appliances @@ -7461,8 +8007,8 @@ CLASS="SECT1" >

    8.4. How Winbind Works9.4. How Winbind Works

    The winbind system is designed around a client/server @@ -7481,8 +8027,8 @@ CLASS="SECT2" >

    8.4.1. Microsoft Remote Procedure Calls9.4.1. Microsoft Remote Procedure Calls

    Over the last two years, efforts have been underway @@ -7507,18 +8053,18 @@ CLASS="SECT2" >

    8.4.2. Name Service Switch9.4.2. Name Service Switch

    The Name Service Switch, or NSS, is a feature that is present in many UNIX operating systems. It allows system information such as hostnames, mail aliases and user information - to be resolved from dierent sources. For example, a standalone + to be resolved from different sources. For example, a standalone UNIX workstation may resolve system information from a series of - flat files stored on the local lesystem. A networked workstation + flat files stored on the local filesystem. A networked workstation may first attempt to resolve system information from local files, - then consult a NIS database for user information or a DNS server + and then consult a NIS database for user information or a DNS server for hostname information.

    The NSS application programming interface allows winbind @@ -7531,11 +8077,12 @@ NAME="AEN1575" a NT domain plus any trusted domain as though they were local users and groups.

    The primary control le for NSS is The primary control file for NSS is + /etc/nsswitch.conf - . When a UNIX application makes a request to do a lookup +>/etc/nsswitch.conf. + When a UNIX application makes a request to do a lookup the C library looks in /etc/nsswitch.conf

    8.4.3. Pluggable Authentication Modules9.4.3. Pluggable Authentication Modules

    Pluggable Authentication Modules, also known as PAM, is a system for abstracting authentication and authorization technologies. With a PAM module it is possible to specify different - authentication methods for dierent system applications without + authentication methods for different system applications without having to recompile these applications. PAM is also useful for implementing a particular policy for authorization. For example, a system administrator may only allow console logins from users @@ -7605,10 +8152,10 @@ NAME="AEN1591" UNIX system. This allows Windows NT users to log in to a UNIX machine and be authenticated against a suitable Primary Domain Controller. These users can also change their passwords and have - this change take eect directly on the Primary Domain Controller. + this change take effect directly on the Primary Domain Controller.

    PAM is congured by providing control files in the directory +>PAM is configured by providing control files in the directory /etc/pam.d//lib/security/ and the pam +> and the PAM control files for relevant services are updated to allow authentication via winbind. See the PAM documentation for more details.

    8.4.4. User and Group ID Allocation9.4.4. User and Group ID Allocation

    When a user or group is created under Windows NT - is it allocated a numerical relative identier (RID). This is - slightly dierent to UNIX which has a range of numbers which are + is it allocated a numerical relative identifier (RID). This is + slightly different to UNIX which has a range of numbers that are used to identify users, and the same range in which to identify groups. It is winbind's job to convert RIDs to UNIX id numbers and - vice versa. When winbind is congured it is given part of the UNIX + vice versa. When winbind is configured it is given part of the UNIX user id space and a part of the UNIX group id space in which to store Windows NT users and groups. If a Windows NT user is resolved for the first time, it is allocated the next UNIX id from @@ -7653,7 +8200,7 @@ NAME="AEN1599" to UNIX user ids and group ids.

    The results of this mapping are stored persistently in - a ID mapping database held in a tdb database). This ensures that + an ID mapping database held in a tdb database). This ensures that RIDs are mapped to UNIX IDs in a consistent way.

    8.4.5. Result Caching9.4.5. Result Caching

    An active system can generate a lot of user and group - name lookups. To reduce the network cost of these lookups winbind - uses a caching scheme based on the SAM sequence number supplied - by NT domain controllers. User or group information returned - by a PDC is cached by winbind along with a sequence number also - returned by the PDC. This sequence number is incremented by - Windows NT whenever any user or group information is modied. If - a cached entry has expired, the sequence number is requested from - the PDC and compared against the sequence number of the cached entry. - If the sequence numbers do not match, then the cached information - is discarded and up to date information is requested directly - from the PDC.

    8.5. Installation and Configuration

    The easiest way to install winbind is by using the packages - provided in the pub/samba/appliance/ - directory on your nearest - Samba mirror. These packages provide snapshots of the Samba source - code and binaries already setup to provide the full functionality - of winbind. This setup is a little more complex than a normal Samba - build as winbind needs a small amount of functionality from a - development code branch called SAMBA_TNG.

    Once you have installed the packages you should read - the winbindd(8) man page which will provide you - with conguration information and give you sample conguration files. - You may also wish to update the main Samba daemons smbd and nmbd) - with a more recent development release, such as the recently - announced Samba 2.2 alpha release.

    8.6. Limitations

    Winbind has a number of limitations in its current - released version which we hope to overcome in future - releases:

    • Winbind is currently only available for - the Linux operating system, although ports to other operating - systems are certainly possible. For such ports to be feasible, - we require the C library of the target operating system to - support the Name Service Switch and Pluggable Authentication - Modules systems. This is becoming more common as NSS and - PAM gain support among UNIX vendors.

    • The mappings of Windows NT RIDs to UNIX ids - is not made algorithmically and depends on the order in which - unmapped users or groups are seen by winbind. It may be difficult - to recover the mappings of rid to UNIX id mapping if the file - containing this information is corrupted or destroyed.

    • Currently the winbind PAM module does not take - into account possible workstation and logon time restrictions - that may be been set for Windows NT users.

    • Building winbind from source is currently - quite tedious as it requires combining source code from two Samba - branches. Work is underway to solve this by providing all - the necessary functionality in the main Samba code branch.

    8.7. Conclusion

    The winbind system, through the use of the Name Service - Switch, Pluggable Authentication Modules, and appropriate - Microsoft RPC calls have allowed us to provide seamless - integration of Microsoft Windows NT domain users on a - UNIX system. The result is a great reduction in the administrative - cost of running a mixed UNIX and NT network.

    Chapter 9. UNIX Permission Bits and WIndows NT Access Control Lists

    9.1. Viewing and changing UNIX permissions using the NT - security dialogs

    New in the Samba 2.0.4 release is the ability for Windows - NT clients to use their native security settings dialog box to - view and modify the underlying UNIX permissions.

    Note that this ability is careful not to compromise - the security of the UNIX host Samba is running on, and - still obeys all the file permission rules that a Samba - administrator can set.

    In Samba 2.0.4 and above the default value of the - parameter nt acl support has been changed from - false to true, so - manipulation of permissions is turned on by default.

    9.2. How to view file security on a Samba share9.5. Installation and Configuration

    From an NT 4.0 client, single-click with the right - mouse button on any file or directory in a Samba mounted - drive letter or UNC path. When the menu pops-up, click - on the Properties entry at the bottom of - the menu. This brings up the normal file properties dialog - box, but with Samba 2.0.4 this will have a new tab along the top - marked Security. Click on this tab and you - will see three buttons, Permissions, - Auditing, and Ownership. - The Auditing button will cause either - an error message A requested privilege is not held - by the client to appear if the user is not the - NT Administrator, or a dialog which is intended to allow an - Administrator to add auditing requirements to a file if the - user is logged on as the NT Administrator. This dialog is - non-functional with a Samba share at this time, as the only - useful button, the Add button will not currently - allow a list of users to be seen.

    Many thanks to John Trostel jtrostel@snapserver.com +for providing the HOWTO for this section.

    This HOWTO describes how to get winbind services up and running +to control access and authenticate users on your Linux box using +the winbind services which come with SAMBA 2.2.2.

    9.3. Viewing file ownership

    9.5.1. Introduction

    Clicking on the "Ownership" button - brings up a dialog box telling you who owns the given file. The - owner name will be of the form :

    This HOWTO describes the procedures used to get winbind up and +running on my RedHat 7.1 system. Winbind is capable of providing access +and authentication control for Windows Domain users through an NT +or Win2K PDC for 'regular' services, such as telnet a nd ftp, as +well for SAMBA services.

    This HOWTO has been written from a 'RedHat-centric' perspective, so if +you are using another distribution, you may have to modify the instructions +somewhat to fit the way your distribution works.

    "SERVER\user (Long name)"

    • Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) Why should I to this? - is the discriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). Click on the Close - button to remove this dialog.

      If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone".

      This allows the SAMBA administrator to rely on the + authentication mechanisms on the NT/Win2K PDC for the authentication + of domain members. NT/Win2K users no longer need to have separate + accounts on the SAMBA server. +

    • The Take Ownership button will not allow - you to change the ownership of this file to yourself (clicking on - it will display a dialog box complaining that the user you are - currently logged onto the NT client cannot be found). The reason - for this is that changing the ownership of a file is a privilaged - operation in UNIX, available only to the root - user. As clicking on this button causes NT to attempt to change - the ownership of a file to the current user logged into the NT - client this will not work with Samba at this time.

      Who should be reading this document? +

      There is an NT chown command that will work with Samba - and allow a user with Administrator privillage connected - to a Samba 2.0.4 server as root to change the ownership of - files on both a local NTFS filesystem or remote mounted NTFS - or Samba drive. This is available as part of the Seclib - NT security library written by Jeremy Allison of - the Samba Team, available from the main Samba ftp site.

      This HOWTO is designed for system administrators. If you are + implementing SAMBA on a file server and wish to (fairly easily) + integrate existing NT/Win2K users from your PDC onto the + SAMBA server, this HOWTO is for you. That said, I am no NT or PAM + expert, so you may find a better or easier way to accomplish + these tasks. +

    9.4. Viewing file or directory permissions

    The third button is the "Permissions" - button. Clicking on this brings up a dialog box that shows both - the permissions and the UNIX owner of the file or directory. - The owner is displayed in the form :

    9.5.2. Requirements

    "SERVER\user (Long name)"

    If you have a samba configuration file that you are currently +using... BACK IT UP! If your system already uses PAM, BACK UP +THE /etc/pam.d directory contents! If you +haven't already made a boot disk, MAKE ON NOW!

    Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the discriptive string identifying the user (normally found in the - GECOS field of the UNIX password database).

    Messing with the pam configuration files can make it nearly impossible +to log in to yourmachine. That's why you want to be able to boot back +into your machine in single user mode and restore your +/etc/pam.d back to the original state they were in if +you get frustrated with the way things are going. ;-)

    If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone" and the - permissions will be shown as NT "Full Control".

    The newest version of SAMBA (version 2.2.2), available from +cvs.samba.org, now include a functioning winbindd daemon. Please refer +to the main SAMBA web page or, better yet, your closest SAMBA mirror +site for instructions on downloading the source code.

    The permissions field is displayed differently for files - and directories, so I'll describe the way file permissions - are displayed first.

    To allow Domain users the ability to access SAMBA shares and +files, as well as potentially other services provided by your +SAMBA machine, PAM (pluggable authentication modules) must +be setup properly on your machine. In order to compile the +winbind modules, you should have at least the pam libraries resident +on your system. For recent RedHat systems (7.1, for instance), that +means 'pam-0.74-22'. For best results, it is helpful to also +install the development packages in 'pam-devel-0.74-22'.

    9.4.1. File Permissions9.5.3. Testing Things Out

    The standard UNIX user/group/world triple and - the correspinding "read", "write", "execute" permissions - triples are mapped by Samba into a three element NT ACL - with the 'r', 'w', and 'x' bits mapped into the corresponding - NT permissions. The UNIX world permissions are mapped into - the global NT group Everyone, followed - by the list of permissions allowed for UNIX world. The UNIX - owner and group permissions are displayed as an NT - user icon and an NT local - group icon respectively followed by the list - of permissions allowed for the UNIX user and group.

    As many UNIX permission sets don't map into common - NT names such as "read", "change" or "full control" then - usually the permissions will be prefixed by the words Before starting, it is probably best to kill off all the SAMBA +related daemons running on your server. Kill off all "Special Access" in the NT display list.

    But what happens if the file has no permissions allowed - for a particular UNIX user group or world component ? In order - to allow "no permissions" to be seen and modified then Samba - overloads the NT smbd, +"Take Ownership" ACL attribute - (which has no meaning in UNIX) and reports a component with - no permissions as having the NT nmbd, and "O" bit set. - This was chosen of course to make it look like a zero, meaning - zero permissions. More details on the decision behind this will - be given below.

    winbindd processes that may +be running. To use PAM, you will want to make sure that you have the +standard PAM package (for RedHat) which supplies the /etc/pam.d +directory structure, including the pam modules are used by pam-aware +services, several pam libraries, and the /usr/doc +and /usr/man entries for pam. Winbind built better +in SAMBA if the pam-devel package was also installed. This package includes +the header files needed to compile pam-aware applications. For instance, my RedHat +system has both 'pam-0.74-22' and 'pam-devel-0.74-22' RPMs installed.

    9.4.2. Directory Permissions

    9.5.3.1. Configure and compile SAMBA

    Directories on an NT NTFS file system have two - different sets of permissions. The first set of permissions - is the ACL set on the directory itself, this is usually displayed - in the first set of parentheses in the normal "RW" - NT style. This first set of permissions is created by Samba in - exactly the same way as normal file permissions are, described - above, and is displayed in the same way.

    The configuration and compilation of SAMBA is pretty straightforward. +The first three steps maynot be necessary depending upon +whether or not you have previously built the Samba binaries.

    The second set of directory permissions has no real meaning - in the UNIX permissions world and represents the "inherited" permissions that any file created within - this directory would inherit.

    root#  autoconf
+root#  make clean
+root#  rm config.cache
+root#  ./configure --with-winbind
+root#  make
+root#  make install

    Samba synthesises these inherited permissions for NT by - returning as an NT ACL the UNIX permission mode that a new file - created by Samba on this share would receive.

    This will, by default, install SAMBA in /usr/local/samba. See the +main SAMBA documentation if you want to install SAMBA somewhere else. +It will also build the winbindd executable and libraries.

    9.5. Modifying file or directory permissions

    9.5.3.2. Configure nsswitch.conf and the winbind libraries

    Modifying file and directory permissions is as simple - as changing the displayed permissions in the dialog box, and - clicking the OK button. However, there are - limitations that a user needs to be aware of, and also interactions - with the standard Samba permission masks and mapping of DOS - attributes that need to also be taken into account.

    The libraries needed to run the winbind daemon through nsswitch +need to be copied to their proper locations, so

    If the parameter nt acl support - is set to false then any attempt to set - security permissions will fail with an "Access Denied" - message.

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

    The first thing to note is that the I also found it necessary to make the following symbolic link:

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

    Now, as root you need to edit /etc/nsswitch.conf to +allow user and group entries to be visible from the "Add"winbindd - button will not return a list of users in Samba 2.0.4 (it will give - an error message of "The remote proceedure call failed - and did not execute"). This means that you can only - manipulate the current user/group/world permissions listed in - the dialog box. This actually works quite well as these are the - only permissions that UNIX actually has.

    /etc/nsswitch.conf     file look like this after editing:

    If a permission triple (either user, group, or world) - is removed from the list of permissions in the NT dialog box, - then when the "OK" button is pressed it will - be applied as "no permissions" on the UNIX side. If you then - view the permissions again the "no permissions" entry will appear - as the NT "O" flag, as described above. This - allows you to add permissions back to a file or directory once - you have removed them from a triple component.

    	passwd:     files winbind
+	shadow:     files winbind
+	group:      files winbind

    As UNIX supports only the "r", "w" and "x" bits of - an NT ACL then if other NT security attributes such as "Delete - access" are selected then they will be ignored when applied on - the Samba server.

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

    When setting permissions on a directory the second - set of permissions (in the second set of parentheses) is - by default applied to all files within that directory. If this - is not what you want you must uncheck the "Replace - permissions on existing files" checkbox in the NT - dialog before clicking "OK".

    root# /sbin/ldconfig -v | grep winbind

    If you wish to remove all permissions from a - user/group/world component then you may either highlight the - component and click the "Remove" button, - or set the component to only have the special "Take - Ownership" permission (dsplayed as This makes libnss_winbind available to winbindd +and echos back a check to you.

    9.5.3.3. Configure smb.conf

    Several parameters are needed in the smb.conf file to control +the behavior of "O" - ) highlighted.

    winbindd. Configure +smb.conf These are described in more detail in +the winbindd(8) man page. My +smb.conf file was modified to +include the following entries in the [global] section:

    [global]
+     <...>
+     # separate domain and username with '+', like DOMAIN+username
+     winbind separator = +
+     # use uids from 10000 to 20000 for domain users
+     winbind uid = 10000-20000
+     # use gids from 10000 to 20000 for domain groups
+     winbind 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 shell = /bin/bash

    9.6. Interaction with the standard Samba create mask - parameters

    9.5.3.4. Join the SAMBA server to the PDC domain

    Note that with Samba 2.0.5 there are four new parameters - to control this interaction. These are :

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

    root# /usr/local/samba/bin/smbpasswd -j DOMAIN -r PDC -U Administrator

    The proper response to the command should be: "Joined the domain +security maskDOMAIN

    " where DOMAIN +is your DOMAIN name.

    9.5.3.5. Start up the winbindd daemon and test it!

    Eventually, you will want to modify your smb 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/bin/winbindd

    I'm always paranoid and like to make sure the daemon +is really running...

    root# ps -ae | grep winbindd +3025 ? 00:00:00 winbindd

    force security mode

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

    directory security maskroot# # /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 winbindd separator is '+'.

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

    force directory security moderoot# /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

    Once a user clicks "OK" to apply the - permissions Samba maps the given permissions into a user/group/world - r/w/x triple set, and then will check the changed permissions for a - file against the bits set in the - security mask parameter. Any bits that - were changed that are not set to '1' in this parameter are left alone - in the file permissions.

    Essentially, zero bits in the security mask - mask may be treated as a set of bits the user is not - allowed to change, and one bits are those the user is allowed to change. -

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

    If not set explicitly this parameter is set to the same value as - the create mask - parameter to provide compatibility with Samba 2.0.4 - where this permission change facility was introduced. To allow a user to - modify all the user/group/world permissions on a file, set this parameter - to 0777.

    root# getent passwd

    Next Samba checks the changed permissions for a file against - the bits set in the force security mode parameter. Any bits - that were changed that correspond to bits set to '1' in this parameter - are forced to be set.

    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.

    Essentially, bits set in the force security mode - parameter may be treated as a set of bits that, when - modifying security on a file, the user has always set to be 'on'.

    The same thing can be done for groups with the command

    If not set explicitly this parameter is set to the same value - as the force - create mode parameter to provide compatibility - with Samba 2.0.4 where the permission change facility was introduced. - To allow a user to modify all the user/group/world permissions on a file, - with no restrictions set this parameter to 000.

    root# getent group

    9.5.3.6. Fix the /etc/rc.d/init.d/smb startup files

    The security mask and force - security mode parameters are applied to the change - request in that order.

    The winbindd daemon needs to start up after the +smbd and nmbd daemons are running. +To accomplish this task, you need to modify the /etc/init.d/smb +script to add commands to invoke this daemon in the proper sequence. My +/etc/init.d/smb file starts up smbd, +nmbd, and winbindd from the +/usr/local/samba/bin directory directly. The 'start' +function in the script looks like this:

    For a directory Samba will perform the same operations as - described above for a file except using the parameter directory security mask instead of security - mask, and force directory security mode - parameter instead of force security mode - .

    start() {
+        KIND="SMB"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
+        RETVAL=$?
+        echo
+        KIND="NMB"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
+        RETVAL2=$?
+        echo
+        KIND="Winbind"
+        echo -n $"Starting $KIND services: "
+        daemon /usr/local/samba/bin/winbindd
+        RETVAL3=$?
+        echo
+        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && touch /var/lock/subsys/smb || \
+           RETVAL=1
+        return $RETVAL
+}

    The directory security mask parameter - by default is set to the same value as the directory mask - parameter and the force directory security - mode parameter by default is set to the same value as - the force directory mode parameter to provide - compatibility with Samba 2.0.4 where the permission change facility - was introduced.

    The 'stop' function has a corresponding entry to shut down the +services and look s like this:

    stop() {
+        KIND="SMB"
+        echo -n $"Shutting down $KIND services: "
+        killproc smbd
+        RETVAL=$?
+        echo
+        KIND="NMB"
+        echo -n $"Shutting down $KIND services: "
+        killproc nmbd
+        RETVAL2=$?
+        echo
+        KIND="Winbind"
+        echo -n $"Shutting down $KIND services: "
+        killproc winbindd
+        RETVAL3=$?
+        [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && rm -f /var/lock/subsys/smb
+        echo ""
+        return $RETVAL
+}

    9.5.3.7. Configure Winbind and PAM

    In this way Samba enforces the permission restrictions that - an administrator can set on a Samba share, whilst still allowing users - to modify the permission bits within that restriction.

    If you have made it this far, you know that winbindd is working. +Now it is time to integrate it into the operation of samba and other +services. The pam configuration files need to be altered in +this step. (Did you remember to make backups of your original +/etc/pam.d files? If not, do it now.)

    If you want to set up a share that allows users full control - in modifying the permission bits on their files and directories and - doesn't force any particular bits to be set 'on', then set the following - parameters in the To get samba to allow domain users and groups, I modified the +smb.conf(5) - file in that share specific section :

    /etc/pam.d/samba file from

    security mask = 0777
    auth    required        /lib/security/pam_stack.so service=system-auth
+account required        /lib/security/pam_stack.so service=system-auth

    force security mode = 0

    to

    directory security mask = 0777
    auth    required        /lib/security/pam_winbind.so
+auth    required        /lib/security/pam_stack.so service=system-auth
+account required        /lib/security/pam_winbind.so
+account required        /lib/security/pam_stack.so service=system-auth

    force directory security mode = 0The other services that I modified to allow the use of winbind +as an authentication service were the normal login on the console (or a terminal +session), telnet logins, and ftp service. In order to enable these +services, you may first need to change the entries in +/etc/xinetd.d (or /etc/inetd.conf). +RedHat 7.1 uses the new xinetd.d structure, in this case you need +to change the lines in /etc/xinetd.d/telnet +and /etc/xinetd.d/wu-ftp from 

    enable = no

    As described, in Samba 2.0.4 the parameters :

    to

    create mask
    enable = yes

    force create mode

    +For ftp services to work properly, you will also need to either +have individual directories for the domain users already present on +the server, or change the home directory template to a general +directory for all domain users. These can be easily set using +the smb.conf global entry +template homedir.

    directory maskThe /etc/pam.d/ftp file can be changed +to allow winbind ftp access in a manner similar to the +samba file. My /etc/pam.d/ftp file was +changed to look like this:

    auth       sufficient   /lib/security/pam_winbind.so
+auth       required     /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
+auth       required     /lib/security/pam_stack.so service=system-auth
+auth       required     /lib/security/pam_shells.so
+account    required     /lib/security/pam_stack.so service=system-auth
+session    required     /lib/security/pam_stack.so service=system-auth

    force directory modeThe /etc/pam.d/login file can be changed nearly the +same way. It now looks like this:

    auth       required     /lib/security/pam_securetty.so
+auth       sufficient   /lib/security/pam_winbind.so
+auth       sufficient   /lib/security/pam_unix.so use_first_pass
+auth       required     /lib/security/pam_stack.so service=system-auth
+auth       required     /lib/security/pam_nologin.so
+account    sufficient   /lib/security/pam_winbind.so
+account    required     /lib/security/pam_stack.so service=system-auth
+password   required     /lib/security/pam_stack.so service=system-auth
+session    required     /lib/security/pam_stack.so service=system-auth
+session    optional     /lib/security/pam_console.so

    were used instead of the parameters discussed here.

    In this case, I added the auth sufficient /lib/security/pam_winbind.so +lines as before, but also added the required pam_securetty.so +above it, to disallow root logins over the network. I also added a +sufficient /lib/security/pam_unix.so use_first_pass +line after the winbind.so line to get rid of annoying +double prompts for passwords.

    Finally, don't forget to copy the winbind pam modules from +the source directory in which you originally compiled the new +SAMBA up to the /lib/security directory so that pam can use it:

    root# cp ../samba/source/nsswitch/pam_winbind.so /lib/security

    9.7. Interaction with the standard Samba file attribute - mapping9.6. Limitations

    Samba maps some of the DOS attribute bits (such as "read - only") into the UNIX permissions of a file. This means there can - be a conflict between the permission bits set via the security - dialog and the permission bits set by the file attribute mapping. -

    Winbind has a number of limitations in its current + released version that we hope to overcome in future + releases:

    One way this can show up is if a file has no UNIX read access - for the owner it will show up as "read only" in the standard - file attributes tabbed dialog. Unfortunately this dialog is - the same one that contains the security info in another tab.

    • What this can mean is that if the owner changes the permissions - to allow themselves read access using the security dialog, clicks - "OK" to get back to the standard attributes tab - dialog, and then clicks "OK" on that dialog, then - NT will set the file permissions back to read-only (as that is what - the attributes still say in the dialog). This means that after setting - permissions and clicking "OK" to get back to the - attributes dialog you should always hit "Cancel" - rather than "OK" to ensure that your changes - are not overridden.

      Winbind is currently only available for + the Linux operating system, although ports to other operating + systems are certainly possible. For such ports to be feasible, + we require the C library of the target operating system to + support the Name Service Switch and Pluggable Authentication + Modules systems. This is becoming more common as NSS and + PAM gain support among UNIX vendors.

    • The mappings of Windows NT RIDs to UNIX ids + is not made algorithmically and depends on the order in which + unmapped users or groups are seen by winbind. It may be difficult + to recover the mappings of rid to UNIX id mapping if the file + containing this information is corrupted or destroyed.

    • Currently the winbind PAM module does not take + into account possible workstation and logon time restrictions + that may be been set for Windows NT users.

    9.7. Conclusion

    The winbind system, through the use of the Name Service + Switch, Pluggable Authentication Modules, and appropriate + Microsoft RPC calls have allowed us to provide seamless + integration of Microsoft Windows NT domain users on a + UNIX system. The result is a great reduction in the administrative + cost of running a mixed UNIX and NT network.

    Chapter 10. OS2 Client HOWTO

    10.1. FAQs

    10.1.1. How can I configure OS/2 Warp Connect or OS/2 Warp 4 as a client for Samba?

    10.1.2. How can I configure OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x for Samba?

    10.1.3. Are there any other issues when OS/2 (any version) is used as a client?

    10.1.4. How do I get printer driver download working for OS/2 clients?

    Install the NT driver first for that printer. Then, - add to your smb.conf a paramater, "os2 driver map = + add to your smb.conf a parameter, "os2 driver map =

    Chapter 11. HOWTO Access Samba source code via CVS

    11.1. Introduction

    Samba is developed in an open environnment. Developers use CVS +>Samba is developed in an open environment. Developers use CVS (Concurrent Versioning System) to "checkin" (also known as "commit") new source code. Samba's various CVS branches can -be accessed via anonymouns CVS using the instructions +be accessed via anonymous CVS using the instructions detailed in this chapter.

    This document is a modified version of the instructions found at @@ -8760,7 +9325,7 @@ CLASS="SECT1" >

    11.2. CVS Access to samba.org

    11.2.1. Access via CVSweb

    11.2.2. Access via cvs

    You can also access the source code via a normal cvs client. This gives you much more control over you can do with the repository and allows you to checkout whole source trees -and keep them uptodate via normal cvs commands. This is the +and keep them up to date via normal cvs commands. This is the preferred method of access if you are a developer and not just a casual browser.

    Index

    Primary Domain Controller, + Background +