From d00b6f125fd98d1842cba57c7b509d52470c82d7 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 2 Apr 2003 18:07:52 +0000 Subject: Regenerate docs (This used to be commit 20ee66b661e295cc9fb66f00b16de3b382a7e723) --- docs/htmldocs/ads.html | 165 +---- docs/htmldocs/appendixes.html | 176 +++-- docs/htmldocs/browsing-quick.html | 85 ++- docs/htmldocs/bugreport.html | 12 +- docs/htmldocs/compiling.html | 142 +++- docs/htmldocs/diagnosis.html | 30 +- docs/htmldocs/domain-security.html | 63 +- docs/htmldocs/groupmapping.html | 26 +- docs/htmldocs/improved-browsing.html | 104 +-- docs/htmldocs/integrate-ms-networks.html | 602 +++-------------- docs/htmldocs/introduction.html | 74 ++- docs/htmldocs/msdfs.html | 34 +- docs/htmldocs/optional.html | 611 ++++++++--------- docs/htmldocs/other-clients.html | 28 +- docs/htmldocs/pam.html | 212 +++--- docs/htmldocs/passdb.html | 56 +- docs/htmldocs/portability.html | 22 +- docs/htmldocs/printing.html | 58 +- docs/htmldocs/samba-bdc.html | 22 +- docs/htmldocs/samba-howto-collection.html | 563 ++++++++-------- docs/htmldocs/samba-pdc.html | 1015 ++--------------------------- docs/htmldocs/securing-samba.html | 38 +- docs/htmldocs/securitylevels.html | 295 ++++++++- docs/htmldocs/speed.html | 68 +- docs/htmldocs/type.html | 162 ++--- docs/htmldocs/unix-permissions.html | 101 +-- docs/htmldocs/vfs.html | 56 +- docs/htmldocs/winbind.html | 70 +- 28 files changed, 1990 insertions(+), 2900 deletions(-) (limited to 'docs/htmldocs') diff --git a/docs/htmldocs/ads.html b/docs/htmldocs/ads.html index ef019915d8..f37bbf0abc 100644 --- a/docs/htmldocs/ads.html +++ b/docs/htmldocs/ads.html @@ -13,7 +13,7 @@ REL="UP" TITLE="Type of installation" HREF="type.html">

This is a rough guide to setting up Samba 3.0 with kerberos authentication against a Windows2000 KDC.

Pieces you need before you begin:

a Windows 2000 server.
samba 3.0 or higher.
the MIT kerberos development libraries (either install from the above sources or use a package). The heimdal libraries will not work.
the OpenLDAP development libraries.

8.1. Installing the required packages for Debian

On Debian you need to install the following packages:

libkrb5-dev
krb5-user

8.2. Installing the required packages for RedHat

On RedHat this means you should have at least:

krb5-workstation (for kinit)
krb5-libs (for linking with)
krb5-devel (because you are compiling from source)

in addition to the standard development environment.

Note that these are not standard on a RedHat install, and you may need -to get them off CD2.

8.3. Compile Samba8.1. Setup your smb.conf

If your kerberos libraries are in a non-standard location then - remember to add the configure option --with-krb5=DIR.

After you run configure make sure that include/config.h it - generates contains - lines like this:

#define HAVE_KRB5 1
-#define HAVE_LDAP 1

If it doesn't then configure did not find your krb5 libraries or - your ldap libraries. Look in config.log to figure out why and fix - it.

Then compile and install Samba as usual. You must use at least the - following 3 options in smb.conf:

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

You do *not* need a smbpasswd file, and older clients will
   be authenticated as if "security = domain", although it won't do any harm
   and allows you to have local users not in the domain.
-  I expect that the above
-  required options will change soon when we get better active
-  directory integration.

8.4. Setup your /etc/krb5.conf8.2. Setup your /etc/krb5.conf

The minimal configuration for krb5.conf is:

8.5. Create the computer account8.3. Create the computer account

As a user that has write permission on the Samba private directory @@ -291,8 +180,8 @@ CLASS="SECT2" >

8.5.1. Possible errors8.3.1. Possible errors

8.6. Test your server setup8.4. Test your server setup

On a Windows 2000 client try

8.7. Testing with smbclient8.5. Testing with smbclient

On your Samba server try to login to a Win2000 server or your Samba @@ -349,12 +238,12 @@ CLASS="SECT1" >

8.8. Notes8.6. Notes

You must change administrator password at least once after DC install, - to create the right encoding types

You must change administrator password at least once after DC +install, to create the right encoding types

w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in their defaults DNS setup. Maybe fixed in service packs?

How to Act as a Backup Domain Controller in a Purely Samba Controlled DomainSamba Backup Domain Controller to Samba Domain ControlNextTable of Contents
23. Samba performance issues
23.1. Comparisons
23.2. Socket options
23.3. Read size
23.4. Max xmit
23.5. Log level
23.6. Read raw
23.7. Write raw
23.8. Slow Clients
23.9. Slow Logins
23.10. Client tuning
24. Portability
24.1. HPUX
24.2. SCO Unix
24.3. DNIX
24.4. RedHat Linux Rembrandt-II
24.5. AIX
24.5.1. Sequential Read Ahead
25.1. Macintosh clients?
25.2. OS2 Client
25.2.1. How can I configure OS/2 Warp Connect or OS/2 Warp 4 as a client for Samba?
25.2.2. How can I configure OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x for Samba?
25.2.3. Are there any other issues when OS/2 (any version) is used as a client?
25.2.4. How do I get printer driver download working for OS/2 clients?
25.3. Windows for Workgroups
25.3.1. Use latest TCP/IP stack from Microsoft
25.3.2. Delete .pwl files after password change
25.3.3. Configure WfW password handling
25.3.4. Case handling of passwords
25.3.5. Use TCP/IP as default protocol
25.4. Windows '95/'98
25.5. Windows 2000 Service Pack 2
26.1. Access Samba source code via CVS
26.1.1. Introduction
26.1.2. CVS Access to samba.org
26.2. Accessing the samba sources via rsync and ftp
26.3. Building the Binaries
26.3.1. Compiling samba with Active Directory support
26.4. Starting the smbd and nmbd
26.4.1. Starting from inetd.conf
26.4.2. Alternative: starting it as a daemon
27.1. Introduction
27.2. General info
27.3. Debug levels
27.4. Internal errors
27.5. Attaching to a running process
27.6. Patches
28.1. Introduction
28.2. Assumptions
28.3. Tests
28.3.1. Test 1
28.3.2. Test 2
28.3.3. Test 3
28.3.4. Test 4
28.3.5. Test 5
28.3.6. Test 6
28.3.7. Test 7
28.3.8. Test 8
28.3.9. Test 9
28.3.10. Test 10
28.3.11. Test 11
28.4. Still having troubles?
NextPortabilitySamba performance issues
2.2. Use of the "Remote Announce" parameter2.2. How browsing functions and how to deploy stable and +dependable browsing using Samba

As stated above, MS Windows machines register their NetBIOS names +(i.e.: the machine name for each service type in operation) on start +up. Also, as stated above, the exact method by which this name registration +takes place is determined by whether or not the MS Windows client/server +has been given a WINS server address, whether or not LMHOSTS lookup +is enabled, or if DNS for NetBIOS name resolution is enabled, etc.

In the case where there is no WINS server all name registrations as +well as name lookups are done by UDP broadcast. This isolates name +resolution to the local subnet, unless LMHOSTS is used to list all +names and IP addresses. In such situations Samba provides a means by +which the samba server name may be forcibly injected into the browse +list of a remote MS Windows network (using the "remote announce" parameter).

Where a WINS server is used, the MS Windows client will use UDP +unicast to register with the WINS server. Such packets can be routed +and thus WINS allows name resolution to function across routed networks.

During the startup process an election will take place to create a +local master browser if one does not already exist. On each NetBIOS network +one machine will be elected to function as the domain master browser. This +domain browsing has nothing to do with MS security domain control. +Instead, the domain master browser serves the role of contacting each local +master browser (found by asking WINS or from LMHOSTS) and exchanging browse +list contents. This way every master browser will eventually obtain a complete +list of all machines that are on the network. Every 11-15 minutes an election +is held to determine which machine will be the master browser. By the nature of +the election criteria used, the machine with the highest uptime, or the +most senior protocol version, or other criteria, will win the election +as domain master browser.

Clients wishing to browse the network make use of this list, but also depend +on the availability of correct name resolution to the respective IP +address/addresses.

Any configuration that breaks name resolution and/or browsing intrinsics +will annoy users because they will have to put up with protracted +inability to use the network services.

Samba supports a feature that allows forced synchonisation +of browse lists across routed networks using the "remote +browse sync" parameter in the smb.conf file. This causes Samba +to contact the local master browser on a remote network and +to request browse list synchronisation. This effectively bridges +two networks that are separated by routers. The two remote +networks may use either broadcast based name resolution or WINS +based name resolution, but it should be noted that the "remote +browse sync" parameter provides browse list synchronisation - and +that is distinct from name to address resolution, in other +words, for cross subnet browsing to function correctly it is +essential that a name to address resolution mechanism be provided. +This mechanism could be via DNS, /etc/hosts, +and so on.

2.3. Use of the "Remote Announce" parameter

The "remote announce" parameter of smb.conf can be used to forcibly ensure @@ -198,8 +265,8 @@ CLASS="SECT1" >

2.3. Use of the "Remote Browse Sync" parameter2.4. Use of the "Remote Browse Sync" parameter

The "remote browse sync" parameter of smb.conf is used to announce to @@ -221,8 +288,8 @@ CLASS="SECT1" >

2.4. Use of WINS2.5. Use of WINS

Use of WINS (either Samba WINS _or_ MS Windows NT Server WINS) is highly @@ -284,8 +351,8 @@ CLASS="SECT1" >

2.5. Do NOT use more than one (1) protocol on MS Windows machines2.6. Do NOT use more than one (1) protocol on MS Windows machines

A very common cause of browsing problems results from installing more than @@ -327,8 +394,8 @@ CLASS="SECT1" >

2.6. Name Resolution Order2.7. Name Resolution Order

Resolution of NetBIOS names to IP addresses can take place using a number diff --git a/docs/htmldocs/bugreport.html b/docs/htmldocs/bugreport.html index ccac1c5779..0711f00f80 100644 --- a/docs/htmldocs/bugreport.html +++ b/docs/htmldocs/bugreport.html @@ -80,7 +80,7 @@ CLASS="SECT1" >

27.1. Introduction

27.2. General info

27.3. Debug levels

27.4. Internal errors

27.5. Attaching to a running process

27.6. Patches

26.1. Access Samba source code via CVS

26.1.1. Introduction

26.1.2. CVS Access to samba.org

26.1.2.1. Access via CVSweb

26.1.2.2. Access via cvs

26.2. Accessing the samba sources via rsync and ftp

26.3. Building the Binaries

if you find this version a disaster!

26.3.1. Compiling samba with Active Directory support

In order to compile samba with ADS support, you need to have installed + on your system: +

the MIT kerberos development libraries (either install from the sources or use a package). The heimdal libraries will not work.
the OpenLDAP development libraries.

+ +

If your kerberos libraries are in a non-standard location then + remember to add the configure option --with-krb5=DIR.

After you run configure make sure that include/config.h it generates contains lines like this:

#define HAVE_KRB5 1
+#define HAVE_LDAP 1
+		  

If it doesn't then configure did not find your krb5 libraries or + your ldap libraries. Look in config.log to figure out why and fix + it.

26.3.1.1. Installing the required packages for Debian

On Debian you need to install the following packages:

libkrb5-dev
krb5-user

+

26.3.1.2. Installing the required packages for RedHat

On RedHat this means you should have at least:

krb5-workstation (for kinit)
krb5-libs (for linking with)
krb5-devel (because you are compiling from source)

+

in addition to the standard development environment.

Note that these are not standard on a RedHat install, and you may need + to get them off CD2.

26.4. Starting the smbd and nmbd

26.4.1. Starting from inetd.conf

26.4.2. Alternative: starting it as a daemon

28.1. Introduction

28.2. Assumptions

28.3. Tests

28.3.1. Test 1

28.3.2. Test 2

28.3.3. Test 3

28.3.4. Test 4

28.3.5. Test 5

28.3.6. Test 6

28.3.7. Test 7

28.3.8. Test 8

28.3.9. Test 9

28.3.10. Test 10

28.3.11. Test 11

28.4. Still having troubles?

9.1. Joining an NT Domain with Samba 3.0

security = domain or - security = ads depending on if the PDC is - NT4 or running Active Directory respectivly.

Next change the root# net join -S DOMPDC +>net rpc join -S DOMPDC -UAdministrator%password

9.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 3.0 is able to act as a member server of a Windows -2000 domain operating in mixed or native mode. The steps above apply -to both NT4 and Windows 2000.

9.3. Why is this better than security = server?9.2. Why is this better than security = server?

Currently, domain security in Samba doesn't free you from @@ -341,13 +322,27 @@ CLASS="COMMAND" 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.

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

Optional configurationAdvanced Configuration
PrevNextChapter 19. Group mapping HOWTOChapter 12. Group mapping HOWTO

Starting with Samba 3.0 alpha 2, a new group mapping function is available. The @@ -185,7 +186,7 @@ WIDTH="33%" ALIGN="left" VALIGN="top" >PrevNextStackable VFS modulesUNIX Permission Bits and Windows NT Access Control ListsSamba performance issuesConfiguring PAM for distributed but centrally +managed authentication

PrevNextChapter 17. Improved browsing in sambaChapter 18. Improved browsing in samba

17.1. Overview of browsing18.1. Overview of browsing

SMB networking provides a mechanism by which clients can access a list @@ -109,8 +109,8 @@ CLASS="SECT1" >

17.2. Browsing support in samba18.2. Browsing support in samba

Samba facilitates browsing. The browsing is supported by nmbd @@ -152,8 +152,8 @@ CLASS="SECT1" >

17.3. Problem resolution18.3. Problem resolution

If something doesn't work then hopefully the log.nmb file will help @@ -199,8 +199,8 @@ CLASS="SECT1" >

17.4. Browsing across subnets18.4. Browsing across subnets

Since the release of Samba 1.9.17(alpha1) Samba has been @@ -230,8 +230,8 @@ CLASS="SECT2" >

17.4.1. How does cross subnet browsing work ?18.4.1. How does cross subnet browsing work ?

Cross subnet browsing is a complicated dance, containing multiple @@ -441,8 +441,8 @@ CLASS="SECT1" >

17.5. Setting up a WINS server18.5. Setting up a WINS server

Either a Samba machine or a Windows NT Server machine may be set up @@ -524,8 +524,8 @@ CLASS="SECT1" >

17.6. Setting up Browsing in a WORKGROUP18.6. Setting up Browsing in a WORKGROUP

To set up cross subnet browsing on a network containing machines @@ -556,10 +556,10 @@ options in the [global] section of the smb.conf file :

        domain master = yes
-        local master = yes
-        preferred master = yes
-        os level = 65
domain master = yes +local master = yes +preferred master = yes +os level = 65

The domain master browser may be the same machine as the WINS @@ -576,10 +576,10 @@ smb.conf file :

        domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
domain master = no +local master = yes +preferred master = yes +os level = 65

Do not do this for more than one Samba server on each subnet, @@ -598,10 +598,10 @@ options in the [global] section of the smb.conf file :

        domain master = no
-        local master = no
-        preferred master = no
-        os level = 0
domain master = no +local master = no +preferred master = no +os level = 0

17.7. Setting up Browsing in a DOMAIN18.7. Setting up Browsing in a DOMAIN

If you are adding Samba servers to a Windows NT Domain then @@ -628,10 +628,10 @@ file :

        domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
domain master = no +local master = yes +preferred master = yes +os level = 65

If you wish to have a Samba server fight the election with machines @@ -660,8 +660,8 @@ CLASS="SECT1" >

17.8. Forcing samba to be the master18.8. Forcing samba to be the master

Who becomes the "master browser" is determined by an election process @@ -708,8 +708,8 @@ CLASS="SECT1" >

17.9. Making samba the domain master18.9. Making samba the domain master

The domain master is responsible for collating the browse lists of @@ -781,8 +781,8 @@ CLASS="SECT1" >

17.10. Note about broadcast addresses18.10. Note about broadcast addresses

If your network uses a "0" based broadcast address (for example if it @@ -795,8 +795,8 @@ CLASS="SECT1" >

17.11. Multiple interfaces18.11. Multiple interfaces

Samba now supports machines with multiple network interfaces. If you @@ -820,7 +820,7 @@ WIDTH="33%" ALIGN="left" VALIGN="top" >PrevNextUnified Logons between Windows NT and UNIX using WinbindIntegrating MS Windows networks with SambaStackable VFS modulesHosting a Microsoft Distributed File System tree on Samba

PrevNextChapter 10. Integrating MS Windows networks with Samba

10.1. Agenda

Chapter 17. Integrating MS Windows networks with Samba

To identify the key functional mechanisms of MS Windows networking -to enable the deployment of Samba as a means of extending and/or -replacing MS Windows NT/2000 technology.

We will examine:

This section deals with NetBIOS over TCP/IP name to IP address resolution. If you +your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this +section does not apply to your installation. If your installation involves use of +NetBIOS over TCP/IP then this section may help you to resolve networking problems.

  1. Name resolution in a pure Unix/Linux TCP/IP - environment -

  2. Name resolution as used within MS Windows - networking -

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

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

  5. NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS + over Logical Link Control (LLC). On modern networks it is highly advised + to NOT run NetBEUI at all. Note also that there is NO such thing as + NetBEUI over TCP/IP - the existence of such a protocol is a complete + and utter mis-apprehension.

Configuration of Samba as:

Since the introduction of MS Windows 2000 it is possible to run MS Windows networking +without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS +name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over +TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be +used and UDP port 137 and TCP port 139 will not.

  1. A stand-alone server

  2. An MS Windows NT 3.x/4.0 security domain member -

  3. An alternative to an MS Windows NT 3.x/4.0 Domain Controller -

    When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then +the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet +Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).

When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that +disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires +Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR). +Use of DHCP with ADS is recommended as a further means of maintaining central control +over client workstation network configuration.

10.2. Name Resolution in a pure Unix/Linux world17.1. Name Resolution in a pure Unix/Linux world

The key configuration files covered in this section are:

10.2.1. 17.1.1. /etc/hosts

10.2.2. 17.1.2. /etc/resolv.conf

10.2.3. 17.1.3. /etc/host.conf

10.2.4. 17.1.4. /etc/nsswitch.conf

10.3. Name resolution as used within MS Windows networking17.2. Name resolution as used within MS Windows networking

MS Windows networking is predicated about the name each machine @@ -491,8 +499,8 @@ CLASS="SECT2" >

10.3.1. The NetBIOS Name Cache17.2.1. The NetBIOS Name Cache

All MS Windows machines employ an in memory buffer in which is @@ -518,8 +526,8 @@ CLASS="SECT2" >

10.3.2. The LMHOSTS file17.2.2. The LMHOSTS file

This file is usually located in MS Windows NT 4.0 or @@ -621,8 +629,8 @@ CLASS="SECT2" >

10.3.3. HOSTS file17.2.3. HOSTS file

This file is usually located in MS Windows NT 4.0 or 2000 in @@ -643,8 +651,8 @@ CLASS="SECT2" >

10.3.4. DNS Lookup17.2.4. DNS Lookup

This capability is configured in the TCP/IP setup area in the network @@ -663,8 +671,8 @@ CLASS="SECT2" >

10.3.5. WINS Lookup17.2.5. WINS Lookup

A WINS (Windows Internet Name Server) service is the equivaent of the @@ -699,416 +707,6 @@ CLASS="REPLACEABLE" of the WINS server.

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

As stated above, MS Windows machines register their NetBIOS names -(i.e.: the machine name for each service type in operation) on start -up. Also, as stated above, the exact method by which this name registration -takes place is determined by whether or not the MS Windows client/server -has been given a WINS server address, whether or not LMHOSTS lookup -is enabled, or if DNS for NetBIOS name resolution is enabled, etc.

In the case where there is no WINS server all name registrations as -well as name lookups are done by UDP broadcast. This isolates name -resolution to the local subnet, unless LMHOSTS is used to list all -names and IP addresses. In such situations Samba provides a means by -which the samba server name may be forcibly injected into the browse -list of a remote MS Windows network (using the "remote announce" parameter).

Where a WINS server is used, the MS Windows client will use UDP -unicast to register with the WINS server. Such packets can be routed -and thus WINS allows name resolution to function across routed networks.

During the startup process an election will take place to create a -local master browser if one does not already exist. On each NetBIOS network -one machine will be elected to function as the domain master browser. This -domain browsing has nothing to do with MS security domain control. -Instead, the domain master browser serves the role of contacting each local -master browser (found by asking WINS or from LMHOSTS) and exchanging browse -list contents. This way every master browser will eventually obtain a complete -list of all machines that are on the network. Every 11-15 minutes an election -is held to determine which machine will be the master browser. By the nature of -the election criteria used, the machine with the highest uptime, or the -most senior protocol version, or other criteria, will win the election -as domain master browser.

Clients wishing to browse the network make use of this list, but also depend -on the availability of correct name resolution to the respective IP -address/addresses.

Any configuration that breaks name resolution and/or browsing intrinsics -will annoy users because they will have to put up with protracted -inability to use the network services.

Samba supports a feature that allows forced synchonisation -of browse lists across routed networks using the "remote -browse sync" parameter in the smb.conf file. This causes Samba -to contact the local master browser on a remote network and -to request browse list synchronisation. This effectively bridges -two networks that are separated by routers. The two remote -networks may use either broadcast based name resolution or WINS -based name resolution, but it should be noted that the "remote -browse sync" parameter provides browse list synchronisation - and -that is distinct from name to address resolution, in other -words, for cross subnet browsing to function correctly it is -essential that a name to address resolution mechanism be provided. -This mechanism could be via DNS, /etc/hosts, -and so on.

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

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:

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 -password authentication. All versions of MS Windows that follow -these versions no longer support plain text passwords by default.

MS Windows clients have a habit of dropping network mappings that -have been idle for 10 minutes or longer. When the user attempts to -use the mapped drive connection that has been dropped, the client -re-establishes the connection using -a cached copy of the password.

When Microsoft changed the default password mode, they dropped support for -caching of the plain text password. This means that when the registry -parameter is changed to re-enable use of plain text passwords it appears to -work, but when a dropped mapping attempts to revalidate it will fail if -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.

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 = integer
-	username level = integer

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 -for support of encrypted passwords:

10.5.1. Use MS Windows NT as an authentication server

This method involves the additions of the following parameters -in the smb.conf file:

	encrypt passwords = Yes
-	security = server
-	password server = "NetBIOS_name_of_PDC"

There are two ways of identifying whether or not a username and -password pair was valid or not. One uses the reply information provided -as part of the authentication messaging process, the other uses -just and error code.

The down-side of this mode of configuration is the fact that -for security reasons Samba will send the password server a bogus -username and a bogus password and if the remote server fails to -reject the username and password pair then an alternative mode -of identification of validation is used. Where a site uses password -lock out after a certain number of failed authentication attempts -this will result in user lockouts.

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.

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

This method involves additon of the following paramters in the smb.conf file:

	encrypt passwords = Yes
-	security = domain
-	workgroup = "name of NT domain"
-	password server = *

The use of the "*" argument to "password server" will cause samba -to locate the domain controller in a way analogous to the way -this is done within MS Windows NT.

In order for this method to work the Samba server needs to join the -MS Windows NT security domain. This is done as follows:

  • On the MS Windows NT domain controller using - the Server Manager add a machine account for the Samba server. -

  • Next, on the Linux system execute: - smbpasswd -r PDC_NAME -j DOMAIN_NAME -

Use of this mode of authentication does require there to be -a standard Unix account for the user in order to assign -a uid once the account has been authenticated by the remote -Windows DC. This account can be blocked to prevent logons by -other than MS Windows clients by things such as setting an invalid -shell in the /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.

10.5.3. Configure Samba as an authentication server

This mode of authentication demands that there be on the -Unix/Linux system both a Unix style account as well as an -smbpasswd entry for the user. The Unix system account can be -locked if required as only the encrypted password will be -used for SMB client authentication.

This method involves addition of the following parameters to -the smb.conf file:

## 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

in order for this method to work a Unix system account needs -to be created for each user, as well as for each MS Windows NT/2000 -machine. The following structure is required.

10.5.3.1. Users

A user account that may provide a home directory should be -created. The following Linux system commands are typical of -the procedure for creating an account.

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

10.5.3.2. MS Windows NT Machine Accounts

These are required only when Samba is used as a domain -controller. Refer to the Samba-PDC-HOWTO for more details.

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

10.6. Conclusions

Samba provides a flexible means to operate as...

2.2. Use of the "Remote Announce" parameterHow browsing functions and how to deploy stable and +dependable browsing using Samba
2.3. Use of the "Remote Browse Sync" parameterUse of the "Remote Announce" parameter
2.4. Use of WINSUse of the "Remote Browse Sync" parameter
2.5. Do NOT use more than one (1) protocol on MS Windows machinesUse of WINS
2.6. Do NOT use more than one (1) protocol on MS Windows machines
2.7. Name Resolution Order
3.1. Introduction
3.2. Important Notes About Security
3.2.1. Advantages of SMB Encryption
3.2.2. Advantages of non-encrypted passwords
3.3. The smbpasswd Command
3.4. Plain text
3.5. TDB
3.6. LDAP
3.6.1. Introduction
3.6.2. Introduction
3.6.3. Supported LDAP Servers
3.6.4. Schema and Relationship to the RFC 2307 posixAccount
3.6.5. Configuring Samba with LDAP
3.6.6. Accounts and Groups management
3.6.7. Security and sambaAccount
3.6.8. LDAP specials attributes for sambaAccounts
3.6.9. Example LDIF Entries for a sambaAccount
3.7. MySQL
3.7.1. Building
3.7.2. Creating the database
3.7.3. Configuring
3.7.4. Using plaintext passwords or encrypted password
3.7.5. Getting non-column data from the table
3.8. Passdb XML plugin
3.8.1. Building
3.8.2. Usage
PrevNextChapter 13. Hosting a Microsoft Distributed File System tree on SambaChapter 19. Hosting a Microsoft Distributed File System tree on Samba

13.1. Instructions19.1. Instructions

The Distributed File System (or Dfs) provides a means of @@ -213,8 +212,8 @@ CLASS="SECT2" >

13.1.1. Notes19.1.1. Notes

PrevNextConfiguring PAM for distributed but centrally -managed authenticationImproved browsing in sambaPrinting SupportStackable VFS modules
Optional configurationAdvanced ConfigurationNext

III. Optional configuration

III. Advanced Configuration

Introduction

10. Integrating MS Windows networks with SambaSystem Policies
10.1. Agenda
10.2. Name Resolution in a pure Unix/Linux worldBasic System Policy Info
10.2.1. /etc/hosts
10.2.2. /etc/resolv.conf
10.2.3. /etc/host.conf
10.2.4. /etc/nsswitch.conf10.1.1. Creating Group Prolicy Files
10.3. Name resolution as used within MS Windows networking10.2. Roaming Profiles
10.3.1. The NetBIOS Name Cache
10.3.2. The LMHOSTS file10.2.1. Windows NT Configuration
10.3.3. HOSTS file10.2.2. Windows 9X Configuration
10.3.4. DNS Lookup10.2.3. Win9X and WinNT Configuration
10.3.5. WINS Lookup10.2.4. Windows 9X Profile Setup
10.4. How browsing functions and how to deploy stable and -dependable browsing using Samba10.2.5. Windows NT Workstation 4.0
10.5. MS Windows security options and how to configure -Samba for seemless integration10.2.6. Windows NT/200x Server
10.5.1. Use MS Windows NT as an authentication server10.2.7. Sharing Profiles between W9x/Me and NT4/200x/XP workstations
10.5.2. Make Samba a member of an MS Windows NT security domain10.2.8. Windows NT 4
10.5.3. Configure Samba as an authentication server10.2.9. Windows 2000/XP
10.6. Conclusions
11.1. Viewing and changing UNIX permissions using the NT security dialogs
11.2. How to view file security on a Samba share
11.3. Viewing file ownership
11.4. Viewing file or directory permissions
11.4.1. File Permissions
11.4.2. Directory Permissions
11.5. Modifying file or directory permissions
11.6. Interaction with the standard Samba create mask parameters
11.7. Interaction with the standard Samba file attribute mapping
12. Group mapping HOWTO
13. Configuring PAM for distributed but centrally managed authentication
12.1. 13.1. Samba and PAM
12.2. 13.2. Distributed Authentication
12.3. 13.3. PAM Configuration in smb.conf
13. Hosting a Microsoft Distributed File System tree on Samba
13.1. Instructions
13.1.1. Notes
14. Printing Support
14.1. Introduction
14.2. Configuration
14.2.1. Creating [print$]
14.2.2. Setting Drivers for Existing Printers
14.2.3. Support a large number of printers
14.2.4. Adding New Printers via the Windows NT APW
14.2.5. Samba and Printer Ports
14.3. The Imprints Toolset
14.3.1. What is Imprints?
14.3.2. Creating Printer Driver Packages
14.3.3. The Imprints server
14.3.4. The Installation Client
14.4. Diagnosis
14.4.1. Introduction
14.4.2. Debugging printer problems
14.4.3. What printers do I have?
14.4.4. Setting up printcap and print servers
14.4.5. Job sent, no output
14.4.6. Job sent, strange output
14.4.7. Raw PostScript printed
14.4.8. Advanced Printing
14.4.9. Real debugging
15.1. Introduction
15.2. CUPS - RAW Print Through Mode
15.3. The CUPS Filter Chains
15.4. CUPS Print Drivers and Devices
15.4.1. Further printing steps
15.5. Limiting the number of pages users can print
15.6. Advanced Postscript Printing from MS Windows
15.7. Auto-Deletion of CUPS spool files
16.1. Abstract
16.2. Introduction
16.3. What Winbind Provides
16.3.1. Target Uses
16.4. How Winbind Works
16.4.1. Microsoft Remote Procedure Calls
16.4.2. Microsoft Active Directory Services
16.4.3. Name Service Switch
16.4.4. Pluggable Authentication Modules
16.4.5. User and Group ID Allocation
16.4.6. Result Caching
16.5. Installation and Configuration
16.5.1. Introduction
16.5.2. Requirements
16.5.3. Testing Things Out
16.6. Limitations
16.7. Conclusion
17. Improved browsing in sambaIntegrating MS Windows networks with Samba
17.1. Overview of browsingName Resolution in a pure Unix/Linux world
17.2. Browsing support in samba17.1.1. /etc/hosts
17.3. Problem resolution17.1.2. /etc/resolv.conf
17.4. Browsing across subnets17.1.3. /etc/host.conf
17.4.1. How does cross subnet browsing work ?17.1.4. /etc/nsswitch.conf
17.5. Setting up a WINS server
17.6. Setting up Browsing in a WORKGROUP17.2. Name resolution as used within MS Windows networking
17.7. Setting up Browsing in a DOMAIN17.2.1. The NetBIOS Name Cache
17.8. Forcing samba to be the master17.2.2. The LMHOSTS file
17.9. Making samba the domain master17.2.3. HOSTS file
17.10. Note about broadcast addresses17.2.4. DNS Lookup
17.11. Multiple interfaces17.2.5. WINS Lookup
18. Stackable VFS modulesImproved browsing in samba
18.1. Introduction and configurationOverview of browsing
18.2. Included modules
18.2.1. audit
18.2.2. recycleBrowsing support in samba
18.2.3. netatalk18.3. Problem resolution
18.3. VFS modules available elsewhere18.4. Browsing across subnets
18.3.1. DatabaseFS
18.3.2. vscan18.4.1. How does cross subnet browsing work ?
19. Group mapping HOWTO
20. Samba performance issues
20.1. Comparisons18.5. Setting up a WINS server
20.2. Socket options18.6. Setting up Browsing in a WORKGROUP
20.3. Read size18.7. Setting up Browsing in a DOMAIN
20.4. Max xmit18.8. Forcing samba to be the master
20.5. Log level18.9. Making samba the domain master
20.6. Read raw18.10. Note about broadcast addresses
20.7. Write raw18.11. Multiple interfaces
20.8. Slow Clients19. Hosting a Microsoft Distributed File System tree on Samba
20.9. Slow Logins19.1. Instructions
20.10. Client tuning19.1.1. Notes
21. Creating Group Prolicy Files20. Stackable VFS modules
21.1. Windows '9x20.1. Introduction and configuration
21.2. Windows NT 420.2. Included modules
21.2.1. Side bar Notes
21.2.2. Mandatory profiles20.2.1. audit
21.2.3. moveuser.exe20.2.2. recycle
21.2.4. Get SID20.2.3. netatalk
21.3. Windows 2000/XP20.3. VFS modules available elsewhere
20.3.1. DatabaseFS
20.3.2. vscan
22. 21. Securing Samba
22.1. 21.1. Introduction
22.2. 21.2. Using host based protection
22.3. 21.3. Using interface protection
22.4. 21.4. Using a firewall
22.5. 21.5. Using a IPC$ share deny
22.6. 21.6. Upgrading Samba
23. 22. Unicode/Charsets
23.1. 22.1. What are charsets and unicode?
23.2. 22.2. Samba and charsets
NextIntegrating MS Windows networks with SambaSystem Policies

25.1. Macintosh clients?

25.2. OS2 Client

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

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

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

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

25.3. Windows for Workgroups

25.3.1. Use latest TCP/IP stack from Microsoft

25.3.2. Delete .pwl files after password change

25.3.3. Configure WfW password handling

25.3.4. Case handling of passwords

25.3.5. Use TCP/IP as default protocol

25.4. Windows '95/'98

25.5. Windows 2000 Service Pack 2

PrevNextChapter 12. Configuring PAM for distributed but centrally +>Chapter 13. Configuring PAM for distributed but centrally managed authentication

12.1. Samba and PAM13.1. Samba and PAM

A number of Unix systems (eg: Sun Solaris), as well as the @@ -119,6 +119,45 @@ or by editing individual files that are located in /etc/pam.d.

If the PAM authentication module (loadable link library file) is located in the + default location then it is not necessary to specify the path. In the case of + Linux, the default location is /lib/security. If the module + is located other than default then the path may be specified as: + +

	eg: "auth       required      /other_path/pam_strange_module.so"
+	
+

The following is an example

#%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
#%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

PAM allows use of replacable modules. Those available on a @@ -155,19 +194,19 @@ sample system include:

$ /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
$ /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

The following example for the login program replaces the use of @@ -230,13 +269,13 @@ source distribution.

#%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
#%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

The following is the PAM configuration file for a particular @@ -247,13 +286,13 @@ CLASS="FILENAME" >

#%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
#%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

In the following example the decision has been made to use the @@ -264,16 +303,36 @@ program.

#%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
#%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

Note: PAM allows stacking of authentication mechanisms. It is +>

PAM allows stacking of authentication mechanisms. It is also possible to pass information obtained within one 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 @@ -290,14 +349,18 @@ CLASS="FILENAME" 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.

12.2. Distributed Authentication13.2. Distributed Authentication

The astute administrator will realize from this that the @@ -308,16 +371,9 @@ CLASS="FILENAME" winbindd, and rsync (see -http://rsync.samba.org/) -will allow the establishment of a centrally managed, distributed +>, and a distributed +passdb backend, such as ldap, 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 @@ -329,8 +385,8 @@ CLASS="SECT1" >

12.3. PAM Configuration in smb.conf13.3. PAM Configuration in smb.conf

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

When Samba 2.2 is configure to enable PAM support (i.e. +>When Samba is configured to enable PAM support (i.e. --with-pamPrevNextUNIX Permission Bits and Windows NT Access Control ListsGroup mapping HOWTOHosting a Microsoft Distributed File System tree on SambaPrinting Support

3.1. Introduction

3.2. Important Notes About Security

3.2.1. Advantages of SMB Encryption

3.2.2. Advantages of non-encrypted passwords

3.3. The smbpasswd Command

3.4. Plain text

3.5. TDB

3.6. LDAP

3.6.1. Introduction

3.6.2. Introduction

3.6.3. Supported LDAP Servers

3.6.4. Schema and Relationship to the RFC 2307 posixAccount

3.6.5. Configuring Samba with LDAP

3.6.5.1. OpenLDAP configuration

3.6.5.2. Configuring Samba

3.6.6. Accounts and Groups management

3.6.7. Security and sambaAccount

3.6.8. LDAP specials attributes for sambaAccounts

3.6.9. Example LDIF Entries for a sambaAccount

3.7. MySQL

3.7.1. Building

3.7.2. Creating the database

3.7.3. Configuring

3.7.4. Using plaintext passwords or encrypted password

3.7.5. Getting non-column data from the table

3.8. Passdb XML plugin

3.8.1. Building

3.8.2. Usage

Prev

24.1. HPUX

24.2. SCO Unix

24.3. DNIX

24.4. RedHat Linux Rembrandt-II

24.5. AIX

2.2. Use of the "Remote Announce" parameterHow browsing functions and how to deploy stable and +dependable browsing using Samba
2.3. Use of the "Remote Browse Sync" parameterUse of the "Remote Announce" parameter
2.4. Use of WINSUse of the "Remote Browse Sync" parameter
2.5. Do NOT use more than one (1) protocol on MS Windows machinesUse of WINS
2.6. Do NOT use more than one (1) protocol on MS Windows machines
2.7. Name Resolution Order
3.1. Introduction
3.2. Important Notes About Security
3.3. The smbpasswd Command
3.4. Plain text
3.5. TDB
3.6. LDAP
3.7. MySQL
3.8. Passdb XML plugin
4.1. Stand Alone Server
4.2. Domain Member Server
4.3. Domain Controller
5. Samba as Stand-Alone server (User and Share security level)Samba as Stand-Alone Server
5.1. User and Share security level
6.
6.1. Prerequisite Reading
6.2. Background
6.3. Configuring the Samba Domain Controller
6.4. Creating Machine Trust Accounts and Joining Clients to the Domain
6.5. Common Problems and Errors
6.6. System Policies and Profiles
6.7. What other help can I get?
6.8. 6.7. Domain Control for Windows 9x/ME
6.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba
7. How to Act as a Backup Domain Controller in a Purely Samba Controlled DomainSamba Backup Domain Controller to Samba Domain Control
7.1. Prerequisite Reading
7.2. Background
7.3. What qualifies a Domain Controller on the network?
7.4. Can Samba be a Backup Domain Controller to an NT PDC?
7.5. How do I set up a Samba BDC?
8.1. Installing the required packages for DebianSetup your smb.conf
8.2. Installing the required packages for RedHatSetup your /etc/krb5.conf
8.3. Compile Samba
8.4. Setup your /etc/krb5.conf
8.5. Create the computer account
8.6. 8.4. Test your server setup
8.7. 8.5. Testing with smbclient
8.8. 8.6. Notes
9.1. Joining an NT Domain with Samba 3.0
9.2. Samba and Windows 2000 Domains
9.3. Why is this better than security = server?
III. Optional configurationAdvanced Configuration
10. Integrating MS Windows networks with SambaSystem Policies
10.1. AgendaBasic System Policy Info
10.2. Name Resolution in a pure Unix/Linux world
10.3. Name resolution as used within MS Windows networking
10.4. How browsing functions and how to deploy stable and -dependable browsing using Samba
10.5. MS Windows security options and how to configure -Samba for seemless integration
10.6. ConclusionsRoaming Profiles
11.1. Viewing and changing UNIX permissions using the NT security dialogs
11.2. How to view file security on a Samba share
11.3. Viewing file ownership
11.4. Viewing file or directory permissions
11.5. Modifying file or directory permissions
11.6. Interaction with the standard Samba create mask parameters
11.7. Interaction with the standard Samba file attribute mapping
12. Group mapping HOWTO
13. Configuring PAM for distributed but centrally managed authentication
12.1. 13.1. Samba and PAM
12.2. 13.2. Distributed Authentication
12.3. 13.3. PAM Configuration in smb.conf
13. Hosting a Microsoft Distributed File System tree on Samba
13.1. Instructions
14. Printing Support
14.1. Introduction
14.2. Configuration
14.3. The Imprints Toolset
14.4. Diagnosis
15.1. Introduction
15.2. CUPS - RAW Print Through Mode
15.3. The CUPS Filter Chains
15.4. CUPS Print Drivers and Devices
15.5. Limiting the number of pages users can print
15.6. Advanced Postscript Printing from MS Windows
15.7. Auto-Deletion of CUPS spool files
16.1. Abstract
16.2. Introduction
16.3. What Winbind Provides
16.4. How Winbind Works
16.5. Installation and Configuration
16.6. Limitations
16.7. Conclusion
17. Integrating MS Windows networks with Samba
17.1. Name Resolution in a pure Unix/Linux world
17.2. Name resolution as used within MS Windows networking
18. Improved browsing in samba
17.1. 18.1. Overview of browsing
17.2. 18.2. Browsing support in samba
17.3. 18.3. Problem resolution
17.4. 18.4. Browsing across subnets
17.5. 18.5. Setting up a WINS server
17.6. 18.6. Setting up Browsing in a WORKGROUP
17.7. 18.7. Setting up Browsing in a DOMAIN
17.8. 18.8. Forcing samba to be the master
17.9. 18.9. Making samba the domain master
17.10. 18.10. Note about broadcast addresses
17.11. 18.11. Multiple interfaces
18. Stackable VFS modules19. Hosting a Microsoft Distributed File System tree on Samba
18.1. Introduction and configuration
18.2. Included modules
18.3. VFS modules available elsewhere19.1. Instructions
19. Group mapping HOWTO
20. Samba performance issuesStackable VFS modules
20.1. ComparisonsIntroduction and configuration
20.2. Socket optionsIncluded modules
20.3. Read size
20.4. Max xmit
20.5. Log level
20.6. Read raw
20.7. Write raw
20.8. Slow Clients
20.9. Slow Logins
20.10. Client tuningVFS modules available elsewhere
21. Creating Group Prolicy Files
21.1. Windows '9x
21.2. Windows NT 4
21.3. Windows 2000/XP
22. Securing Samba
22.1. 21.1. Introduction
22.2. 21.2. Using host based protection
22.3. 21.3. Using interface protection
22.4. 21.4. Using a firewall
22.5. 21.5. Using a IPC$ share deny
22.6. 21.6. Upgrading Samba
23. 22. Unicode/Charsets
23.1. 22.1. What are charsets and unicode?
23.2. 22.2. Samba and charsets
23. Samba performance issues
23.1. Comparisons
23.2. Socket options
23.3. Read size
23.4. Max xmit
23.5. Log level
23.6. Read raw
23.7. Write raw
23.8. Slow Clients
23.9. Slow Logins
23.10. Client tuning
24. Portability
24.1. HPUX
24.2. SCO Unix
24.3. DNIX
24.4. RedHat Linux Rembrandt-II
24.5. AIX
25.1. Macintosh clients?
25.2. OS2 Client
25.3. Windows for Workgroups
25.4. Windows '95/'98
25.5. Windows 2000 Service Pack 2
26.1. Access Samba source code via CVS
26.2. Accessing the samba sources via rsync and ftp
26.3. Building the Binaries
26.4. Starting the smbd and nmbd
27.1. Introduction
27.2. General info
27.3. Debug levels
27.4. Internal errors
27.5. Attaching to a running process
27.6. Patches
28.1. Introduction
28.2. Assumptions
28.3. Tests
28.4. Still having troubles?

6.1. Prerequisite Reading

6.2. Background

  • domain logons for Windows NT 4.0 / 200x / XP Professional clients. +> Domain logons for Windows NT 4.0 / 200x / XP Professional clients.

  • placing Windows 9x / Me clients in user level security +> Placing Windows 9x / Me clients in user level security

  • retrieving a list of users and groups from a Samba PDC to +> Retrieving a list of users and groups from a Samba PDC to Windows 9x / Me / NT / 200x / XP Professional clients

  • roaming user profiles +> Roaming Profiles

  • Windows NT 4.0-style system policies +> Network/System Policies

Roaming Profiles and System/Network policies are advanced network administration topics +that are covered separately in this document.

The following functionalities are new to the Samba 3.0 release:

6.3. Configuring the Samba Domain Controller

6.4. Creating Machine Trust Accounts and Joining Clients to the Domain

6.4.1. Manual Creation of Machine Trust Accounts

6.4.2. "On-the-Fly" Creation of Machine Trust Accounts

6.4.3. Joining the Client to the Domain

6.5. Common Problems and Errors

I joined the domain successfully but after upgrading to a newer version of the Samba code I get the message, "The system - can not log you on (C000019B), Please try a gain or consult your + can not log you on (C000019B), Please try again or consult your system administrator" when attempting to logon.

This occurs when the domain SID stored in - private/WORKGROUP.SID is - changed. For example, you remove the file and smbd automatically - creates a new one. Or you are swapping back and forth between - versions 2.0.7, TNG and the HEAD branch code (not recommended). The - only way to correct the problem is to restore the original domain - SID or remove the domain client from the domain and rejoin. +> This occurs when the domain SID stored in the secrets.tdb database + is changed. The most common cause of a change in domain SID is when + the domain name and/or the server name (netbios name) is changed. + The only way to correct the problem is to restore the original domain + SID or remove the domain client from the domain and rejoin. The domain + SID may be reset using either the smbpasswd or rpcclient utilities.

  • 6.6. System Policies and Profiles

    Much of the information necessary to implement System Policies and -Roving User Profiles in a Samba domain is the same as that for -implementing these same items in a Windows NT 4.0 domain. -You should read the white paper Implementing -Profiles and Policies in Windows NT 4.0 available from Microsoft.

    Here are some additional details:

    • What about Windows NT Policy Editor? -

      To create or edit ntconfig.pol you must use - the NT Server Policy Editor, poledit.exe which - is included with NT Server but not NT Workstation. - There is a Policy Editor on a NTws - but it is not suitable for creating Domain Policies. - Further, although the Windows 95 - Policy Editor can be installed on an NT Workstation/Server, it will not - work with NT policies because the registry key that are set by the policy templates. - However, the files from the NT Server will run happily enough on an NTws. - You need poledit.exe, common.adm and winnt.adm. It is convenient - to put the two *.adm files in c:\winnt\inf which is where - the binary will look for them unless told otherwise. Note also that that - directory is 'hidden'. -

      The Windows NT policy editor is also included with the Service Pack 3 (and - later) for Windows NT 4.0. Extract the files using servicepackname /x, - i.e. that's Nt4sp6ai.exe /x for service pack 6a. The policy editor, - poledit.exe and the associated template files (*.adm) should - be extracted as well. It is also possible to downloaded the policy template - files for Office97 and get a copy of the policy editor. Another possible - location is with the Zero Administration Kit available for download from Microsoft. -

    • Can Win95 do Policies? -

      Install the group policy handler for Win9x to pick up group - policies. Look on the Win98 CD in \tools\reskit\netadmin\poledit. - Install group policies on a Win9x client by double-clicking - grouppol.inf. Log off and on again a couple of - times and see if Win98 picks up group policies. Unfortunately this needs - to be done on every Win9x machine that uses group policies.... -

      If group policies don't work one reports suggests getting the updated - (read: working) grouppol.dll for Windows 9x. The group list is grabbed - from /etc/group. -

    • How do I get 'User Manager' and 'Server Manager' -

      Since I don't need to buy an NT Server CD now, how do I get - the 'User Manager for Domains', the 'Server Manager'? -

      Microsoft distributes a version of these tools called nexus for - installation on Windows 95 systems. The tools set includes -

      • Server Manager

      • User Manager for Domains

      • Event Viewer

      Click here to download the archived file ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE -

      The Windows NT 4.0 version of the 'User Manager for - Domains' and 'Server Manager' are available from Microsoft via ftp - from ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE -

    6.7. What other help can I get?6.6. What other help can I get?

    There are many sources of information available in the form @@ -1684,62 +1527,27 @@ CLASS="SECT1" >

    6.8. Domain Control for Windows 9x/ME6.7. Domain Control for Windows 9x/ME

    The following section contains much of the original -DOMAIN.txt file previously included with Samba. Much of -the material is based on what went into the book Special -Edition, Using Samba, by Richard Sharpe.

    A domain and a workgroup are exactly the same thing in terms of network browsing. The difference is that a distributable authentication database is associated with a domain, for secure login access to a network. Also, different access rights can be granted to users if they -successfully authenticate against a domain logon server (NT server and -other systems based on NT server support this, as does at least Samba TNG now).

    The SMB client logging on to a domain has an expectation that every other server in the domain should accept the same authentication information. -Network browsing functionality of domains and workgroups is -identical and is explained in BROWSING.txt. It should be noted, that browsing -is totally orthogonal to logon support.

    Issues related to the single-logon network model are discussed in this section. Samba supports domain logons, network logon scripts, and user profiles for MS Windows for workgroups and MS Windows 9X/ME clients -which will be the focus of this section.

    When an SMB client in a domain wishes to logon it broadcast requests for a logon server. The first one to reply gets the job, and validates its @@ -1818,8 +1626,8 @@ CLASS="SECT2" >

    6.8.1. Configuration Instructions: Network Logons6.7.1. Configuration Instructions: Network Logons

    The main difference between a PDC and a Windows 9x logon @@ -1919,703 +1727,6 @@ for its domain.

    6.8.2. Configuration Instructions: Setting up Roaming User Profiles

    NOTE! Roaming profiles support is different -for Win9X and WinNT.

    Before discussing how to configure roaming profiles, it is useful to see how -Win9X and WinNT clients implement these features.

    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 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, -including a separate field for the location of the user's profiles. -This means that support for profiles is different for Win9X and WinNT.

    6.8.2.1. Windows NT Configuration

    To support WinNT clients, in the [global] section of smb.conf set the -following (for example):

    logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath

    The default for this option is \\%N\%U\profile, namely -\\sambaserver\username\profile. The \\N%\%U service is created -automatically by the [homes] service. -If you are using a samba server for the profiles, you _must_ make the -share specified in the logon path browseable.

    [lkcl 26aug96 - we have discovered a problem where Windows clients can -maintain a connection to the [homes] share in between logins. The -[homes] share must NOT therefore be used in a profile path.]

    6.8.2.2. Windows 9X Configuration

    To support Win9X clients, you must use the "logon home" parameter. Samba has -now been fixed so that "net use/home" now works as well, and it, too, relies -on the "logon home" parameter.

    By using the logon home parameter, you are restricted to putting Win9X -profiles in the user's home directory. But wait! There is a trick you -can use. If you set the following in the [global] section of your -smb.conf file:

    logon home = \\%L\%U\.profiles

    then your Win9X clients will dutifully put their clients in a subdirectory -of your home directory called .profiles (thus making them hidden).

    Not only that, but 'net use/home' will also work, because of a feature in -Win9X. It removes any directory stuff off the end of the home directory area -and only uses the server and share portion. That is, it looks like you -specified \\%L\%U for "logon home".

    6.8.2.3. Win9X and WinNT Configuration

    You can support profiles for both Win9X and WinNT clients by setting both the -"logon home" and "logon path" parameters. For example:

    logon home = \\%L\%U\.profiles
    -logon path = \\%L\profiles\%U

    I have not checked what 'net use /home' does on NT when "logon home" is -set as above.

    6.8.2.4. Windows 9X Profile Setup

    When a user first logs in on Windows 9X, the file user.DAT is created, -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 preserve case = yes" and -"case sensitive = no" in order to maintain capital letters in shortcuts -in any of the profile folders.

    The user.DAT file contains all the user's preferences. If you wish to -enforce a set of preferences, rename their user.DAT file to user.MAN, -and deny them write access to this file.

    1. On the Windows 95 machine, go to Control Panel | Passwords and - select the User Profiles tab. Select the required level of - roaming preferences. Press OK, but do _not_ allow the computer - to reboot. -

    2. On the Windows 95 machine, go to Control Panel | Network | - Client for Microsoft Networks | Preferences. Select 'Log on to - NT Domain'. Then, ensure that the Primary Logon is 'Client for - Microsoft Networks'. Press OK, and this time allow the computer - to reboot. -

    Under Windows 95, Profiles are downloaded from the Primary Logon. -If you have the Primary Logon as 'Client for Novell Networks', then -the profiles and logon script will be downloaded from your Novell -Server. If you have the Primary Logon as 'Windows Logon', then the -profiles will be loaded from the local machine - a bit against the -concept of roaming profiles, if you ask me.

    You will now find that the Microsoft Networks Login box contains -[user, password, domain] instead of just [user, password]. Type in -the samba server's domain name (or any other domain known to exist, -but bear in mind that the user will be authenticated against this -domain and profiles downloaded from it, if that domain logon server -supports it), user name and user's password.

    Once the user has been successfully validated, the Windows 95 machine -will inform you that 'The user has not logged on before' and asks you -if you wish to save the user's preferences? Select 'yes'.

    Once the Windows 95 client comes up with the desktop, you should be able -to examine the contents of the directory specified in the "logon path" -on the samba server and verify that the "Desktop", "Start Menu", -"Programs" and "Nethood" folders have been created.

    These folders will be cached locally on the client, and updated when -the user logs off (if you haven't made them read-only by then :-). -You will find that if the user creates further folders or short-cuts, -that the client will merge the profile contents downloaded with the -contents of the profile directory already on the local client, taking -the newest folders and short-cuts from each set.

    If you have made the folders / files read-only on the samba server, -then you will get errors from the w95 machine on logon and logout, as -it attempts to merge the local and the remote profile. Basically, if -you have any errors reported by the w95 machine, check the Unix file -permissions and ownership rights on the profile directory contents, -on the samba server.

    If you have problems creating user profiles, you can reset the user's -local desktop cache, as shown below. When this user then next logs in, -they will be told that they are logging in "for the first time".

    1. instead of logging in under the [user, password, domain] dialog, - press escape. -

    2. run the regedit.exe program, and look in: -

      HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList -

      you will find an entry, for each user, of ProfilePath. Note the - contents of this key (likely to be c:\windows\profiles\username), - then delete the key ProfilePath for the required user. -

      [Exit the registry editor]. -

    3. WARNING - before deleting the contents of the - directory listed in - the ProfilePath (this is likely to be c:\windows\profiles\username), - ask them if they have any important files stored on their desktop - or in their start menu. delete the contents of the directory - ProfilePath (making a backup if any of the files are needed). -

      This will have the effect of removing the local (read-only hidden - system file) user.DAT in their profile directory, as well as the - local "desktop", "nethood", "start menu" and "programs" folders. -

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

    5. log off the windows 95 client. -

    6. check the contents of the profile path (see "logon path" described - above), and delete the user.DAT or user.MAN file for the user, - making a backup if required. -

    If all else fails, increase samba's debug log levels to between 3 and 10, -and / or run a packet trace program such as tcpdump or netmon.exe, and -look for any error reports.

    If you have access to an NT server, then first set up roaming profiles -and / or netlogons on the NT server. Make a packet trace, or examine -the example packet traces provided with NT server, and see what the -differences are with the equivalent samba trace.

    6.8.2.5. Windows NT Workstation 4.0

    When a user first logs in to a Windows NT Workstation, the profile -NTuser.DAT is created. The profile location can be now specified -through the "logon path" parameter.

    [lkcl 10aug97 - i tried setting the path to -\\samba-server\homes\profile, and discovered that this fails because -a background process maintains the connection to the [homes] share -which does _not_ close down in between user logins. you have to -have \\samba-server\%L\profile, where user is the username created -from the [homes] share].

    There is a parameter that is now available for use with NT Profiles: -"logon drive". This should be set to "h:" or any other drive, and -should be used in conjunction with the new "logon home" parameter.

    The entry for the NT 4.0 profile is a _directory_ not a file. The NT -help on profiles mentions that a directory is also created with a .PDS -extension. The user, while logging in, must have write permission to -create the full profile path (and the folder with the .PDS extension) -[lkcl 10aug97 - i found that the creation of the .PDS directory failed, -and had to create these manually for each user, with a shell script. -also, i presume, but have not tested, that the full profile path must -be browseable just as it is for w95, due to the manner in which they -attempt to create the full profile path: test existence of each path -component; create path component].

    In the profile directory, NT creates more folders than 95. It creates -"Application Data" and others, as well as "Desktop", "Nethood", -"Start Menu" and "Programs". The profile itself is stored in a file -NTuser.DAT. Nothing appears to be stored in the .PDS directory, and -its purpose is currently unknown.

    You can use the System Control Panel to copy a local profile onto -a samba server (see NT Help on profiles: it is also capable of firing -up the correct location in the System Control Panel for you). The -NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN -turns a profile into a mandatory one.

    [lkcl 10aug97 - i notice that NT Workstation tells me that it is -downloading a profile from a slow link. whether this is actually the -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 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 -workstation to access the samba server using LAN manager encrypted -passwords, without the user intervention normally required by NT -workstation for clear-text passwords].

    [lkcl 25aug97 - more comments received about NT profiles: the case of -the profile _matters_. the file _must_ be called NTuser.DAT or, for -a mandatory profile, NTuser.MAN].

    6.8.2.6. Windows NT Server

    There is nothing to stop you specifying any path that you like for the -location of users' profiles. Therefore, you could specify that the -profile be stored on a samba server, or any other SMB server, as long as -that SMB server supports encrypted passwords.

    6.8.2.7. Sharing Profiles between W95 and NT Workstation 4.0

    Potentially outdated or incorrect material follows
     

    I think this is all bogus, but have not deleted it. (Richard Sharpe)

    The default logon path is \\%N\%U. NT Workstation will attempt to create -a directory "\\samba-server\username.PDS" if you specify the logon path -as "\\samba-server\username" with the NT User Manager. Therefore, you -will need to specify (for example) "\\samba-server\username\profile". -NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which -is more likely to succeed.

    If you then want to share the same Start Menu / Desktop with W95, you will -need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97 -this has its drawbacks: i created a shortcut to telnet.exe, which attempts -to run from the c:\winnt\system32 directory. this directory is obviously -unlikely to exist on a Win95-only host].

    If you have this set up correctly, you will find separate user.DAT and -NTuser.DAT files in the same profile directory.

    [lkcl 25aug97 - there are some issues to resolve with downloading of -NT profiles, probably to do with time/date stamps. i have found that -NTuser.DAT is never updated on the workstation after the first time that -it is copied to the local workstation profile directory. this is in -contrast to w95, where it _does_ transfer / update profiles correctly].

    6.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba

    Possibly Outdated Material
     

    This appendix was originally authored by John H Terpstra of - the Samba Team and is included here for posterity. -

    NOTE : -The term "Domain Controller" and those related to it refer to one specific -method of authentication that can underly an SMB domain. Domain Controllers -prior to Windows NT Server 3.1 were sold by various companies and based on -private extensions to the LAN Manager 2.1 protocol. Windows NT introduced -Microsoft-specific ways of distributing the user authentication database. -See DOMAIN.txt for examples of how Samba can participate in or create -SMB domains based on shared authentication database schemes other than the -Windows NT SAM.

    Windows NT Server can be installed as either a plain file and print server -(WORKGROUP workstation or server) or as a server that participates in Domain -Control (DOMAIN member, Primary Domain controller or Backup Domain controller). -The same is true for OS/2 Warp Server, Digital Pathworks and other similar -products, all of which can participate in Domain Control along with Windows NT.

    To many people these terms can be confusing, so let's try to clear the air.

    Every Windows NT system (workstation or server) has a registry database. -The registry contains entries that describe the initialization information -for all services (the equivalent of Unix Daemons) that run within the Windows -NT environment. The registry also contains entries that tell application -software where to find dynamically loadable libraries that they depend upon. -In fact, the registry contains entries that describes everything that anything -may need to know to interact with the rest of the system.

    The registry files can be located on any Windows NT machine by opening a -command prompt and typing:

    C:\WINNT\> dir %SystemRoot%\System32\config

    The environment variable %SystemRoot% value can be obtained by typing:

    C:\WINNT>echo %SystemRoot%

    The active parts of the registry that you may want to be familiar with are -the files called: default, system, software, sam and security.

    In a domain environment, Microsoft Windows NT domain controllers participate -in replication of the SAM and SECURITY files so that all controllers within -the domain have an exactly identical copy of each.

    The Microsoft Windows NT system is structured within a security model that -says that all applications and services must authenticate themselves before -they can obtain permission from the security manager to do what they set out -to do.

    The Windows NT User database also resides within the registry. This part of -the registry contains the user's security identifier, home directory, group -memberships, desktop profile, and so on.

    Every Windows NT system (workstation as well as server) will have its own -registry. Windows NT Servers that participate in Domain Security control -have a database that they share in common - thus they do NOT own an -independent full registry database of their own, as do Workstations and -plain Servers.

    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 (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 -smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and -/pub/samba/pwdump on your nearest Samba mirror for the utility. This -facility is useful but cannot be easily used to implement SAM replication -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. 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).

    The PDC and BDCs then participate in replication of the SAM database so that -each Domain Controlling participant will have an up to date SAM component -within its registry.

    Samba as Stand-Alone server (User and Share security level)Samba as Stand-Alone ServerHow to Act as a Backup Domain Controller in a Purely Samba Controlled DomainSamba Backup Domain Controller to Samba Domain Control
    PrevChapter 22. Securing SambaChapter 21. Securing Samba

    22.1. Introduction21.1. Introduction

    This note was attached to the Samba 2.2.8 release notes as it contained an @@ -93,8 +93,8 @@ CLASS="SECT1" >

    22.2. Using host based protection21.2. Using host based protection

    In many installations of Samba the greatest threat comes for outside @@ -125,8 +125,8 @@ CLASS="SECT1" >

    22.3. Using interface protection21.3. Using interface protection

    By default Samba will accept connections on any network interface that @@ -161,8 +161,8 @@ CLASS="SECT1" >

    22.4. Using a firewall21.4. Using a firewall

    Many people use a firewall to deny access to services that they don't @@ -191,8 +191,8 @@ CLASS="SECT1" >

    22.5. Using a IPC$ share deny21.5. Using a IPC$ share deny

    If the above methods are not suitable, then you could also place a @@ -230,8 +230,8 @@ CLASS="SECT1" >

    22.6. Upgrading Samba21.6. Upgrading Samba

    Please check regularly on http://www.samba.org/ for updates and @@ -256,7 +256,7 @@ WIDTH="33%" ALIGN="left" VALIGN="top" >PrevCreating Group Prolicy FilesStackable VFS modulesSamba as Stand-Alone server (User and Share security level)Samba as Stand-Alone ServerChapter 5. Samba as Stand-Alone server (User and Share security level)Chapter 5. Samba as Stand-Alone Server

    In this section the function and purpose of Samba's security +modes are described.

    5.1. User and Share security level

    A SMB server tells the client at startup what "security level" it is running. There are two options "share level" and "user level". Which @@ -85,6 +102,14 @@ strange, but it fits in with the client/server approach of SMB. In SMB everything is initiated and controlled by the client, and the server can only tell the client what is available and whether an action is allowed.

    5.1.1. User Level Security

    I'll describe user level security first, as its simpler. In user level security the client will send a "session setup" command directly after @@ -117,6 +142,15 @@ requests. When the server responds it gives the client a "uid" to use as an authentication tag for that username/password. The client can maintain multiple authentication contexts in this way (WinDD is an example of an application that does this)

    5.1.2. Share Level Security

    Ok, now for share level security. In share level security the client authenticates itself separately for each share. It will send a @@ -139,6 +173,15 @@ home directories) and any users listed in the "user =" smb.conf line. The password is then checked in turn against these "possible usernames". If a match is found then the client is authenticated as that user.

    5.1.3. Server Level Security

    Finally "server level" security. In server level security the samba server reports to the client that it is in user level security. The @@ -167,6 +210,254 @@ requests to another "user mode" server. This requires an additional parameter "password server =" that points to the real authentication server. That real authentication server can be another Samba server or can be a Windows NT server, the later natively capable of encrypted password support.

    5.1.3.1. Configuring Samba for Seemless Windows Network Integration

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

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

    • An MD4 hash of the UNICODE of the password + string. This is known as the NT 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. +

    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 password authentication. All +versions of MS Windows that follow these versions no longer support plain +text passwords by default.

    MS Windows clients have a habit of dropping network mappings that have been idle +for 10 minutes or longer. When the user attempts to use the mapped drive +connection that has been dropped, the client re-establishes the connection using +a cached copy of the password.

    When Microsoft changed the default password mode, support was dropped for caching +of the plain text password. This means that when the registry parameter is changed +to re-enable use of plain text passwords it appears to work, but when a dropped +service connection mapping attempts to revalidate it will fail if 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.

    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 = integer
    +	username level = integer

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

    However, passwords 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 +for support of encrypted passwords:

    5.1.3.2. Use MS Windows NT as an authentication server

    This method involves the additions of the following parameters in the smb.conf file:

    	encrypt passwords = Yes
    +	security = server
    +	password server = "NetBIOS_name_of_PDC"

    There are two ways of identifying whether or not a username and +password pair was valid or not. One uses the reply information provided +as part of the authentication messaging process, the other uses +just and error code.

    The down-side of this mode of configuration is the fact that +for security reasons Samba will send the password server a bogus +username and a bogus password and if the remote server fails to +reject the username and password pair then an alternative mode +of identification of validation is used. Where a site uses password +lock out after a certain number of failed authentication attempts +this will result in user lockouts.

    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.

    5.1.4. Domain Level Security

    When samba is operating in security = domain mode this means that +the Samba server has a domain security trust account (a machine account) and will cause +all authentication requests to be passed through to the domain controllers.

    5.1.4.1. Samba as a member of an MS Windows NT security domain

    This method involves additon of the following paramters in the smb.conf file:

    	encrypt passwords = Yes
    +	security = domain
    +	workgroup = "name of NT domain"
    +	password server = *

    The use of the "*" argument to "password server" will cause samba to locate the +domain controller in a way analogous to the way this is done within MS Windows NT. +This is the default behaviour.

    In order for this method to work the Samba server needs to join the +MS Windows NT security domain. This is done as follows:

    • On the MS Windows NT domain controller using + the Server Manager add a machine account for the Samba server. +

    • Next, on the Linux system execute: + smbpasswd -r PDC_NAME -j DOMAIN_NAME +

    Use of this mode of authentication does require there to be a standard Unix account +for the user in order to assign a uid once the account has been authenticated by +the remote Windows DC. This account can be blocked to prevent logons by other than +MS Windows clients by things such as setting an invalid shell in the +/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.

    5.1.5. ADS Level Security

    For information about the configuration option please refer to the entire section entitled +Samba as an ADS Domain Member.

  • 7. How to Act as a Backup Domain Controller in a Purely Samba Controlled DomainSamba Backup Domain Controller to Samba Domain Control
    7.1. Prerequisite Reading
    7.2. Background
    7.3. What qualifies a Domain Controller on the network?
    7.3.1. How does a Workstation find its domain controller?
    7.3.2. When is the PDC needed?
    7.4. Can Samba be a Backup Domain Controller to an NT PDC?
    7.5. How do I set up a Samba BDC?
    7.5.1. How do I replicate the smbpasswd file?
    7.5.2. Can I do this all with LDAP?
    8.1. Installing the required packages for DebianSetup your smb.conf
    8.2. Installing the required packages for RedHatSetup your /etc/krb5.conf
    8.3. Compile Samba
    8.4. Setup your /etc/krb5.conf
    8.5. Create the computer account
    8.5.1. 8.3.1. Possible errors
    8.6. 8.4. Test your server setup
    8.7. 8.5. Testing with smbclient
    8.8. 8.6. Notes
    9.1. Joining an NT Domain with Samba 3.0
    9.2. Samba and Windows 2000 Domains
    9.3. Why is this better than security = server?
    PrevNext

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

    Windows NT clients can 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 @@ -100,11 +98,11 @@ CLASS="SECT1" >

    11.2. How to view file security on a Samba share

    From an NT 4.0 client, single-click with the right +>From an NT4/2000/XP 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 +> and you will see three buttons,

    11.3. Viewing file ownership

    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 + to a Samba 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

    11.4. Viewing file or directory permissions

    11.4.1. File Permissions

    11.4.2. Directory Permissions

    11.5. Modifying file or directory permissions

    "Add" - button will not return a list of users in Samba 2.0.4 (it will give + button will not return a list of users in Samba (it will give an error message of "The remote procedure call failed @@ -500,13 +497,14 @@ CLASS="SECT1" >

    11.6. Interaction with the standard Samba create mask parameters

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

    There are four parameters + to control interaction with the standard Samba create mask parameters. + These are :

    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 +> parameter. To allow a user to modify all the + user/group/world permissions on a file, set this parameter to 0777.

    Next Samba checks the changed permissions for a file against @@ -602,8 +599,7 @@ CLASS="PARAMETER" >force create mode parameter to provide compatibility - with Samba 2.0.4 where the permission change facility was introduced. +> parameter. To allow a user to modify all the user/group/world permissions on a file with no restrictions set this parameter to 000.

    force directory mode parameter to provide - compatibility with Samba 2.0.4 where the permission change facility - was introduced.

    parameter.

    In this way Samba enforces the permission restrictions that an administrator can set on a Samba share, whilst still allowing users @@ -691,37 +685,13 @@ CLASS="PARAMETER" CLASS="PARAMETER" >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.

    11.7. Interaction with the standard Samba file attribute mapping

    PrevNextIntegrating MS Windows networks with SambaSystem PoliciesConfiguring PAM for distributed but centrally -managed authenticationGroup mapping HOWTO
    PrevNextChapter 18. Stackable VFS modulesChapter 20. Stackable VFS modules

    18.1. Introduction and configuration20.1. Introduction and configuration

    Since samba 3.0, samba supports stackable VFS(Virtual File System) modules. @@ -121,16 +121,16 @@ CLASS="SECT1" >

    18.2. Included modules20.2. Included modules

    18.2.1. audit20.2.1. audit

    A simple module to audit file access to the syslog @@ -167,8 +167,8 @@ CLASS="SECT2" >

    18.2.2. recycle20.2.2. recycle

    A recycle-bin like modules. When used any unlink call @@ -238,8 +238,8 @@ CLASS="SECT2" >

    18.2.3. netatalk20.2.3. netatalk

    A netatalk module, that will ease co-existence of samba and @@ -271,8 +271,8 @@ CLASS="SECT1" >

    18.3. VFS modules available elsewhere20.3. VFS modules available elsewhere

    This section contains a listing of various other VFS modules that @@ -287,8 +287,8 @@ CLASS="SECT2" >

    18.3.1. DatabaseFS20.3.1. DatabaseFS

    URL:

    18.3.2. vscan20.3.2. vscan

    URL: PrevNextImproved browsing in sambaHosting a Microsoft Distributed File System tree on SambaGroup mapping HOWTOSecuring Samba

    Next

    16.1. Abstract

    16.2. Introduction

    16.3. What Winbind Provides

    16.3.1. Target Uses

    16.4. How Winbind Works

    16.4.1. Microsoft Remote Procedure Calls

    16.4.2. Microsoft Active Directory Services

    16.4.3. Name Service Switch

    16.4.4. Pluggable Authentication Modules

    16.4.5. User and Group ID Allocation

    16.4.6. Result Caching

    16.5. Installation and Configuration

    16.5.1. Introduction

    16.5.2. Requirements

    16.5.3. Testing Things Out

    16.5.3.1. Configure and compile SAMBA

    16.5.3.2. Configure nsswitch.conf

    16.5.3.3. Configure smb.conf

    16.5.3.4. Join the SAMBA server to the PDC domain

    16.5.3.5. Start up the winbindd daemon and test it!

    16.5.3.6. Fix the init.d startup scripts