From bf11814a57dff757d5816791593c55c9bd15a9e5 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 2 Apr 2003 12:28:46 +0000 Subject: Renegerate docs after John's changes (This used to be commit 597b23e9fbbd4b5024d9d839151b9083efc02b5c) --- docs/htmldocs/Samba-HOWTO-Collection.html | 10208 ++++++++++++++-------------- 1 file changed, 4975 insertions(+), 5233 deletions(-) (limited to 'docs/htmldocs') diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html index ea080fbd79..c902d63bec 100644 --- a/docs/htmldocs/Samba-HOWTO-Collection.html +++ b/docs/htmldocs/Samba-HOWTO-Collection.html @@ -145,26 +145,32 @@ HREF="#AEN130" >
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. Setup your smb.conf
8.2. Setup your /etc/krb5.conf
8.3. Create the computer account
8.4. Test your server setup
8.5. Testing with smbclient
8.6. Notes
9.1. Joining an NT Domain with Samba 3.0
9.2. 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?
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
2.2. Use of the "Remote Announce" parameter2.2. How browsing functions and how to deploy stable and +dependable browsing using Samba

The "remote announce" parameter of smb.conf can be used to forcibly ensure -that all the NetBIOS names on a network get announced to a remote network. -The syntax of the "remote announce" parameter is: -

	remote announce = a.b.c.d [e.f.g.h] ...
-_or_ -
	remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
- -where: -

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 +that all the NetBIOS names on a network get announced to a remote network. +The syntax of the "remote announce" parameter is: +

	remote announce = a.b.c.d [e.f.g.h] ...
+_or_ +
	remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
+ +where: +

a.b.c.d and e.f.g.h

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 @@ -1921,8 +1972,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 @@ -1984,8 +2035,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 @@ -2027,8 +2078,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 @@ -2118,7 +2169,7 @@ CLASS="SECT1" >

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

Introduction

4.1. Stand Alone Server
4.2. Domain Member Server
4.3. Domain Controller
4.3.1. Domain Controller Types
5. Samba as Stand-Alone server (User and Share security level)Samba as Stand-Alone Server
5.1. User and Share security level
5.1.1. User Level Security
5.1.2. Share Level Security
5.1.3. Server Level Security
5.1.4. Domain Level Security
5.1.5. ADS Level Security
6. Samba as an NT4 or Win2k Primary Domain Controller
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.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
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.8.1. 6.7.1. Configuration Instructions: Network Logons
6.8.2. Configuration Instructions: Setting up Roaming User Profiles
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.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. Setup your smb.conf
8.2. Setup your /etc/krb5.conf
8.3. Create the computer account
8.3.1. Possible errors
8.4. Test your server setup
8.5. Testing with smbclient
8.6. Notes
9.1. Joining an NT Domain with Samba 3.0
9.2. Why is this better than security = server?

4.1. Stand Alone Server

No special action is needed other than to create user accounts. Stand-alone +servers do NOT provide network logon services, meaning that machines that +use this server do NOT perform a domain logon but instead make use only of +the MS Windows logon which is local to the MS Windows workstation/server.

Samba tends to blur the distinction a little in respect of what is a stand alone server. This is because the authentication database may be local or on a remote server, even if from the samba protocol perspective @@ -4025,7 +4104,7 @@ CLASS="SECT1" >

4.2. Domain Member Server

4.3. Domain Controller

4.3.1. Domain Controller Types

Chapter 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 @@ -4158,6 +4254,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 @@ -4190,6 +4294,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 @@ -4212,6 +4325,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 @@ -4240,104 +4362,379 @@ 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.

Chapter 6. Samba as an NT4 or Win2k Primary Domain Controller

6.1. Prerequisite Reading

5.1.3.1. Configuring Samba for Seemless Windows Network Integration

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

6.2. Background

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.

This article outlines the steps necessary for configuring Samba as a PDC. -It is necessary to have a working Samba server prior to implementing the -PDC functionality.

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

  • domain logons for Windows NT 4.0 / 200x / XP Professional clients. -

  • placing Windows 9x / Me clients in user level security -

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

  • roaming user profiles +>An MD4 hash of the UNICODE of the password + string. This is known as the NT hash.

  • Windows NT 4.0-style system policies +>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.

The following functionalities are new to the Samba 3.0 release:

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

    Windows NT 4 domain trusts -

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

    Adding users via the User Manager for Domains -

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 functionalities are NOT provided by Samba 3.0:

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

  • SAM replication with Windows NT 4.0 Domain Controllers - (i.e. a Samba PDC and a Windows NT BDC or vice versa) +>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.

Chapter 6. Samba as an NT4 or Win2k Primary Domain Controller

6.1. Prerequisite Reading

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

6.2. Background

This article outlines the steps necessary for configuring Samba as a PDC. +It is necessary to have a working Samba server prior to implementing the +PDC functionality.

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

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

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

  • Roaming Profiles +

  • 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:

  • Windows NT 4 domain trusts +

  • Adding users via the User Manager for Domains +

The following functionalities are NOT provided by Samba 3.0:

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

  • 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 @@ -5857,62 +6070,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 @@ -5991,8 +6169,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 @@ -6092,1443 +6270,746 @@ for its domain.

6.8.2. Configuration Instructions: Setting up Roaming User Profiles

Chapter 7. Samba Backup Domain Controller to Samba Domain Control

7.1. Prerequisite Reading

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

Before you continue reading in this chapter, please make sure +that you are comfortable with configuring a Samba PDC +as described in the Samba-PDC-HOWTO.

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

7.2. Background

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

What is a Domain Controller? It is a machine that is able to answer +logon requests from workstations in a Windows NT Domain. Whenever a +user logs into a Windows NT Workstation, the workstation connects to a +Domain Controller and asks him whether the username and password the +user typed in is correct. The Domain Controller replies with a lot of +information about the user, for example the place where the users +profile is stored, the users full name of the user. All this +information is stored in the NT user database, the so-called SAM.

There are two kinds of Domain Controller in a NT 4 compatible Domain: +A Primary Domain Controller (PDC) and one or more Backup Domain +Controllers (BDC). The PDC contains the master copy of the +SAM. Whenever the SAM has to change, for example when a user changes +his password, this change has to be done on the PDC. A Backup Domain +Controller is a machine that maintains a read-only copy of the +SAM. This way it is able to reply to logon requests and authenticate +users in case the PDC is not available. During this time no changes to +the SAM are possible. Whenever changes to the SAM are done on the PDC, +all BDC receive the changes from the PDC.

Since version 2.2 Samba officially supports domain logons for all +current Windows Clients, including Windows 2000 and XP. This text +assumes the domain to be named SAMBA. To be able to act as a PDC, some +parameters in the [global]-section of the smb.conf have to be set:

logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
workgroup = SAMBA +domain master = yes +domain logons = yes

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.

Several other things like a [homes] and a [netlogon] share also may be +set along with settings for the profile path, the users home drive and +others. This will not be covered in this document.

7.3. What qualifies a Domain Controller on the network?

Every machine that is a Domain Controller for the domain SAMBA has to +register the NetBIOS group name SAMBA#1c with the WINS server and/or +by broadcast on the local network. The PDC also registers the unique +NetBIOS name SAMBA#1b with the WINS server. The name type #1b is +normally reserved for the domain master browser, a role that has +nothing to do with anything related to authentication, but the +Microsoft Domain implementation requires the domain master browser to +be on the same machine as the PDC.

7.3.1. How does a Workstation find its domain controller?

[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.]

A NT workstation in the domain SAMBA that wants a local user to be +authenticated has to find the domain controller for SAMBA. It does +this by doing a NetBIOS name query for the group name SAMBA#1c. It +assumes that each of the machines it gets back from the queries is a +domain controller and can answer logon requests. To not open security +holes both the workstation and the selected (TODO: How is the DC +chosen) domain controller authenticate each other. After that the +workstation sends the user's credentials (his name and password) to +the domain controller, asking for approval.

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

7.3.2. When is the PDC needed?

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

Whenever a user wants to change his password, this has to be done on +the PDC. To find the PDC, the workstation does a NetBIOS name query +for SAMBA#1b, assuming this machine maintains the master copy of the +SAM. The workstation contacts the PDC, both mutually authenticate and +the password change is done.

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:

7.4. Can Samba be a Backup Domain Controller to an NT PDC?

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

With version 2.2, no. The native NT SAM replication protocols have +not yet been fully implemented. The Samba Team is working on +understanding and implementing the protocols, but this work has not +been finished for version 2.2.

With version 3.0, the work on both the replication protocols and a +suitable storage mechanism has progressed, and some form of NT4 BDC +support is expected soon.

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

Can I get the benefits of a BDC with Samba? Yes. The main reason for +implementing a BDC is availability. If the PDC is a Samba machine, +a second Samba machine can be set up to +service logon requests whenever the PDC is down.

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.

7.5. How do I set up a Samba BDC?

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.

Several things have to be done:

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

      The domain SID has to be the same on the PDC and the BDC. This used to +be stored in the file private/MACHINE.SID. This file is not created +anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is +stored in the file private/secrets.tdb. Simply copying the secrets.tdb +from the PDC to the BDC does not work, as the BDC would +generate a new SID for itself and override the domain SID with this +new BDC SID.

      To retrieve the domain SID from the PDC or an existing BDC and store it in the +secrets.tdb, execute 'net rpc getsid' on the BDC.

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

      The Unix user database has to be synchronized from the PDC to the +BDC. This means that both the /etc/passwd and /etc/group have to be +replicated from the PDC to the BDC. This can be done manually +whenever changes are made, or the PDC is set up as a NIS master +server and the BDC as a NIS slave server. To set up the BDC as a +mere NIS client would not be enough, as the BDC would not be able to +access its user database in case of a PDC failure.

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.

    The Samba password database in the file private/smbpasswd has to be +replicated from the PDC to the BDC. This is a bit tricky, see the +next section.

  • 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'.

    Any netlogon share has to be replicated from the PDC to the +BDC. This can be done manually whenever login scripts are changed, +or it can be done automatically together with the smbpasswd +synchronization.

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

    Finally, the BDC has to be found by the workstations. This can be done +by setting

    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.

    workgroup = samba
+domain master = no
+domain logons = yes

    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.

    in the [global]-section of the smb.conf of the BDC. This makes the BDC +only register the name SAMBA#1c with the WINS server. This is no +problem as the name SAMBA#1c is a NetBIOS group name that is meant to +be registered by more than one machine. The parameter 'domain master = +no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS +name is reserved for the Primary Domain Controller.

    7.5.1. How do I replicate the smbpasswd file?

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

    Replication of the smbpasswd file is sensitive. It has to be done +whenever changes to the SAM are made. Every user's password change is +done in the smbpasswd file and has to be replicated to the BDC. So +replicating the smbpasswd file very often is necessary.

    1. As the smbpasswd file contains plain text password equivalents, it +must not be sent unencrypted over the wire. The best way to set up +smbpasswd replication from the PDC to the BDC is to use the utility +rsync. rsync can use ssh as a transport. ssh itself can be set up to +accept *only* rsync transfer without requiring the user to type a +password.

    7.5.2. Can I do this all with LDAP?

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

  • The simple answer is YES. Samba's pdb_ldap code supports +binding to a replica LDAP server, and will also follow referrals and +rebind to the master if it ever needs to make a modification to the +database. (Normally BDCs are read only, so this will not occur +often).

    • Chapter 8. Samba as a ADS domain member

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

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

    8.1. Setup your smb.conf

    HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList -

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

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

      realm = YOUR.KERBEROS.REALM
+  security = ADS
+  encrypt passwords = yes

    [Exit the registry editor]. -

  • In case samba can't figure out your ads server using your realm name, use the +ads server option in smb.conf: +
      ads server = your.kerberos.server

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

    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.2. Setup your /etc/krb5.conf

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

  • The minimal configuration for krb5.conf is:

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

  • [realms]
+    YOUR.KERBEROS.REALM = {
+	kdc = your.kerberos.server
+    }

    log off the windows 95 client. -

  • Test your config by doing a "kinit USERNAME@REALM" and making sure that + your password is accepted by the Win2000 KDC.

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

    • NOTE: The realm must be uppercase.

    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.

    You also must ensure that you can do a reverse DNS lookup on the IP +address of your KDC. Also, the name that this reverse lookup maps to +must either be the netbios name of the KDC (ie. the hostname with no +domain attached) or it can alternatively be the netbios name +followed by the realm.

    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.

    The easiest way to ensure you get this right is to add a /etc/hosts +entry mapping the IP address of your KDC to its netbios name. If you +don't get this right then you will get a "local error" when you try +to join the realm.

    If all you want is kerberos support in smbclient then you can skip +straight to step 5 now. Step 3 is only needed if you want kerberos +support for smbd and winbindd.

    6.8.2.5. Windows NT Workstation 4.0

    8.3. Create the computer account

    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.

    As a user that has write permission on the Samba private directory +(usually root) run: +net ads join

    8.3.1. Possible errors

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

    "ADS support not compiled in"

    Samba must be reconfigured (remove config.cache) and recompiled (make clean all install) after the kerberos libs and headers are installed.

    [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

    8.4. Test your server setup

    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.

    On a Windows 2000 client try net use * \\server\share. You should +be logged in with kerberos without needing to know a password. If +this fails then run klist tickets. Did you get a ticket for the +server? Does it have an encoding type of DES-CBC-MD5 ?

    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.

    8.5. Testing with smbclient

    [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].

    On your Samba server try to login to a Win2000 server or your Samba +server using smbclient and kerberos. Use smbclient as usual, but +specify the -k option to choose kerberos authentication.

    6.9. DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba8.6. Notes

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

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

    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.

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

    Chapter 7. How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain

    Chapter 9. Samba as a NT4 or Win2k domain member

    7.1. Prerequisite Reading

    Before you continue reading in this chapter, please make sure -that you are comfortable with configuring a Samba PDC -as described in the Samba-PDC-HOWTO.

    7.2. Background9.1. Joining an NT Domain with Samba 3.0

    What is a Domain Controller? It is a machine that is able to answer -logon requests from workstations in a Windows NT Domain. Whenever a -user logs into a Windows NT Workstation, the workstation connects to a -Domain Controller and asks him whether the username and password the -user typed in is correct. The Domain Controller replies with a lot of -information about the user, for example the place where the users -profile is stored, the users full name of the user. All this -information is stored in the NT user database, the so-called SAM.

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

    There are two kinds of Domain Controller in a NT 4 compatible Domain: -A Primary Domain Controller (PDC) and one or more Backup Domain -Controllers (BDC). The PDC contains the master copy of the -SAM. Whenever the SAM has to change, for example when a user changes -his password, this change has to be done on the PDC. A Backup Domain -Controller is a machine that maintains a read-only copy of the -SAM. This way it is able to reply to logon requests and authenticate -users in case the PDC is not available. During this time no changes to -the SAM are possible. Whenever changes to the SAM are done on the PDC, -all BDC receive the changes from the PDC.

    Firstly, you must edit your smb.conf(5) + file to tell Samba it should now use domain security.

    Since version 2.2 Samba officially supports domain logons for all -current Windows Clients, including Windows 2000 and XP. This text -assumes the domain to be named SAMBA. To be able to act as a PDC, some -parameters in the [global]-section of the smb.conf have to be set:

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

    workgroup = SAMBA
-domain master = yes
-domain logons = yes
    security = domain

    Several other things like a [homes] and a [netlogon] share also may be -set along with settings for the profile path, the users home drive and -others. This will not be covered in this document.

    7.3. What qualifies a Domain Controller on the network?

    Every machine that is a Domain Controller for the domain SAMBA has to -register the NetBIOS group name SAMBA#1c with the WINS server and/or -by broadcast on the local network. The PDC also registers the unique -NetBIOS name SAMBA#1b with the WINS server. The name type #1b is -normally reserved for the domain master browser, a role that has -nothing to do with anything related to authentication, but the -Microsoft Domain implementation requires the domain master browser to -be on the same machine as the PDC.

    7.3.1. How does a Workstation find its domain controller?

    A NT workstation in the domain SAMBA that wants a local user to be -authenticated has to find the domain controller for SAMBA. It does -this by doing a NetBIOS name query for the group name SAMBA#1c. It -assumes that each of the machines it gets back from the queries is a -domain controller and can answer logon requests. To not open security -holes both the workstation and the selected (TODO: How is the DC -chosen) domain controller authenticate each other. After that the -workstation sends the user's credentials (his name and password) to -the domain controller, asking for approval.

    7.3.2. When is the PDC needed?

    Whenever a user wants to change his password, this has to be done on -the PDC. To find the PDC, the workstation does a NetBIOS name query -for SAMBA#1b, assuming this machine maintains the master copy of the -SAM. The workstation contacts the PDC, both mutually authenticate and -the password change is done.

    7.4. Can Samba be a Backup Domain Controller to an NT PDC?

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

    With version 2.2, no. The native NT SAM replication protocols have -not yet been fully implemented. The Samba Team is working on -understanding and implementing the protocols, but this work has not -been finished for version 2.2.

    workgroup = DOM

    With version 3.0, the work on both the replication protocols and a -suitable storage mechanism has progressed, and some form of NT4 BDC -support is expected soon.

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

    Can I get the benefits of a BDC with Samba? Yes. The main reason for -implementing a BDC is availability. If the PDC is a Samba machine, -a second Samba machine can be set up to -service logon requests whenever the PDC is down.

    7.5. How do I set up a Samba BDC?

    You must also have the parameter encrypt passwords set to yes + in order for your users to authenticate to the NT PDC.

    Several things have to be done:

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

    password server = DOMPDC DOMBDC1 DOMBDC2

    • The domain SID has to be the same on the PDC and the BDC. This used to -be stored in the file private/MACHINE.SID. This file is not created -anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is -stored in the file private/secrets.tdb. Simply copying the secrets.tdb -from the PDC to the BDC does not work, as the BDC would -generate a new SID for itself and override the domain SID with this -new BDC SID.

      To retrieve the domain SID from the PDC or an existing BDC and store it in the -secrets.tdb, execute 'net rpc getsid' on the BDC.

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

      The Unix user database has to be synchronized from the PDC to the -BDC. This means that both the /etc/passwd and /etc/group have to be -replicated from the PDC to the BDC. This can be done manually -whenever changes are made, or the PDC is set up as a NIS master -server and the BDC as a NIS slave server. To set up the BDC as a -mere NIS client would not be enough, as the BDC would not be able to -access its user database in case of a PDC failure.

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

      The Samba password database in the file private/smbpasswd has to be -replicated from the PDC to the BDC. This is a bit tricky, see the -next section.

    • password server = *

      Any netlogon share has to be replicated from the PDC to the -BDC. This can be done manually whenever login scripts are changed, -or it can be done automatically together with the smbpasswd -synchronization.

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

    Finally, the BDC has to be found by the workstations. This can be done -by setting

    In order to actually join the domain, you must run this + command:

    workgroup = samba
-domain master = no
-domain logons = yes
    root# net rpc join -S DOMPDC + -UAdministrator%password

    in the [global]-section of the smb.conf of the BDC. This makes the BDC -only register the name SAMBA#1c with the WINS server. This is no -problem as the name SAMBA#1c is a NetBIOS group name that is meant to -be registered by more than one machine. The parameter 'domain master = -no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS -name is reserved for the Primary Domain Controller.

    7.5.1. How do I replicate the smbpasswd file?

    Replication of the smbpasswd file is sensitive. It has to be done -whenever changes to the SAM are made. Every user's password change is -done in the smbpasswd file and has to be replicated to the BDC. So -replicating the smbpasswd file very often is necessary.

    As the smbpasswd file contains plain text password equivalents, it -must not be sent unencrypted over the wire. The best way to set up -smbpasswd replication from the PDC to the BDC is to use the utility -rsync. rsync can use ssh as a transport. ssh itself can be set up to -accept *only* rsync transfer without requiring the user to type a -password.

    7.5.2. Can I do this all with LDAP?

    as we are joining the domain DOM and the PDC for that domain + (the only machine that has write access to the domain SAM database) + is DOMPDC. The Administrator%password is + the login name and password for an account which has the necessary + privilege to add machines to the domain. If this is successful + you will see the message:

    The simple answer is YES. Samba's pdb_ldap code supports -binding to a replica LDAP server, and will also follow referrals and -rebind to the master if it ever needs to make a modification to the -database. (Normally BDCs are read only, so this will not occur -often).

    Chapter 8. Samba as a ADS domain member

    Joined domain DOM. + or Joined 'SERV1' to realm 'MYREALM' +

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

    8.1. Setup your smb.conf

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

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

    This process joins the server to thedomain + without having to create the machine trust account on the PDC + beforehand.

      realm = YOUR.KERBEROS.REALM
-  security = ADS
-  encrypt passwords = yes

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

    In case samba can't figure out your ads server using your realm name, use the -ads server option in smb.conf: -

      ads server = your.kerberos.server
    /usr/local/samba/private/secrets.tdb

    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.

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

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

    8.2. Setup your /etc/krb5.conf9.2. Why is this better than security = server?

    The minimal configuration for krb5.conf is:

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

    [realms]
-    YOUR.KERBEROS.REALM = {
-	kdc = your.kerberos.server
-    }

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

    Test your config by doing a "kinit USERNAME@REALM" and making sure that - your password is accepted by the Win2000 KDC.

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

    NOTE: The realm must be uppercase.

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

    You also must ensure that you can do a reverse DNS lookup on the IP -address of your KDC. Also, the name that this reverse lookup maps to -must either be the netbios name of the KDC (ie. the hostname with no -domain attached) or it can alternatively be the netbios name -followed by the realm.

    And finally, acting in the same manner as an NT server + authenticating to a PDC means that as part of the authentication + reply, the Samba server gets the user identification information such + as the user SID, the list of NT groups the user belongs to, etc.

    The easiest way to ensure you get this right is to add a /etc/hosts -entry mapping the IP address of your KDC to its netbios name. If you -don't get this right then you will get a "local error" when you try -to join the realm.

    If all you want is kerberos support in smbclient then you can skip -straight to step 5 now. Step 3 is only needed if you want kerberos -support for smbd and winbindd.

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

    8.3. Create the computer account

    As a user that has write permission on the Samba private directory -(usually root) run: -net ads join

    III. Advanced Configuration

    8.3.1. Possible errors

    "ADS support not compiled in"

    Samba must be reconfigured (remove config.cache) and recompiled (make clean all install) after the kerberos libs and headers are installed.

    8.4. Test your server setup

    On a Windows 2000 client try net use * \\server\share. You should -be logged in with kerberos without needing to know a password. If -this fails then run klist tickets. Did you get a ticket for the -server? Does it have an encoding type of DES-CBC-MD5 ?

    8.5. Testing with smbclient

    On your Samba server try to login to a Win2000 server or your Samba -server using smbclient and kerberos. Use smbclient as usual, but -specify the -k option to choose kerberos authentication.

    8.6. Notes

    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?

    Chapter 9. Samba as a NT4 or Win2k domain member

    9.1. Joining an NT Domain with Samba 3.0

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

    Firstly, you must edit your smb.conf(5) - file to tell Samba it should now use domain security.

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

    security = domain

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

    workgroup = DOM

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

    You must also have the parameter encrypt passwords set to yes - in order for your users to authenticate to the NT PDC.

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

    password server = DOMPDC DOMBDC1 DOMBDC2

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

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

    password server = *

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

    In order to actually join the domain, you must run this - command:

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

    as we are joining the domain DOM and the PDC for that domain - (the only machine that has write access to the domain SAM database) - is DOMPDC. The Administrator%password is - the login name and password for an account which has the necessary - privilege to add machines to the domain. If this is successful - you will see the message:

    Joined domain DOM. - or Joined 'SERV1' to realm 'MYREALM' -

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

    This process joins the server to thedomain - without having to create the machine trust account on the PDC - beforehand.

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

    /usr/local/samba/private/secrets.tdb

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

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

    9.2. Why is this better than security = server?

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

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

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

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

    And finally, acting in the same manner as an NT server - authenticating to a PDC means that as part of the authentication - reply, the Samba server gets the user identification information such - as the user SID, the list of NT groups the user belongs to, etc.

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

    III. Optional 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

    Chapter 10. Integrating MS Windows networks with Samba

    Chapter 10. System Policies

    10.1. Agenda10.1. Basic System Policy Info

    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.

    Much of the information necessary to implement System Policies and +Roaming 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.

    We will examine:

    Here are some additional details:

      • Name resolution in a pure Unix/Linux TCP/IP - environment +> 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'.

      • Name resolution as used within MS Windows - networking +> 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.

      • How browsing functions and how to deploy stable - and dependable browsing using Samba +> 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.

      • MS Windows security options and how to - configure Samba for seemless integration +> How do I get 'User Manager' and 'Server Manager'

      • Configuration of Samba as:

        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 +

          • A stand-alone server

            Server Manager

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

            User Manager for Domains

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

            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 +

    10.1.1. Creating Group Prolicy Files

    10.1.1.1. Windows '9x

    You need the Win98 Group Policy Editor to +set Group Profiles up under Windows '9x. It can be found on the Original +full product Win98 installation CD under +tools/reskit/netadmin/poledit. You install this +using the Add/Remove Programs facility and then click on the 'Have Disk' +tab.

    Use the Group Policy Editor to create a policy file that specifies the +location of user profiles and/or the My Documents etc. +stuff. You then save these settings in a file called +Config.POL that needs to be placed in +the root of the [NETLOGON] share. If your Win98 is configured to log onto +the Samba Domain, it will automatically read this file and update the +Win9x/Me registry of the machine that is logging on.

    All of this is covered in the Win98 Resource Kit documentation.

    If you do not do it this way, then every so often Win9x/Me will check the +integrity of the registry and will restore it's settings from the back-up +copy of the registry it stores on each Win9x/Me machine. Hence, you will +occasionally notice things changing back to the original settings.

    10.2. Name Resolution in a pure Unix/Linux world10.2. Roaming Profiles

    The key configuration files covered in this section are:

    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.

    10.2.1. Windows NT Configuration

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

      /etc/hosts

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

    • /etc/resolv.conf

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

      /etc/host.conf

    • /etc/nsswitch.conf

      MS Windows NT/2K clients at times do not disconnect a connection to a server +between logons. It is recommended to NOT use the homes +meta-service name as part of the profile share path.

    10.2.1. /etc/hosts10.2.2. Windows 9X Configuration

    Contains a static list of IP Addresses and names. -eg:

    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:

    	127.0.0.1	localhost localhost.localdomain
-	192.168.1.1	bigbox.caldera.com	bigbox	alias4box
    logon home = \\%L\%U\.profiles

    The purpose of /etc/hosts is to provide a -name resolution mechanism so that uses do not need to remember -IP addresses.

    Network packets that are sent over the physical network transport -layer communicate not via IP addresses but rather using the Media -Access Control address, or MAC address. IP Addresses are currently -32 bits in length and are typically presented as four (4) decimal -numbers that are separated by a dot (or period). eg: 168.192.1.1

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

    MAC Addresses use 48 bits (or 6 bytes) and are typically represented -as two digit hexadecimal numbers separated by colons. eg: -40:8e:0a:12:34:56

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

    10.2.3. Win9X and WinNT Configuration

    Every network interfrace must have an MAC address. Associated with -a MAC address there may be one or more IP addresses. There is NO -relationship between an IP address and a MAC address, all such assignments -are arbitary or discretionary in nature. At the most basic level all -network communications takes place using MAC addressing. Since MAC -addresses must be globally unique, and generally remains fixed for -any particular interface, the assignment of an IP address makes sense -from a network management perspective. More than one IP address can -be assigned per MAC address. One address must be the primary IP address, -this is the address that will be returned in the ARP reply.

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

    When a user or a process wants to communicate with another machine -the protocol implementation ensures that the "machine name" or "host -name" is resolved to an IP address in a manner that is controlled -by the TCP/IP configuration control files. The file -/etc/hosts is one such file.

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

    When the IP address of the destination interface has been -determined a protocol called ARP/RARP is used to identify -the MAC address of the target interface. ARP stands for Address -Resolution Protocol, and is a broadcast oriented method that -uses UDP (User Datagram Protocol) to send a request to all -interfaces on the local network segment using the all 1's MAC -address. Network interfaces are programmed to respond to two -MAC addresses only; their own unique address and the address -ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will -contain the MAC address and the primary IP address for each -interface.

    The /etc/hosts file is foundational to all -Unix/Linux TCP/IP installations and as a minumum will contain -the localhost and local network interface IP addresses and the -primary names by which they are known within the local machine. -This file helps to prime the pump so that a basic level of name -resolution can exist before any other method of name resolution -becomes available.

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

    10.2.2. /etc/resolv.conf10.2.4. Windows 9X Profile Setup

    This file tells the name resolution libraries:

    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. The name of the domain to which the machine - belongs +> 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. The name(s) of any domains that should be - automatically searched when trying to resolve unqualified - host names to their IP address +> 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.

      The name or IP address of available Domain - Name Servers that may be asked to perform name to address - translation lookups -

    10.2.3. /etc/host.conf

    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.

    /etc/host.conf is the primary means by -which the setting in /etc/resolv.conf may be affected. It is a -critical configuration file. This file controls the order by -which name resolution may procede. The typical structure is:

    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.

    	order hosts,bind
-	multi on

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

    then both addresses should be returned. Please refer to the -man page for host.conf for further details.

    10.2.4. /etc/nsswitch.conf

    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.

    This file controls the actual name resolution targets. The -file typically has resolver object specifications as follows:

    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.

    	# /etc/nsswitch.conf
-	#
-	# Name Service Switch configuration file.
-	#
-
-	passwd:		compat
-	# Alternative entries for password authentication are:
-	# passwd:	compat files nis ldap winbind
-	shadow:		compat
-	group:		compat
-
-	hosts:		files nis dns
-	# Alternative entries for host name resolution are:
-	# hosts:	files dns nis nis+ hesoid db compat ldap wins
-	networks:	nis files dns
-
-	ethers:		nis files
-	protocols:	nis files
-	rpc:		nis files
-	services:	nis files

    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.

    Of course, each of these mechanisms requires that the appropriate -facilities and/or services are correctly configured.

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

    It should be noted that unless a network request/message must be -sent, TCP/IP networks are silent. All TCP/IP communications assumes a -principal of speaking only when necessary.

    1. Starting with version 2.2.0 samba has Linux support for extensions to -the name service switch infrastructure so that linux clients will -be able to obtain resolution of MS Windows NetBIOS names to IP -Addresses. To gain this functionality Samba needs to be compiled -with appropriate arguments to the make command (ie: make -nsswitch/libnss_wins.so). The resulting library should -then be installed in the /lib directory and -the "wins" parameter needs to be added to the "hosts:" line in -the /etc/nsswitch.conf file. At this point it -will be possible to ping any MS Windows machine by it's NetBIOS -machine name, so long as that machine is within the workgroup to -which both the samba machine and the MS Windows machine belong.

    10.3. Name resolution as used within MS Windows networking

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

  • MS Windows networking is predicated about the name each machine -is given. This name is known variously (and inconsistently) as -the "computer name", "machine name", "networking name", "netbios name", -"SMB name". All terms mean the same thing with the exception of -"netbios name" which can apply also to the name of the workgroup or the -domain name. The terms "workgroup" and "domain" are really just a -simply name with which the machine is associated. All NetBIOS names -are exactly 16 characters in length. The 16th character is reserved. -It is used to store a one byte value that indicates service level -information for the NetBIOS name that is registered. A NetBIOS machine -name is therefore registered for each service type that is provided by -the client/server.

    run the regedit.exe program, and look in: +

    The following are typical NetBIOS name/service type registrations:

    HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList + 

    	Unique NetBIOS Names:
-		MACHINENAME<00>	= Server Service is running on MACHINENAME
-		MACHINENAME<03> = Generic Machine Name (NetBIOS name)
-		MACHINENAME<20> = LanMan Server service is running on MACHINENAME
-		WORKGROUP<1b> = Domain Master Browser
-
-	Group Names:
-		WORKGROUP<03> = Generic Name registered by all members of WORKGROUP
-		WORKGROUP<1c> = Domain Controllers / Netlogon Servers
-		WORKGROUP<1d> = Local Master Browsers
-		WORKGROUP<1e> = Internet Name Resolvers

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

    It should be noted that all NetBIOS machines register their own -names as per the above. This is in vast contrast to TCP/IP -installations where traditionally the system administrator will -determine in the /etc/hosts or in the DNS database what names -are associated with each IP address.

    [Exit the registry editor]. +

  • One further point of clarification should be noted, the /etc/hosts -file and the DNS records do not provide the NetBIOS name type information -that MS Windows clients depend on to locate the type of service that may -be needed. An example of this is what happens when an MS Windows client -wants to locate a domain logon server. It find this service and the IP -address of a server that provides it by performing a lookup (via a -NetBIOS broadcast) for enumeration of all machines that have -registered the name type *<1c>. A logon request is then sent to each -IP address that is returned in the enumerated list of IP addresses. Which -ever machine first replies then ends up providing the logon services.

    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). +

    The name "workgroup" or "domain" really can be confusing since these -have the added significance of indicating what is the security -architecture of the MS Windows network. The term "workgroup" indicates -that the primary nature of the network environment is that of a -peer-to-peer design. In a WORKGROUP all machines are responsible for -their own security, and generally such security is limited to use of -just a password (known as SHARE MODE security). In most situations -with peer-to-peer networking the users who control their own machines -will simply opt to have no security at all. It is possible to have -USER MODE security in a WORKGROUP environment, thus requiring use -of a user name and a matching password.

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

  • MS Windows networking is thus predetermined to use machine names -for all local and remote machine message passing. The protocol used is -called Server Message Block (SMB) and this is implemented using -the NetBIOS protocol (Network Basic Input Output System). NetBIOS can -be encapsulated using LLC (Logical Link Control) protocol - in which case -the resulting protocol is called NetBEUI (Network Basic Extended User -Interface). NetBIOS can also be run over IPX (Internetworking Packet -Exchange) protocol as used by Novell NetWare, and it can be run -over TCP/IP protocols - in which case the resulting protocol is called -NBT or NetBT, the NetBIOS over TCP/IP.

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

  • MS Windows machines use a complex array of name resolution mechanisms. -Since we are primarily concerned with TCP/IP this demonstration is -limited to this area.

    10.3.1. The NetBIOS Name Cache

    log off the windows 95 client. +

  • All MS Windows machines employ an in memory buffer in which is -stored the NetBIOS names and IP addresses for all external -machines that that machine has communicated with over the -past 10-15 minutes. It is more efficient to obtain an IP address -for a machine from the local cache than it is to go through all the -configured name resolution mechanisms.

    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 a machine whose name is in the local name cache has been shut -down before the name had been expired and flushed from the cache, then -an attempt to exchange a message with that machine will be subject -to time-out delays. i.e.: Its name is in the cache, so a name resolution -lookup will succeed, but the machine can not respond. This can be -frustrating for users - but it is a characteristic of the protocol.

    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.

    The MS Windows utility that allows examination of the NetBIOS -name cache is called "nbtstat". The Samba equivalent of this -is called "nmblookup".

    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.

    10.3.2. The LMHOSTS file10.2.5. Windows NT Workstation 4.0

    This file is usually located in MS Windows NT 4.0 or -2000 in C:\WINNT\SYSTEM32\DRIVERS\ETC and contains -the IP Address and the machine name in matched pairs. The -LMHOSTS file performs NetBIOS name -to IP address mapping oriented.

    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.

    It typically looks like:

    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.

    	# Copyright (c) 1998 Microsoft Corp.
-	#
-	# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
-	# over TCP/IP) stack for Windows98
-	#
-	# This file contains the mappings of IP addresses to NT computernames
-	# (NetBIOS) names.  Each entry should be kept on an individual line.
-	# The IP address should be placed in the first column followed by the
-	# corresponding computername. The address and the comptername
-	# should be separated by at least one space or tab. The "#" character
-	# is generally used to denote the start of a comment (see the exceptions
-	# below).
-	#
-	# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
-	# files and offers the following extensions:
-	#
-	#      #PRE
-	#      #DOM:<domain>
-	#      #INCLUDE <filename>
-	#      #BEGIN_ALTERNATE
-	#      #END_ALTERNATE
-	#      \0xnn (non-printing character support)
-	#
-	# Following any entry in the file with the characters "#PRE" will cause
-	# the entry to be preloaded into the name cache. By default, entries are
-	# not preloaded, but are parsed only after dynamic name resolution fails.
-	#
-	# Following an entry with the "#DOM:<domain>" tag will associate the
-	# entry with the domain specified by <domain>. This affects how the
-	# browser and logon services behave in TCP/IP environments. To preload
-	# the host name associated with #DOM entry, it is necessary to also add a
-	# #PRE to the line. The <domain> is always preloaded although it will not
-	# be shown when the name cache is viewed.
-	#
-	# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
-	# software to seek the specified <filename> and parse it as if it were
-	# local. <filename> is generally a UNC-based name, allowing a
-	# centralized lmhosts file to be maintained on a server.
-	# It is ALWAYS necessary to provide a mapping for the IP address of the
-	# server prior to the #INCLUDE. This mapping must use the #PRE directive.
-	# In addtion the share "public" in the example below must be in the
-	# LanManServer list of "NullSessionShares" in order for client machines to
-	# be able to read the lmhosts file successfully. This key is under
-	# \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
-	# in the registry. Simply add "public" to the list found there.
-	#
-	# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
-	# statements to be grouped together. Any single successful include
-	# will cause the group to succeed.
-	#
-	# Finally, non-printing characters can be embedded in mappings by
-	# first surrounding the NetBIOS name in quotations, then using the
-	# \0xnn notation to specify a hex value for a non-printing character.
-	#
-	# The following example illustrates all of these extensions:
-	#
-	# 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
-	# 102.54.94.102    "appname  \0x14"                    #special app server
-	# 102.54.94.123    popular            #PRE             #source server
-	# 102.54.94.117    localsrv           #PRE             #needed for the include
-	#
-	# #BEGIN_ALTERNATE
-	# #INCLUDE \\localsrv\public\lmhosts
-	# #INCLUDE \\rhino\public\lmhosts
-	# #END_ALTERNATE
-	#
-	# In the above example, the "appname" server contains a special
-	# character in its name, the "popular" and "localsrv" server names are
-	# preloaded, and the "rhino" server name is specified so it can be used
-	# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
-	# system is unavailable.
-	#
-	# Note that the whole file is parsed including comments on each lookup,
-	# so keeping the number of comments to a minimum will improve performance.
-	# Therefore it is not advisable to simply add lmhosts file entries onto the
-	# end of this file.

    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 +for those situations where it might be created.)

    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.

    The case of the profile is significant. The file must be called +NTuser.DAT or, for a mandatory profile, NTuser.MAN.

    10.3.3. HOSTS file10.2.6. Windows NT/200x Server

    This file is usually located in MS Windows NT 4.0 or 2000 in -C:\WINNT\SYSTEM32\DRIVERS\ETC and contains -the IP Address and the IP hostname in matched pairs. It can be -used by the name resolution infrastructure in MS Windows, depending -on how the TCP/IP environment is configured. This file is in -every way the equivalent of the Unix/Linux /etc/hosts file.

    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.

    10.3.4. DNS Lookup10.2.7. Sharing Profiles between W9x/Me and NT4/200x/XP workstations

    This capability is configured in the TCP/IP setup area in the network -configuration facility. If enabled an elaborate name resolution sequence -is followed the precise nature of which isdependant on what the NetBIOS -Node Type parameter is configured to. A Node Type of 0 means use -NetBIOS broadcast (over UDP broadcast) is first used if the name -that is the subject of a name lookup is not found in the NetBIOS name -cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to -Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the -WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast -lookup is used.

    Sharing of desktop profiles between Windows versions is NOT recommended. +Desktop profiles are an evolving phenomenon and profiles for later versions +of MS Windows clients add features that may interfere with earlier versions +of MS Windows clients. Probably the more salient reason to NOT mix profiles +is that when logging off an earlier version of MS Windows the older format +of profile contents may overwrite information that belongs to the newer +version resulting in loss of profile information content when that user logs +on again with the newer version of MS Windows.

    If you then want to share the same Start Menu / Desktop with W9x/Me, you will +need to specify a common location for the profiles. The smb.conf parameters +that need to be common are logon path and +logon home.

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

    10.3.5. WINS Lookup10.2.8. Windows NT 4

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

    Unfortunately, the Resource Kit info is Win NT4 or 200x specific.

    To configure Samba to be a WINS server the following parameter needs -to be added to the smb.conf file:

    Here is a quick guide:

    	wins support = Yes

    • To configure Samba to use a WINS server the following parameters are -needed in the smb.conf file:

      On your NT4 Domain Controller, right click on 'My Computer', then +select the tab labelled 'User Profiles'.

    • Select a user profile you want to migrate and click on it.

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

      where xxx.xxx.xxx.xxx is the IP address -of the WINS server.

      I am using the term "migrate" lossely. You can copy a profile to +create a group profile. You can give the user 'Everyone' rights to the +profile you copy this to. That is what you need to do, since your samba +domain is not a member of a trust relationship with your NT4 PDC.

    • Click the 'Copy To' button.

    • In the box labelled 'Copy Profile to' add your new path, eg: +c:\temp\foobar

    • Click on the button labelled 'Change' in the "Permitted to use" box.

    • Click on the group 'Everyone' and then click OK. This closes the +'chose user' box.

    • Now click OK.

    Follow the above for every profile you need to migrate.

    10.2.8.1. Side bar Notes

    You should obtain the SID of your NT4 domain. You can use smbpasswd to do +this. Read the man page.

    With Samba-3.0.0 alpha code you can import all you NT4 domain accounts +using the net samsync method. This way you can retain your profile +settings as well as all your users.

    10.2.8.2. Mandatory profiles

    The above method can be used to create mandatory profiles also. To convert +a group profile into a mandatory profile simply locate the NTUser.DAT file +in the copied profile and rename it to NTUser.MAN.

    10.2.8.3. moveuser.exe

    The W2K professional resource kit has moveuser.exe. moveuser.exe changes +the security of a profile from one user to another. This allows the account +domain to change, and/or the user name to change.

    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.

    10.2.8.4. Get SID

    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.

    You can identify the SID by using GetSID.exe from the Windows NT Server 4.0 +Resource Kit.

    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.

    Windows NT 4.0 stores the local profile information in the registry under +the following key: +HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

    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.

    Under the ProfileList key, there will be subkeys named with the SIDs of the +users who have logged on to this computer. (To find the profile information +for the user whose locally cached profile you want to move, find the SID for +the user with the GetSID.exe utility.) Inside of the appropriate user's +subkey, you will see a string value named ProfileImagePath.

    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.

    10.2.9. Windows 2000/XP

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

    You must first convert the profile from a local profile to a domain +profile on the MS Windows workstation as follows:

    • An MD4 hash of the UNICODE of the password - string. This is known as the NT hash. -

      Log on as the LOCAL workstation administrator.

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

      Right click on the 'My Computer' Icon, select 'Properties'

    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.

    Click on the 'User Profiles' tab

  • 	passsword level = integer
-	username level = integer

    Select the profile you wish to convert (click on it once)

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

    Click on the button 'Copy To'

  • 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).

    In the "Permitted to use" box, click on the 'Change' button.

  • 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:

    Click on the 'Look in" area that lists the machine name, when you click +here it will open up a selection box. Click on the domain to which the +profile must be accessible.

    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.

    You will need to log on if a logon box opens up. Eg: In the connect +as: MIDEARTH\root, password: mypassword.

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

    To make the profile capable of being used by anyone select 'Everyone'

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

    Click OK. The Selection box will close.

  • Now click on the 'Ok' button to create the profile in the path you +nominated.

    • Done. You now have a profile that can be editted using the samba-3.0.0 +profiles tool.

    Under NT/2K the use of mandotory profiles forces the use of MS Exchange +storage of mail data. That keeps desktop profiles usable.

    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.

      This is a security check new to Windows XP (or maybe only +Windows XP service pack 1). It can be disabled via a group policy in +Active Directory. The policy is:

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

      "Computer Configuration\Administrative Templates\System\User +Profiles\Do not check for user ownership of Roaming Profile Folders"

        ...and it should be set to "Enabled". +Does the new version of samba have an Active Directory analogue? If so, +then you may be able to set the policy through this.

        If you cannot set group policies in samba, then you may be able to set +the policy locally on each machine. If you want to try this, then do +the following (N.B. I don't know for sure that this will work in the +same way as a domain group policy):

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

        On the XP workstation log in with an Administrator account.

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

        Click: "Start", "Run"

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

      Type: "mmc"

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

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

      A Microsoft Management Console should appear.

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

      Click: File, "Add/Remove Snap-in...", "Add"

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

      Double-Click: "Group Policy"

    • 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

      Click: "Finish", "Close"

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

      Click: "OK"

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

      In the "Console Root" window:

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

      Expand: "Local Computer Policy", "Computer Configuration",

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

      10.6. Conclusions

      "Administrative Templates", "System", "User Profiles"

    • Samba provides a flexible means to operate as...

      Double-Click: "Do not check for user ownership of Roaming Profile

      • Folders"

      • A Stand-alone server - No special action is needed - other than to create user accounts. Stand-alone servers do NOT - provide network logon services, meaning that machines that use this - server do NOT perform a domain logon but instead make use only of - the MS Windows logon which is local to the MS Windows - workstation/server. -

        Select: "Enabled"

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

        Click: OK"

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

        Close the whole console. You do not need to save the settings (this +refers to the console settings rather than the policies you have +changed).

      • Reboot

    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

    Chapter 12. Group mapping HOWTO

    +Starting with Samba 3.0 alpha 2, a new group mapping function is available. The +current method (likely to change) to manage the groups is a new command called +smbgroupedit.

    The first immediate reason to use the group mapping on a PDC, is that +the domain admin group of smb.conf is +now gone. This parameter was used to give the listed users local admin rights +on their workstations. It was some magic stuff that simply worked but didn't +scale very well for complex setups.

    Let me explain how it works on NT/W2K, to have this magic fade away. +When installing NT/W2K on a computer, the installer program creates some users +and groups. Notably the 'Administrators' group, and gives to that group some +privileges like the ability to change the date and time or to kill any process +(or close too) running on the local machine. The 'Administrator' user is a +member of the 'Administrators' group, and thus 'inherit' the 'Administrators' +group privileges. If a 'joe' user is created and become a member of the +'Administrator' group, 'joe' has exactly the same rights as 'Administrator'.

    When a NT/W2K machine is joined to a domain, during that phase, the "Domain +Administrators' group of the PDC is added to the 'Administrators' group of the +workstation. Every members of the 'Domain Administrators' group 'inherit' the +rights of the 'Administrators' group when logging on the workstation.

    You are now wondering how to make some of your samba PDC users members of the +'Domain Administrators' ? That's really easy.

    1. create a unix group (usually in /etc/group), let's call it domadm

    2. add to this group the users that must be Administrators. For example if you want joe,john and mary, your entry in /etc/group will look like:

      domadm:x:502:joe,john,mary

    3. Map this domadm group to the domain admins group by running the command:

      smbgroupedit -c "Domain Admins" -u domadm

    You're set, joe, john and mary are domain administrators !

    Like the Domain Admins group, you can map any arbitrary Unix group to any NT +group. You can also make any Unix group a domain group. For example, on a domain +member machine (an NT/W2K or a samba server running winbind), you would like to +give access to a certain directory to some users who are member of a group on +your samba PDC. Flag that group as a domain group by running:

    smbgroupedit -a unixgroup -td

    You can list the various groups in the mapping database like this

    smbgroupedit -v

    Chapter 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 @@ -10128,6 +9649,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 @@ -10164,19 +9724,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 @@ -10239,13 +9799,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 @@ -10256,13 +9816,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 @@ -10273,278 +9833,122 @@ 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

    Note: 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 -capabilities of PAM in this environment. Some Linux implmentations also -provide the pam_stack.so module that allows all -authentication to be configured in a single central file. The -pam_stack.so method has some very devoted followers -on the basis that it allows for easier administration. As with all issues in -life though, every decision makes trade-offs, so you may want examine the -PAM documentation for further helpful information.

    12.2. Distributed Authentication

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

    12.3. PAM Configuration in smb.conf

    There is an option in smb.conf called obey pam restrictions. -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. ---with-pam), this parameter will -control whether or not Samba should obey PAM's account -and session management directives. The default behavior -is to use PAM for clear text authentication only and to -ignore any account or session management. Note that Samba always -ignores PAM for authentication in the case of -encrypt passwords = yes. -The reason is that PAM modules cannot support the challenge/response -authentication mechanism needed in the presence of SMB -password encryption.

    Default: obey pam restrictions = no

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

    13.1. Instructions

    The Distributed File System (or Dfs) provides a means of - separating the logical view of files and directories that users - see from the actual physical locations of these resources on the - network. It allows for higher availability, smoother storage expansion, - load balancing etc. For more information about Dfs, refer to Microsoft documentation.

    This document explains how to host a Dfs tree on a Unix - machine (for Dfs-aware clients to browse) using Samba.

    To enable SMB-based DFS for Samba, configure it with the - --with-msdfs option. Once built, a - Samba server can be made a Dfs server by setting the global - boolean host msdfs parameter in the smb.conf - file. You designate a share as a Dfs root using the share - level boolean msdfs root parameter. A Dfs root directory on - Samba hosts Dfs links in the form of symbolic links that point - to other servers. For example, a symbolic link - junction->msdfs:storage1\share1 in - the share directory acts as the Dfs junction. When Dfs-aware - clients attempt to access the junction link, they are redirected - to the storage location (in this case, \\storage1\share1).

    Dfs trees on Samba work with all Dfs-aware clients ranging - from Windows 95 to 2000.

    Here's an example of setting up a Dfs tree on a Samba - server.

    # The smb.conf file:
-[global]
-	netbios name = SAMBA
-	host msdfs   = yes
-
-[dfs]
-	path = /export/dfsroot
-	msdfs root = yes
-

    In the /export/dfsroot directory we set up our dfs links to - other servers on the network.

    root# cd /export/dfsroot

    root# chown root /export/dfsroot

    root# chmod 755 /export/dfsroot

    root# ln -s msdfs:storageA\\shareA linka

    root# ln -s msdfs:serverB\\share,serverC\\share linkb #%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

    You should set up the permissions and ownership of - the directory acting as the Dfs root such that only designated - users can create, delete or modify the msdfs links. Also note - that symlink names should be all lowercase. This limitation exists - to have Samba avoid trying all the case combinations to get at - the link name. Finally set up the symbolic links to point to the - network shares you want, and start Samba.

    Users on Dfs-aware clients can now browse the Dfs tree - on the Samba server at \\samba\dfs. Accessing - links linka or linkb (which appear as directories to the client) - takes users directly to the appropriate shares on the network.

    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 +capabilities of PAM in this environment. Some Linux implmentations also +provide the pam_stack.so module that allows all +authentication to be configured in a single central file. The +pam_stack.so method has some very devoted followers +on the basis that it allows for easier administration. As with all issues in +life though, every decision makes trade-offs, so you may want examine the +PAM documentation for further helpful information.

    13.1.1. Notes

    13.2. Distributed Authentication

    • The astute administrator will realize from this that the +combination of pam_smbpass.so, +winbindd, 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 +use of Microsoft Active Directory Service (ADS) in so far as +reduction of wide area network authentication traffic.

    13.3. PAM Configuration in smb.conf

    Windows clients need to be rebooted - if a previously mounted non-dfs share is made a dfs - root or vice versa. A better way is to introduce a - new share and make it the dfs root.

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

    Currently there's a restriction that msdfs - symlink names should all be lowercase.

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

    For security purposes, the directory - acting as the root of the Dfs tree should have ownership - and permissions set so that only designated users can - modify the symbolic links in the directory.

    • Default: obey pam restrictions = no

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

    16.5.3.6.1. Linux

    16.5.3.6.2. Solaris

    16.5.3.6.3. Restarting

    16.5.3.7. Configure Winbind and PAM

    16.5.3.7.1. Linux/FreeBSD-specific PAM configuration

    16.5.3.7.2. Solaris-specific configuration

    I also added a try_first_pass line after the winbind.so line to get rid of -annoying double prompts for passwords.

    Now restart your Samba and try connecting through your application that you -configured in the pam.conf.

    16.6. Limitations

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

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

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

    • Currently the winbind PAM module does not take - into account possible workstation and logon time restrictions - that may be been set for Windows NT users, this is - instead up to the PDC to enforce.

    16.7. Conclusion

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

    Chapter 17. Improved browsing in samba

    17.1. Overview of browsing

    SMB networking provides a mechanism by which clients can access a list -of machines in a network, a so-called "browse list". This list -contains machines that are ready to offer file and/or print services -to other machines within the network. Thus it does not include -machines which aren't currently able to do server tasks. The browse -list is heavily used by all SMB clients. Configuration of SMB -browsing has been problematic for some Samba users, hence this -document.

    MS Windows 2000 and later, as with Samba-3 and later, can be -configured to not use NetBIOS over TCP/IP. When configured this way -it is imperative that name resolution (using DNS/LDAP/ADS) be correctly -configured and operative. Browsing will NOT work if name resolution -from SMB machine names to IP addresses does not function correctly.

    Where NetBIOS over TCP/IP is enabled use of a WINS server is highly -recommended to aid the resolution of NetBIOS (SMB) names to IP addresses. -WINS allows remote segment clients to obtain NetBIOS name_type information -that can NOT be provided by any other means of name resolution.

    17.2. Browsing support in samba

    Samba facilitates browsing. The browsing is supported by nmbd -and is also controlled by options in the smb.conf file (see smb.conf(5)). -Samba can act as a local browse master for a workgroup and the ability -for samba to support domain logons and scripts is now available.

    Samba can also act as a domain master browser for a workgroup. This -means that it will collate lists from local browse masters into a -wide area network server list. In order for browse clients to -resolve the names they may find in this list, it is recommended that -both samba and your clients use a WINS server.

    Note that you should NOT set Samba to be the domain master for a -workgroup that has the same name as an NT Domain: on each wide area -network, you must only ever have one domain master browser per workgroup, -regardless of whether it is NT, Samba or any other type of domain master -that is providing this service.

    [Note that nmbd can be configured as a WINS server, but it is not -necessary to specifically use samba as your WINS server. MS Windows -NT4, Server or Advanced Server 2000 or 2003 can be configured as -your WINS server. In a mixed NT/2000/2003 server and samba environment on -a Wide Area Network, it is recommended that you use the Microsoft -WINS server capabilities. In a samba-only environment, it is -recommended that you use one and only one Samba server as your WINS server.

    To get browsing to work you need to run nmbd as usual, but will need -to use the "workgroup" option in smb.conf to control what workgroup -Samba becomes a part of.

    I also added a try_first_pass line after the winbind.so line to get rid of +annoying double prompts for passwords.

    Samba also has a useful option for a Samba server to offer itself for -browsing on another subnet. It is recommended that this option is only -used for 'unusual' purposes: announcements over the internet, for -example. See "remote announce" in the smb.conf man page.

    Now restart your Samba and try connecting through your application that you +configured in the pam.conf.

    17.3. Problem resolution16.6. Limitations

    If something doesn't work then hopefully the log.nmb file will help -you track down the problem. Try a debug level of 2 or 3 for finding -problems. Also note that the current browse list usually gets stored -in text form in a file called browse.dat.

    Note that if it doesn't work for you, then you should still be able to -type the server name as \\SERVER in filemanager then hit enter and -filemanager should display the list of available shares.

    Some people find browsing fails because they don't have the global -"guest account" set to a valid account. Remember that the IPC$ -connection that lists the shares is done as guest, and thus you must -have a valid guest account.

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

    MS Windows 2000 and upwards (as with Samba) can be configured to disallow -anonymous (ie: Guest account) access to the IPC$ share. In that case, the -MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the -name of the currently logged in user to query the IPC$ share. MS Windows -9X clients are not able to do this and thus will NOT be able to browse -server resources.

    • Also, a lot of people are getting bitten by the problem of too many -parameters on the command line of nmbd in inetd.conf. This trick is to -not use spaces between the option and the parameter (eg: -d2 instead -of -d 2), and to not use the -B and -N options. New versions of nmbd -are now far more likely to correctly find your broadcast and network -address, so in most cases these aren't needed.

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

    • The other big problem people have is that their broadcast address, -netmask or IP address is wrong (specified with the "interfaces" option -in smb.conf)

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

    • Currently the winbind PAM module does not take + into account possible workstation and logon time restrictions + that may be been set for Windows NT users, this is + instead up to the PDC to enforce.

    17.4. Browsing across subnets16.7. Conclusion

    Since the release of Samba 1.9.17(alpha1) Samba has been -updated to enable it to support the replication of browse lists -across subnet boundaries. New code and options have been added to -achieve this. This section describes how to set this feature up -in different settings.

    To see browse lists that span TCP/IP subnets (ie. networks separated -by routers that don't pass broadcast traffic) you must set up at least -one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing -NetBIOS name to IP address translation to be done by doing a direct -query of the WINS server. This is done via a directed UDP packet on -port 137 to the WINS server machine. The reason for a WINS server is -that by default, all NetBIOS name to IP address translation is done -by broadcasts from the querying machine. This means that machines -on one subnet will not be able to resolve the names of machines on -another subnet without using a WINS server.

    Remember, for browsing across subnets to work correctly, all machines, -be they Windows 95, Windows NT, or Samba servers must have the IP address -of a WINS server given to them by a DHCP server, or by manual configuration -(for Win95 and WinNT, this is in the TCP/IP Properties, under Network -settings) for Samba this is in the smb.conf file.

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

    17.4.1. How does cross subnet browsing work ?

    Cross subnet browsing is a complicated dance, containing multiple -moving parts. It has taken Microsoft several years to get the code -that achieves this correct, and Samba lags behind in some areas. -Samba is capable of cross subnet browsing when configured correctly.

    Consider a network set up as follows :

                                       (DMB)
-             N1_A      N1_B        N1_C       N1_D        N1_E
-              |          |           |          |           |
-          -------------------------------------------------------
-            |          subnet 1                       |
-          +---+                                      +---+
-          |R1 | Router 1                  Router 2   |R2 |
-          +---+                                      +---+
-            |                                          |
-            |  subnet 2              subnet 3          |
-  --------------------------       ------------------------------------
-  |     |     |      |               |        |         |           |
- N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
-                    (WINS)

    Consisting of 3 subnets (1, 2, 3) connected by two routers -(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines -on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume -for the moment that all these machines are configured to be in the -same workgroup (for simplicities sake). Machine N1_C on subnet 1 -is configured as Domain Master Browser (ie. it will collate the -browse lists for the workgroup). Machine N2_D is configured as -WINS server and all the other machines are configured to register -their NetBIOS names with it.

    As all these machines are booted up, elections for master browsers -will take place on each of the three subnets. Assume that machine -N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on -subnet 3 - these machines are known as local master browsers for -their particular subnet. N1_C has an advantage in winning as the -local master browser on subnet 1 as it is set up as Domain Master -Browser.

    On each of the three networks, machines that are configured to -offer sharing services will broadcast that they are offering -these services. The local master browser on each subnet will -receive these broadcasts and keep a record of the fact that -the machine is offering a service. This list of records is -the basis of the browse list. For this case, assume that -all the machines are configured to offer services so all machines -will be on the browse list.

    For each network, the local master browser on that network is -considered 'authoritative' for all the names it receives via -local broadcast. This is because a machine seen by the local -master browser via a local broadcast must be on the same -network as the local master browser and thus is a 'trusted' -and 'verifiable' resource. Machines on other networks that -the local master browsers learn about when collating their -browse lists have not been directly seen - these records are -called 'non-authoritative'.

    At this point the browse lists look as follows (these are -the machines you would see in your network neighborhood if -you looked in it on a particular network right now).

    Subnet           Browse Master   List
-------           -------------   ----
-Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E
-
-Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
-
-Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D

    Note that at this point all the subnets are separate, no -machine is seen across any of the subnets.

    Now examine subnet 2. As soon as N2_B has become the local -master browser it looks for a Domain master browser to synchronize -its browse list with. It does this by querying the WINS server -(N2_D) for the IP address associated with the NetBIOS name -WORKGROUP>1B<. This name was registerd by the Domain master -browser (N1_C) with the WINS server as soon as it was booted.

    Once N2_B knows the address of the Domain master browser it -tells it that is the local master browser for subnet 2 by -sending a MasterAnnouncement packet as a UDP port 138 packet. -It then synchronizes with it by doing a NetServerEnum2 call. This -tells the Domain Master Browser to send it all the server -names it knows about. Once the domain master browser receives -the MasterAnnouncement packet it schedules a synchronization -request to the sender of that packet. After both synchronizations -are done the browse lists look like :

    Subnet           Browse Master   List
-------           -------------   ----
-Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
-                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
-                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-
-Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
-
-Servers with a (*) after them are non-authoritative names.

    At this point users looking in their network neighborhood on -subnets 1 or 2 will see all the servers on both, users on -subnet 3 will still only see the servers on their own subnet.

    The same sequence of events that occured for N2_B now occurs -for the local master browser on subnet 3 (N3_D). When it -synchronizes browse lists with the domain master browser (N1_A) -it gets both the server entries on subnet 1, and those on -subnet 2. After N3_D has synchronized with N1_C and vica-versa -the browse lists look like.

    Chapter 17. Integrating MS Windows networks with Samba

    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.

    Subnet           Browse Master   List
-------           -------------   ----
-Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
-                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*),
-                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
-                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-
-Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
-                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
-                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-
-Servers with a (*) after them are non-authoritative names.

    At this point users looking in their network neighborhood on -subnets 1 or 3 will see all the servers on all sunbets, users on -subnet 2 will still only see the servers on subnets 1 and 2, but not 3.

    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.

    Finally, the local master browser for subnet 2 (N2_B) will sync again -with the domain master browser (N1_C) and will recieve the missing -server entries. Finally - and as a steady state (if no machines -are removed or shut off) the browse lists will look like :

    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.

    Subnet           Browse Master   List
-------           -------------   ----
-Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
-                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*),
-                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
-                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
-                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
-
-Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
-                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
-                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
-	
-Servers with a (*) after them are non-authoritative names.

    Synchronizations between the domain master browser and local -master browsers will continue to occur, but this should be a -steady state situation.

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

    If either router R1 or R2 fails the following will occur:

    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.

    17.1. Name Resolution in a pure Unix/Linux world

    The key configuration files covered in this section are:

      • Names of computers on each side of the inaccessible network fragments - will be maintained for as long as 36 minutes, in the network neighbourhood - lists. -

        /etc/hosts

      • Attempts to connect to these inaccessible computers will fail, but the - names will not be removed from the network neighbourhood lists. -

        /etc/resolv.conf

      • If one of the fragments is cut off from the WINS server, it will only - be able to access servers on its local subnet, by using subnet-isolated - broadcast NetBIOS name resolution. The effects are similar to that of - losing access to a DNS server. -

        /etc/host.conf

  • /etc/nsswitch.conf

    • 17.5. Setting up a WINS server

    17.1.1. /etc/hosts

    Either a Samba machine or a Windows NT Server machine may be set up -as a WINS server. To set a Samba machine to be a WINS server you must -add the following option to the smb.conf file on the selected machine : -in the [globals] section add the line

    Contains a static list of IP Addresses and names. +eg:

    wins support = yes

    	127.0.0.1	localhost localhost.localdomain
+	192.168.1.1	bigbox.caldera.com	bigbox	alias4box

    Versions of Samba prior to 1.9.17 had this parameter default to -yes. If you have any older versions of Samba on your network it is -strongly suggested you upgrade to a recent version, or at the very -least set the parameter to 'no' on all these machines.

    Machines with "wins support = yes" will keep a list of -all NetBIOS names registered with them, acting as a DNS for NetBIOS names.

    You should set up only ONE wins server. Do NOT set the -"wins support = yes" option on more than one Samba -server.

    The purpose of /etc/hosts is to provide a +name resolution mechanism so that uses do not need to remember +IP addresses.

    To set up a Windows NT Server as a WINS server you need to set up -the WINS service - see your NT documentation for details. Note that -Windows NT WINS Servers can replicate to each other, allowing more -than one to be set up in a complex subnet environment. As Microsoft -refuse to document these replication protocols Samba cannot currently -participate in these replications. It is possible in the future that -a Samba->Samba WINS replication protocol may be defined, in which -case more than one Samba machine could be set up as a WINS server -but currently only one Samba server should have the "wins support = yes" -parameter set.

    Network packets that are sent over the physical network transport +layer communicate not via IP addresses but rather using the Media +Access Control address, or MAC address. IP Addresses are currently +32 bits in length and are typically presented as four (4) decimal +numbers that are separated by a dot (or period). eg: 168.192.1.1

    After the WINS server has been configured you must ensure that all -machines participating on the network are configured with the address -of this WINS server. If your WINS server is a Samba machine, fill in -the Samba machine IP address in the "Primary WINS Server" field of -the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs -in Windows 95 or Windows NT. To tell a Samba server the IP address -of the WINS server add the following line to the [global] section of -all smb.conf files :

    MAC Addresses use 48 bits (or 6 bytes) and are typically represented +as two digit hexadecimal numbers separated by colons. eg: +40:8e:0a:12:34:56

    wins server = >name or IP address<

    Every network interfrace must have an MAC address. Associated with +a MAC address there may be one or more IP addresses. There is NO +relationship between an IP address and a MAC address, all such assignments +are arbitary or discretionary in nature. At the most basic level all +network communications takes place using MAC addressing. Since MAC +addresses must be globally unique, and generally remains fixed for +any particular interface, the assignment of an IP address makes sense +from a network management perspective. More than one IP address can +be assigned per MAC address. One address must be the primary IP address, +this is the address that will be returned in the ARP reply.

    where >name or IP address< is either the DNS name of the WINS server -machine or its IP address.

    When a user or a process wants to communicate with another machine +the protocol implementation ensures that the "machine name" or "host +name" is resolved to an IP address in a manner that is controlled +by the TCP/IP configuration control files. The file +/etc/hosts is one such file.

    Note that this line MUST NOT BE SET in the smb.conf file of the Samba -server acting as the WINS server itself. If you set both the -"wins support = yes" option and the -"wins server = <name>" option then -nmbd will fail to start.

    When the IP address of the destination interface has been +determined a protocol called ARP/RARP is used to identify +the MAC address of the target interface. ARP stands for Address +Resolution Protocol, and is a broadcast oriented method that +uses UDP (User Datagram Protocol) to send a request to all +interfaces on the local network segment using the all 1's MAC +address. Network interfaces are programmed to respond to two +MAC addresses only; their own unique address and the address +ff:ff:ff:ff:ff:ff. The reply packet from an ARP request will +contain the MAC address and the primary IP address for each +interface.

    There are two possible scenarios for setting up cross subnet browsing. -The first details setting up cross subnet browsing on a network containing -Windows 95, Samba and Windows NT machines that are not configured as -part of a Windows NT Domain. The second details setting up cross subnet -browsing on networks that contain NT Domains.

    The /etc/hosts file is foundational to all +Unix/Linux TCP/IP installations and as a minumum will contain +the localhost and local network interface IP addresses and the +primary names by which they are known within the local machine. +This file helps to prime the pump so that a basic level of name +resolution can exist before any other method of name resolution +becomes available.

    17.6. Setting up Browsing in a WORKGROUP

    To set up cross subnet browsing on a network containing machines -in up to be in a WORKGROUP, not an NT Domain you need to set up one -Samba server to be the Domain Master Browser (note that this is *NOT* -the same as a Primary Domain Controller, although in an NT Domain the -same machine plays both roles). The role of a Domain master browser is -to collate the browse lists from local master browsers on all the -subnets that have a machine participating in the workgroup. Without -one machine configured as a domain master browser each subnet would -be an isolated workgroup, unable to see any machines on any other -subnet. It is the presense of a domain master browser that makes -cross subnet browsing possible for a workgroup.

    17.1.2. /etc/resolv.conf

    In an WORKGROUP environment the domain master browser must be a -Samba server, and there must only be one domain master browser per -workgroup name. To set up a Samba server as a domain master browser, -set the following option in the [global] section of the smb.conf file :

    This file tells the name resolution libraries:

    domain master = yes

    • The domain master browser should also preferrably be the local master -browser for its own subnet. In order to achieve this set the following -options in the [global] section of the smb.conf file :

      The name of the domain to which the machine + belongs + 

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

      The name(s) of any domains that should be + automatically searched when trying to resolve unqualified + host names to their IP address +

    • The domain master browser may be the same machine as the WINS -server, if you require.

      The name or IP address of available Domain + Name Servers that may be asked to perform name to address + translation lookups +

    17.1.3. /etc/host.conf

    Next, you should ensure that each of the subnets contains a -machine that can act as a local master browser for the -workgroup. Any MS Windows NT/2K/XP/2003 machine should be -able to do this, as will Windows 9x machines (although these -tend to get rebooted more often, so it's not such a good idea -to use these). To make a Samba server a local master browser -set the following options in the [global] section of the -smb.conf file :

    /etc/host.conf is the primary means by +which the setting in /etc/resolv.conf may be affected. It is a +critical configuration file. This file controls the order by +which name resolution may procede. The typical structure is:

            domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
    order hosts,bind + multi on

    Do not do this for more than one Samba server on each subnet, -or they will war with each other over which is to be the local -master browser.

    The "local master" parameter allows Samba to act as a local master -browser. The "preferred master" causes nmbd to force a browser -election on startup and the "os level" parameter sets Samba high -enough so that it should win any browser elections.

    If you have an NT machine on the subnet that you wish to -be the local master browser then you can disable Samba from -becoming a local master browser by setting the following -options in the [global] section of the smb.conf file :

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

    then both addresses should be returned. Please refer to the +man page for host.conf for further details.

    17.7. Setting up Browsing in a DOMAIN

    If you are adding Samba servers to a Windows NT Domain then -you must not set up a Samba server as a domain master browser. -By default, a Windows NT Primary Domain Controller for a Domain -name is also the Domain master browser for that name, and many -things will break if a Samba server registers the Domain master -browser NetBIOS name (DOMAIN<1B>) with WINS instead of the PDC.

    17.1.4. /etc/nsswitch.conf

    For subnets other than the one containing the Windows NT PDC -you may set up Samba servers as local master browsers as -described. To make a Samba server a local master browser set -the following options in the [global] section of the smb.conf -file :

    This file controls the actual name resolution targets. The +file typically has resolver object specifications as follows:

            domain master = no
-        local master = yes
-        preferred master = yes
-        os level = 65
    # /etc/nsswitch.conf + # + # Name Service Switch configuration file. + # + + passwd: compat + # Alternative entries for password authentication are: + # passwd: compat files nis ldap winbind + shadow: compat + group: compat + + hosts: files nis dns + # Alternative entries for host name resolution are: + # hosts: files dns nis nis+ hesoid db compat ldap wins + networks: nis files dns + + ethers: nis files + protocols: nis files + rpc: nis files + services: nis files

    If you wish to have a Samba server fight the election with machines -on the same subnet you may set the "os level" parameter to lower -levels. By doing this you can tune the order of machines that -will become local master browsers if they are running. For -more details on this see the section "FORCING SAMBA TO BE THE MASTER" -below.

    Of course, each of these mechanisms requires that the appropriate +facilities and/or services are correctly configured.

    If you have Windows NT machines that are members of the domain -on all subnets, and you are sure they will always be running then -you can disable Samba from taking part in browser elections and -ever becoming a local master browser by setting following options -in the [global] section of the smb.conf file :

    It should be noted that unless a network request/message must be +sent, TCP/IP networks are silent. All TCP/IP communications assumes a +principal of speaking only when necessary.

    Starting with version 2.2.0 samba has Linux support for extensions to +the name service switch infrastructure so that linux clients will +be able to obtain resolution of MS Windows NetBIOS names to IP +Addresses. To gain this functionality Samba needs to be compiled +with appropriate arguments to the make command (ie: domain master = no - local master = no - preferred master = no - os level = 0

    make +nsswitch/libnss_wins.so). The resulting library should +then be installed in the /lib directory and +the "wins" parameter needs to be added to the "hosts:" line in +the /etc/nsswitch.conf file. At this point it +will be possible to ping any MS Windows machine by it's NetBIOS +machine name, so long as that machine is within the workgroup to +which both the samba machine and the MS Windows machine belong.

    17.8. Forcing samba to be the master17.2. Name resolution as used within MS Windows networking

    Who becomes the "master browser" is determined by an election process -using broadcasts. Each election packet contains a number of parameters -which determine what precedence (bias) a host should have in the -election. By default Samba uses a very low precedence and thus loses -elections to just about anyone else.

    MS Windows networking is predicated about the name each machine +is given. This name is known variously (and inconsistently) as +the "computer name", "machine name", "networking name", "netbios name", +"SMB name". All terms mean the same thing with the exception of +"netbios name" which can apply also to the name of the workgroup or the +domain name. The terms "workgroup" and "domain" are really just a +simply name with which the machine is associated. All NetBIOS names +are exactly 16 characters in length. The 16th character is reserved. +It is used to store a one byte value that indicates service level +information for the NetBIOS name that is registered. A NetBIOS machine +name is therefore registered for each service type that is provided by +the client/server.

    If you want Samba to win elections then just set the "os level" global -option in smb.conf to a higher number. It defaults to 0. Using 34 -would make it win all elections over every other system (except other -samba systems!)

    The following are typical NetBIOS name/service type registrations:

    	Unique NetBIOS Names:
+		MACHINENAME<00>	= Server Service is running on MACHINENAME
+		MACHINENAME<03> = Generic Machine Name (NetBIOS name)
+		MACHINENAME<20> = LanMan Server service is running on MACHINENAME
+		WORKGROUP<1b> = Domain Master Browser
+
+	Group Names:
+		WORKGROUP<03> = Generic Name registered by all members of WORKGROUP
+		WORKGROUP<1c> = Domain Controllers / Netlogon Servers
+		WORKGROUP<1d> = Local Master Browsers
+		WORKGROUP<1e> = Internet Name Resolvers

    It should be noted that all NetBIOS machines register their own +names as per the above. This is in vast contrast to TCP/IP +installations where traditionally the system administrator will +determine in the /etc/hosts or in the DNS database what names +are associated with each IP address.

    One further point of clarification should be noted, the /etc/hosts +file and the DNS records do not provide the NetBIOS name type information +that MS Windows clients depend on to locate the type of service that may +be needed. An example of this is what happens when an MS Windows client +wants to locate a domain logon server. It find this service and the IP +address of a server that provides it by performing a lookup (via a +NetBIOS broadcast) for enumeration of all machines that have +registered the name type *<1c>. A logon request is then sent to each +IP address that is returned in the enumerated list of IP addresses. Which +ever machine first replies then ends up providing the logon services.

    The name "workgroup" or "domain" really can be confusing since these +have the added significance of indicating what is the security +architecture of the MS Windows network. The term "workgroup" indicates +that the primary nature of the network environment is that of a +peer-to-peer design. In a WORKGROUP all machines are responsible for +their own security, and generally such security is limited to use of +just a password (known as SHARE MODE security). In most situations +with peer-to-peer networking the users who control their own machines +will simply opt to have no security at all. It is possible to have +USER MODE security in a WORKGROUP environment, thus requiring use +of a user name and a matching password.

    A "os level" of 2 would make it beat WfWg and Win95, but not MS Windows -NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.

    MS Windows networking is thus predetermined to use machine names +for all local and remote machine message passing. The protocol used is +called Server Message Block (SMB) and this is implemented using +the NetBIOS protocol (Network Basic Input Output System). NetBIOS can +be encapsulated using LLC (Logical Link Control) protocol - in which case +the resulting protocol is called NetBEUI (Network Basic Extended User +Interface). NetBIOS can also be run over IPX (Internetworking Packet +Exchange) protocol as used by Novell NetWare, and it can be run +over TCP/IP protocols - in which case the resulting protocol is called +NBT or NetBT, the NetBIOS over TCP/IP.

    The maximum os level is 255

    MS Windows machines use a complex array of name resolution mechanisms. +Since we are primarily concerned with TCP/IP this demonstration is +limited to this area.

    17.2.1. The NetBIOS Name Cache

    If you want samba to force an election on startup, then set the -"preferred master" global option in smb.conf to "yes". Samba will -then have a slight advantage over other potential master browsers -that are not preferred master browsers. Use this parameter with -care, as if you have two hosts (whether they are windows 95 or NT or -samba) on the same local subnet both set with "preferred master" to -"yes", then periodically and continually they will force an election -in order to become the local master browser.

    All MS Windows machines employ an in memory buffer in which is +stored the NetBIOS names and IP addresses for all external +machines that that machine has communicated with over the +past 10-15 minutes. It is more efficient to obtain an IP address +for a machine from the local cache than it is to go through all the +configured name resolution mechanisms.

    If you want samba to be a "domain master browser", then it is -recommended that you also set "preferred master" to "yes", because -samba will not become a domain master browser for the whole of your -LAN or WAN if it is not also a local master browser on its own -broadcast isolated subnet.

    If a machine whose name is in the local name cache has been shut +down before the name had been expired and flushed from the cache, then +an attempt to exchange a message with that machine will be subject +to time-out delays. i.e.: Its name is in the cache, so a name resolution +lookup will succeed, but the machine can not respond. This can be +frustrating for users - but it is a characteristic of the protocol.

    It is possible to configure two samba servers to attempt to become -the domain master browser for a domain. The first server that comes -up will be the domain master browser. All other samba servers will -attempt to become the domain master browser every 5 minutes. They -will find that another samba server is already the domain master -browser and will fail. This provides automatic redundancy, should -the current domain master browser fail.

    The MS Windows utility that allows examination of the NetBIOS +name cache is called "nbtstat". The Samba equivalent of this +is called "nmblookup".

    17.9. Making samba the domain master

    The domain master is responsible for collating the browse lists of -multiple subnets so that browsing can occur between subnets. You can -make samba act as the domain master by setting "domain master = yes" -in smb.conf. By default it will not be a domain master.

    Note that you should NOT set Samba to be the domain master for a -workgroup that has the same name as an NT Domain.

    When samba is the domain master and the master browser it will listen -for master announcements (made roughly every twelve minutes) from local -master browsers on other subnets and then contact them to synchronise -browse lists.

    If you want samba to be the domain master then I suggest you also set -the "os level" high enough to make sure it wins elections, and set -"preferred master" to "yes", to get samba to force an election on -startup.

    Note that all your servers (including samba) and clients should be -using a WINS server to resolve NetBIOS names. If your clients are only -using broadcasting to resolve NetBIOS names, then two things will occur:

    1. your local master browsers will be unable to find a domain master - browser, as it will only be looking on the local subnet. -

    2. 17.2.2. The LMHOSTS file

      if a client happens to get hold of a domain-wide browse list, and - a user attempts to access a host in that list, it will be unable to - resolve the NetBIOS name of that host. -

    This file is usually located in MS Windows NT 4.0 or +2000 in C:\WINNT\SYSTEM32\DRIVERS\ETC and contains +the IP Address and the machine name in matched pairs. The +LMHOSTS file performs NetBIOS name +to IP address mapping oriented.

    If, however, both samba and your clients are using a WINS server, then:

    It typically looks like:

    	# Copyright (c) 1998 Microsoft Corp.
+	#
+	# This is a sample LMHOSTS file used by the Microsoft Wins Client (NetBIOS
+	# over TCP/IP) stack for Windows98
+	#
+	# This file contains the mappings of IP addresses to NT computernames
+	# (NetBIOS) names.  Each entry should be kept on an individual line.
+	# The IP address should be placed in the first column followed by the
+	# corresponding computername. The address and the comptername
+	# should be separated by at least one space or tab. The "#" character
+	# is generally used to denote the start of a comment (see the exceptions
+	# below).
+	#
+	# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
+	# files and offers the following extensions:
+	#
+	#      #PRE
+	#      #DOM:<domain>
+	#      #INCLUDE <filename>
+	#      #BEGIN_ALTERNATE
+	#      #END_ALTERNATE
+	#      \0xnn (non-printing character support)
+	#
+	# Following any entry in the file with the characters "#PRE" will cause
+	# the entry to be preloaded into the name cache. By default, entries are
+	# not preloaded, but are parsed only after dynamic name resolution fails.
+	#
+	# Following an entry with the "#DOM:<domain>" tag will associate the
+	# entry with the domain specified by <domain>. This affects how the
+	# browser and logon services behave in TCP/IP environments. To preload
+	# the host name associated with #DOM entry, it is necessary to also add a
+	# #PRE to the line. The <domain> is always preloaded although it will not
+	# be shown when the name cache is viewed.
+	#
+	# Specifying "#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
+	# software to seek the specified <filename> and parse it as if it were
+	# local. <filename> is generally a UNC-based name, allowing a
+	# centralized lmhosts file to be maintained on a server.
+	# It is ALWAYS necessary to provide a mapping for the IP address of the
+	# server prior to the #INCLUDE. This mapping must use the #PRE directive.
+	# In addtion the share "public" in the example below must be in the
+	# LanManServer list of "NullSessionShares" in order for client machines to
+	# be able to read the lmhosts file successfully. This key is under
+	# \machine\system\currentcontrolset\services\lanmanserver\parameters\nullsessionshares
+	# in the registry. Simply add "public" to the list found there.
+	#
+	# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
+	# statements to be grouped together. Any single successful include
+	# will cause the group to succeed.
+	#
+	# Finally, non-printing characters can be embedded in mappings by
+	# first surrounding the NetBIOS name in quotations, then using the
+	# \0xnn notation to specify a hex value for a non-printing character.
+	#
+	# The following example illustrates all of these extensions:
+	#
+	# 102.54.94.97     rhino         #PRE #DOM:networking  #net group's DC
+	# 102.54.94.102    "appname  \0x14"                    #special app server
+	# 102.54.94.123    popular            #PRE             #source server
+	# 102.54.94.117    localsrv           #PRE             #needed for the include
+	#
+	# #BEGIN_ALTERNATE
+	# #INCLUDE \\localsrv\public\lmhosts
+	# #INCLUDE \\rhino\public\lmhosts
+	# #END_ALTERNATE
+	#
+	# In the above example, the "appname" server contains a special
+	# character in its name, the "popular" and "localsrv" server names are
+	# preloaded, and the "rhino" server name is specified so it can be used
+	# to later #INCLUDE a centrally maintained lmhosts file if the "localsrv"
+	# system is unavailable.
+	#
+	# Note that the whole file is parsed including comments on each lookup,
+	# so keeping the number of comments to a minimum will improve performance.
+	# Therefore it is not advisable to simply add lmhosts file entries onto the
+	# end of this file.

    1. your local master browsers will contact the WINS server and, as long as - samba has registered that it is a domain master browser with the WINS - server, your local master browser will receive samba's ip address - as its domain master browser. -

    17.2.3. HOSTS file

    when a client receives a domain-wide browse list, and a user attempts - to access a host in that list, it will contact the WINS server to - resolve the NetBIOS name of that host. as long as that host has - registered its NetBIOS name with the same WINS server, the user will - be able to see that host. -

    This file is usually located in MS Windows NT 4.0 or 2000 in +C:\WINNT\SYSTEM32\DRIVERS\ETC and contains +the IP Address and the IP hostname in matched pairs. It can be +used by the name resolution infrastructure in MS Windows, depending +on how the TCP/IP environment is configured. This file is in +every way the equivalent of the Unix/Linux /etc/hosts file.

    17.10. Note about broadcast addresses

    17.2.4. DNS Lookup

    If your network uses a "0" based broadcast address (for example if it -ends in a 0) then you will strike problems. Windows for Workgroups -does not seem to support a 0's broadcast and you will probably find -that browsing and name lookups won't work.

    This capability is configured in the TCP/IP setup area in the network +configuration facility. If enabled an elaborate name resolution sequence +is followed the precise nature of which isdependant on what the NetBIOS +Node Type parameter is configured to. A Node Type of 0 means use +NetBIOS broadcast (over UDP broadcast) is first used if the name +that is the subject of a name lookup is not found in the NetBIOS name +cache. If that fails then DNS, HOSTS and LMHOSTS are checked. If set to +Node Type 8, then a NetBIOS Unicast (over UDP Unicast) is sent to the +WINS Server to obtain a lookup before DNS, HOSTS, LMHOSTS, or broadcast +lookup is used.

    17.11. Multiple interfaces

    17.2.5. WINS Lookup

    Samba now supports machines with multiple network interfaces. If you -have multiple interfaces then you will need to use the "interfaces" -option in smb.conf to configure them. See smb.conf(5) for details.

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

    To configure Samba to be a WINS server the following parameter needs +to be added to the smb.conf file:

    	wins support = Yes

    To configure Samba to use a WINS server the following parameters are +needed in the smb.conf file:

    	wins support = No
+	wins server = xxx.xxx.xxx.xxx

    where xxx.xxx.xxx.xxx is the IP address +of the WINS server.

    Chapter 18. Stackable VFS modules

    Chapter 18. Improved browsing in samba

    18.1. Introduction and configuration18.1. Overview of browsing

    Since samba 3.0, samba supports stackable VFS(Virtual File System) modules. -Samba passes each request to access the unix file system thru the loaded VFS modules. -This chapter covers all the modules that come with the samba source and references to -some external modules.

    You may have problems to compile these modules, as shared libraries are -compiled and linked in different ways on different systems. -They currently have been tested against GNU/linux and IRIX.

    To use the VFS modules, create a share similar to the one below. The -important parameter is the vfs object parameter which must point to -the exact pathname of the shared library objects. For example, to log all access -to files and use a recycle bin: - -

           [audit]
-                comment = Audited /data directory
-                path = /data
-                vfs object = /path/to/audit.so /path/to/recycle.so
-                writeable = yes
-                browseable = yes

    SMB networking provides a mechanism by which clients can access a list +of machines in a network, a so-called "browse list". This list +contains machines that are ready to offer file and/or print services +to other machines within the network. Thus it does not include +machines which aren't currently able to do server tasks. The browse +list is heavily used by all SMB clients. Configuration of SMB +browsing has been problematic for some Samba users, hence this +document.

    The modules are used in the order they are specified.

    MS Windows 2000 and later, as with Samba-3 and later, can be +configured to not use NetBIOS over TCP/IP. When configured this way +it is imperative that name resolution (using DNS/LDAP/ADS) be correctly +configured and operative. Browsing will NOT work if name resolution +from SMB machine names to IP addresses does not function correctly.

    Further documentation on writing VFS modules for Samba can be found in -the Samba Developers Guide.

    Where NetBIOS over TCP/IP is enabled use of a WINS server is highly +recommended to aid the resolution of NetBIOS (SMB) names to IP addresses. +WINS allows remote segment clients to obtain NetBIOS name_type information +that can NOT be provided by any other means of name resolution.

    18.2. Included modules18.2. Browsing support in samba

    18.2.1. audit

    A simple module to audit file access to the syslog -facility. The following operations are logged: -

    share
    connect/disconnect
    directory opens/create/remove
    file open/close/rename/unlink/chmod

    18.2.2. recycle

    A recycle-bin like modules. When used any unlink call -will be intercepted and files moved to the recycle -directory instead of beeing deleted.

    Supported options: -

    vfs_recycle_bin:repository

    FIXME

    vfs_recycle_bin:keeptree

    FIXME

    vfs_recycle_bin:versions

    FIXME

    vfs_recycle_bin:touch
    Samba facilitates browsing. The browsing is supported by nmbd +and is also controlled by options in the smb.conf file (see smb.conf(5)). +Samba can act as a local browse master for a workgroup and the ability +for samba to support domain logons and scripts is now available.

    FIXME

    vfs_recycle_bin:maxsize
    Samba can also act as a domain master browser for a workgroup. This +means that it will collate lists from local browse masters into a +wide area network server list. In order for browse clients to +resolve the names they may find in this list, it is recommended that +both samba and your clients use a WINS server.

    FIXME

    vfs_recycle_bin:exclude
    Note that you should NOT set Samba to be the domain master for a +workgroup that has the same name as an NT Domain: on each wide area +network, you must only ever have one domain master browser per workgroup, +regardless of whether it is NT, Samba or any other type of domain master +that is providing this service.

    FIXME

    vfs_recycle_bin:exclude_dir
    [Note that nmbd can be configured as a WINS server, but it is not +necessary to specifically use samba as your WINS server. MS Windows +NT4, Server or Advanced Server 2000 or 2003 can be configured as +your WINS server. In a mixed NT/2000/2003 server and samba environment on +a Wide Area Network, it is recommended that you use the Microsoft +WINS server capabilities. In a samba-only environment, it is +recommended that you use one and only one Samba server as your WINS server.

    FIXME

    vfs_recycle_bin:noversions
    To get browsing to work you need to run nmbd as usual, but will need +to use the "workgroup" option in smb.conf to control what workgroup +Samba becomes a part of.

    FIXME

    Samba also has a useful option for a Samba server to offer itself for +browsing on another subnet. It is recommended that this option is only +used for 'unusual' purposes: announcements over the internet, for +example. See "remote announce" in the smb.conf man page.

    18.2.3. netatalk

    18.3. Problem resolution

    A netatalk module, that will ease co-existence of samba and -netatalk file sharing services.

    If something doesn't work then hopefully the log.nmb file will help +you track down the problem. Try a debug level of 2 or 3 for finding +problems. Also note that the current browse list usually gets stored +in text form in a file called browse.dat.

    Advantages compared to the old netatalk module: -

    it doesn't care about creating of .AppleDouble forks, just keeps ones in sync
    if share in smb.conf doesn't contain .AppleDouble item in hide or veto list, it will be added automatically
    Note that if it doesn't work for you, then you should still be able to +type the server name as \\SERVER in filemanager then hit enter and +filemanager should display the list of available shares.

    Some people find browsing fails because they don't have the global +"guest account" set to a valid account. Remember that the IPC$ +connection that lists the shares is done as guest, and thus you must +have a valid guest account.

    MS Windows 2000 and upwards (as with Samba) can be configured to disallow +anonymous (ie: Guest account) access to the IPC$ share. In that case, the +MS Windows 2000/XP/2003 machine acting as an SMB/CIFS client will use the +name of the currently logged in user to query the IPC$ share. MS Windows +9X clients are not able to do this and thus will NOT be able to browse +server resources.

    Also, a lot of people are getting bitten by the problem of too many +parameters on the command line of nmbd in inetd.conf. This trick is to +not use spaces between the option and the parameter (eg: -d2 instead +of -d 2), and to not use the -B and -N options. New versions of nmbd +are now far more likely to correctly find your broadcast and network +address, so in most cases these aren't needed.

    The other big problem people have is that their broadcast address, +netmask or IP address is wrong (specified with the "interfaces" option +in smb.conf)

    18.3. VFS modules available elsewhere18.4. Browsing across subnets

    This section contains a listing of various other VFS modules that -have been posted but don't currently reside in the Samba CVS -tree for one reason ot another (e.g. it is easy for the maintainer -to have his or her own CVS tree).

    Since the release of Samba 1.9.17(alpha1) Samba has been +updated to enable it to support the replication of browse lists +across subnet boundaries. New code and options have been added to +achieve this. This section describes how to set this feature up +in different settings.

    No statemets about the stability or functionality any module -should be implied due to its presence here.

    To see browse lists that span TCP/IP subnets (ie. networks separated +by routers that don't pass broadcast traffic) you must set up at least +one WINS server. The WINS server acts as a DNS for NetBIOS names, allowing +NetBIOS name to IP address translation to be done by doing a direct +query of the WINS server. This is done via a directed UDP packet on +port 137 to the WINS server machine. The reason for a WINS server is +that by default, all NetBIOS name to IP address translation is done +by broadcasts from the querying machine. This means that machines +on one subnet will not be able to resolve the names of machines on +another subnet without using a WINS server.

    Remember, for browsing across subnets to work correctly, all machines, +be they Windows 95, Windows NT, or Samba servers must have the IP address +of a WINS server given to them by a DHCP server, or by manual configuration +(for Win95 and WinNT, this is in the TCP/IP Properties, under Network +settings) for Samba this is in the smb.conf file.

    18.3.1. DatabaseFS18.4.1. How does cross subnet browsing work ?

    URL: http://www.css.tayloru.edu/~elorimer/databasefs/index.phpCross subnet browsing is a complicated dance, containing multiple +moving parts. It has taken Microsoft several years to get the code +that achieves this correct, and Samba lags behind in some areas. +Samba is capable of cross subnet browsing when configured correctly.

    Consider a network set up as follows :

                                       (DMB)
+             N1_A      N1_B        N1_C       N1_D        N1_E
+              |          |           |          |           |
+          -------------------------------------------------------
+            |          subnet 1                       |
+          +---+                                      +---+
+          |R1 | Router 1                  Router 2   |R2 |
+          +---+                                      +---+
+            |                                          |
+            |  subnet 2              subnet 3          |
+  --------------------------       ------------------------------------
+  |     |     |      |               |        |         |           |
+ N2_A  N2_B  N2_C   N2_D           N3_A     N3_B      N3_C        N3_D 
+                    (WINS)

    By Eric Lorimer.

    Consisting of 3 subnets (1, 2, 3) connected by two routers +(R1, R2) - these do not pass broadcasts. Subnet 1 has 5 machines +on it, subnet 2 has 4 machines, subnet 3 has 4 machines. Assume +for the moment that all these machines are configured to be in the +same workgroup (for simplicities sake). Machine N1_C on subnet 1 +is configured as Domain Master Browser (ie. it will collate the +browse lists for the workgroup). Machine N2_D is configured as +WINS server and all the other machines are configured to register +their NetBIOS names with it.

    I have created a VFS module which implements a fairly complete read-only -filesystem. It presents information from a database as a filesystem in -a modular and generic way to allow different databases to be used -(originally designed for organizing MP3s under directories such as -"Artists," "Song Keywords," etc... I have since applied it to a student -roster database very easily). The directory structure is stored in the -database itself and the module makes no assumptions about the database -structure beyond the table it requires to run.

    As all these machines are booted up, elections for master browsers +will take place on each of the three subnets. Assume that machine +N1_C wins on subnet 1, N2_B wins on subnet 2, and N3_D wins on +subnet 3 - these machines are known as local master browsers for +their particular subnet. N1_C has an advantage in winning as the +local master browser on subnet 1 as it is set up as Domain Master +Browser.

    Any feedback would be appreciated: comments, suggestions, patches, -etc... If nothing else, hopefully it might prove useful for someone -else who wishes to create a virtual filesystem.

    18.3.2. vscan

    On each of the three networks, machines that are configured to +offer sharing services will broadcast that they are offering +these services. The local master browser on each subnet will +receive these broadcasts and keep a record of the fact that +the machine is offering a service. This list of records is +the basis of the browse list. For this case, assume that +all the machines are configured to offer services so all machines +will be on the browse list.

    URL: http://www.openantivirus.org/For each network, the local master browser on that network is +considered 'authoritative' for all the names it receives via +local broadcast. This is because a machine seen by the local +master browser via a local broadcast must be on the same +network as the local master browser and thus is a 'trusted' +and 'verifiable' resource. Machines on other networks that +the local master browsers learn about when collating their +browse lists have not been directly seen - these records are +called 'non-authoritative'.

    At this point the browse lists look as follows (these are +the machines you would see in your network neighborhood if +you looked in it on a particular network right now).

    Subnet           Browse Master   List
+------           -------------   ----
+Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E
+
+Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
+
+Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D

    samba-vscan is a proof-of-concept module for Samba, which -uses the VFS (virtual file system) features of Samba 2.2.x/3.0 -alphaX. Of couse, Samba has to be compiled with VFS support. -samba-vscan supports various virus scanners and is maintained -by Rainer Link.

    Chapter 19. Group mapping HOWTO

    Note that at this point all the subnets are separate, no +machine is seen across any of the subnets.

    -Starting with Samba 3.0 alpha 2, a new group mapping function is available. The -current method (likely to change) to manage the groups is a new command called -smbgroupedit.

    Now examine subnet 2. As soon as N2_B has become the local +master browser it looks for a Domain master browser to synchronize +its browse list with. It does this by querying the WINS server +(N2_D) for the IP address associated with the NetBIOS name +WORKGROUP>1B<. This name was registerd by the Domain master +browser (N1_C) with the WINS server as soon as it was booted.

    The first immediate reason to use the group mapping on a PDC, is that -the domain admin group of smb.conf is -now gone. This parameter was used to give the listed users local admin rights -on their workstations. It was some magic stuff that simply worked but didn't -scale very well for complex setups.

    Once N2_B knows the address of the Domain master browser it +tells it that is the local master browser for subnet 2 by +sending a MasterAnnouncement packet as a UDP port 138 packet. +It then synchronizes with it by doing a NetServerEnum2 call. This +tells the Domain Master Browser to send it all the server +names it knows about. Once the domain master browser receives +the MasterAnnouncement packet it schedules a synchronization +request to the sender of that packet. After both synchronizations +are done the browse lists look like :

    Subnet           Browse Master   List
+------           -------------   ----
+Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
+                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+
+Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
+                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+
+Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
+
+Servers with a (*) after them are non-authoritative names.

    At this point users looking in their network neighborhood on +subnets 1 or 2 will see all the servers on both, users on +subnet 3 will still only see the servers on their own subnet.

    The same sequence of events that occured for N2_B now occurs +for the local master browser on subnet 3 (N3_D). When it +synchronizes browse lists with the domain master browser (N1_A) +it gets both the server entries on subnet 1, and those on +subnet 2. After N3_D has synchronized with N1_C and vica-versa +the browse lists look like.

    Subnet           Browse Master   List
+------           -------------   ----
+Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
+                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*),
+                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+
+Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
+                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+
+Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
+                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
+                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+
+Servers with a (*) after them are non-authoritative names.

    At this point users looking in their network neighborhood on +subnets 1 or 3 will see all the servers on all sunbets, users on +subnet 2 will still only see the servers on subnets 1 and 2, but not 3.

    Finally, the local master browser for subnet 2 (N2_B) will sync again +with the domain master browser (N1_C) and will recieve the missing +server entries. Finally - and as a steady state (if no machines +are removed or shut off) the browse lists will look like :

    Let me explain how it works on NT/W2K, to have this magic fade away. -When installing NT/W2K on a computer, the installer program creates some users -and groups. Notably the 'Administrators' group, and gives to that group some -privileges like the ability to change the date and time or to kill any process -(or close too) running on the local machine. The 'Administrator' user is a -member of the 'Administrators' group, and thus 'inherit' the 'Administrators' -group privileges. If a 'joe' user is created and become a member of the -'Administrator' group, 'joe' has exactly the same rights as 'Administrator'.

    Subnet           Browse Master   List
+------           -------------   ----
+Subnet1          N1_C            N1_A, N1_B, N1_C, N1_D, N1_E, 
+                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*),
+                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+
+Subnet2          N2_B            N2_A, N2_B, N2_C, N2_D
+                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*)
+                                 N3_A(*), N3_B(*), N3_C(*), N3_D(*)
+
+Subnet3          N3_D            N3_A, N3_B, N3_C, N3_D
+                                 N1_A(*), N1_B(*), N1_C(*), N1_D(*), N1_E(*),
+                                 N2_A(*), N2_B(*), N2_C(*), N2_D(*)
+	
+Servers with a (*) after them are non-authoritative names.

    When a NT/W2K machine is joined to a domain, during that phase, the "Domain -Administrators' group of the PDC is added to the 'Administrators' group of the -workstation. Every members of the 'Domain Administrators' group 'inherit' the -rights of the 'Administrators' group when logging on the workstation.

    Synchronizations between the domain master browser and local +master browsers will continue to occur, but this should be a +steady state situation.

    You are now wondering how to make some of your samba PDC users members of the -'Domain Administrators' ? That's really easy.

    If either router R1 or R2 fails the following will occur:

    1. create a unix group (usually in /etc/group), let's call it domadm

      Names of computers on each side of the inaccessible network fragments + will be maintained for as long as 36 minutes, in the network neighbourhood + lists. +

    2. add to this group the users that must be Administrators. For example if you want joe,john and mary, your entry in /etc/group will look like:

      domadm:x:502:joe,john,mary

      Attempts to connect to these inaccessible computers will fail, but the + names will not be removed from the network neighbourhood lists. +

    3. Map this domadm group to the domain admins group by running the command:

      If one of the fragments is cut off from the WINS server, it will only + be able to access servers on its local subnet, by using subnet-isolated + broadcast NetBIOS name resolution. The effects are similar to that of + losing access to a DNS server. +

    18.5. Setting up a WINS server

    Either a Samba machine or a Windows NT Server machine may be set up +as a WINS server. To set a Samba machine to be a WINS server you must +add the following option to the smb.conf file on the selected machine : +in the [globals] section add the line

    smbgroupedit -c "Domain Admins" -u domadm wins support = yes

    You're set, joe, john and mary are domain administrators !

    Versions of Samba prior to 1.9.17 had this parameter default to +yes. If you have any older versions of Samba on your network it is +strongly suggested you upgrade to a recent version, or at the very +least set the parameter to 'no' on all these machines.

    Like the Domain Admins group, you can map any arbitrary Unix group to any NT -group. You can also make any Unix group a domain group. For example, on a domain -member machine (an NT/W2K or a samba server running winbind), you would like to -give access to a certain directory to some users who are member of a group on -your samba PDC. Flag that group as a domain group by running:

    Machines with "wins support = yes" will keep a list of +all NetBIOS names registered with them, acting as a DNS for NetBIOS names.

    You should set up only ONE wins server. Do NOT set the +"smbgroupedit -a unixgroup -td

    wins support = yes" option on more than one Samba +server.

    You can list the various groups in the mapping database like this

    To set up a Windows NT Server as a WINS server you need to set up +the WINS service - see your NT documentation for details. Note that +Windows NT WINS Servers can replicate to each other, allowing more +than one to be set up in a complex subnet environment. As Microsoft +refuse to document these replication protocols Samba cannot currently +participate in these replications. It is possible in the future that +a Samba->Samba WINS replication protocol may be defined, in which +case more than one Samba machine could be set up as a WINS server +but currently only one Samba server should have the "wins support = yes" +parameter set.

    After the WINS server has been configured you must ensure that all +machines participating on the network are configured with the address +of this WINS server. If your WINS server is a Samba machine, fill in +the Samba machine IP address in the "Primary WINS Server" field of +the "Control Panel->Network->Protocols->TCP->WINS Server" dialogs +in Windows 95 or Windows NT. To tell a Samba server the IP address +of the WINS server add the following line to the [global] section of +all smb.conf files :

    smbgroupedit -vwins server = >name or IP address<

    Chapter 20. Samba performance issues

    20.1. Comparisons

    The Samba server uses TCP to talk to the client. Thus if you are -trying to see if it performs well you should really compare it to -programs that use the same protocol. The most readily available -programs for file transfer that use TCP are ftp or another TCP based -SMB server.

    If you want to test against something like a NT or WfWg server then -you will have to disable all but TCP on either the client or -server. Otherwise you may well be using a totally different protocol -(such as Netbeui) and comparisons may not be valid.

    where >name or IP address< is either the DNS name of the WINS server +machine or its IP address.

    Generally you should find that Samba performs similarly to ftp at raw -transfer speed. It should perform quite a bit faster than NFS, -although this very much depends on your system.

    Note that this line MUST NOT BE SET in the smb.conf file of the Samba +server acting as the WINS server itself. If you set both the +"wins support = yes" option and the +"wins server = <name>" option then +nmbd will fail to start.

    Several people have done comparisons between Samba and Novell, NFS or -WinNT. In some cases Samba performed the best, in others the worst. I -suspect the biggest factor is not Samba vs some other system but the -hardware and drivers used on the various systems. Given similar -hardware Samba should certainly be competitive in speed with other -systems.

    There are two possible scenarios for setting up cross subnet browsing. +The first details setting up cross subnet browsing on a network containing +Windows 95, Samba and Windows NT machines that are not configured as +part of a Windows NT Domain. The second details setting up cross subnet +browsing on networks that contain NT Domains.

    20.2. Socket options18.6. Setting up Browsing in a WORKGROUP

    There are a number of socket options that can greatly affect the -performance of a TCP based server like Samba.

    To set up cross subnet browsing on a network containing machines +in up to be in a WORKGROUP, not an NT Domain you need to set up one +Samba server to be the Domain Master Browser (note that this is *NOT* +the same as a Primary Domain Controller, although in an NT Domain the +same machine plays both roles). The role of a Domain master browser is +to collate the browse lists from local master browsers on all the +subnets that have a machine participating in the workgroup. Without +one machine configured as a domain master browser each subnet would +be an isolated workgroup, unable to see any machines on any other +subnet. It is the presense of a domain master browser that makes +cross subnet browsing possible for a workgroup.

    The socket options that Samba uses are settable both on the command -line with the -O option, or in the smb.conf file.

    In an WORKGROUP environment the domain master browser must be a +Samba server, and there must only be one domain master browser per +workgroup name. To set up a Samba server as a domain master browser, +set the following option in the [global] section of the smb.conf file :

    The "socket options" section of the smb.conf manual page describes how -to set these and gives recommendations.

    domain master = yes

    Getting the socket options right can make a big difference to your -performance, but getting them wrong can degrade it by just as -much. The correct settings are very dependent on your local network.

    The domain master browser should also preferrably be the local master +browser for its own subnet. In order to achieve this set the following +options in the [global] section of the smb.conf file :

    The socket option TCP_NODELAY is the one that seems to make the -biggest single difference for most networks. Many people report that -adding "socket options = TCP_NODELAY" doubles the read performance of -a Samba drive. The best explanation I have seen for this is that the -Microsoft TCP/IP stack is slow in sending tcp ACKs.

    20.3. Read size

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

    The option "read size" affects the overlap of disk reads/writes with -network reads/writes. If the amount of data being transferred in -several of the SMB commands (currently SMBwrite, SMBwriteX and -SMBreadbraw) is larger than this value then the server begins writing -the data before it has received the whole packet from the network, or -in the case of SMBreadbraw, it begins writing to the network before -all the data has been read from disk.

    The domain master browser may be the same machine as the WINS +server, if you require.

    Next, you should ensure that each of the subnets contains a +machine that can act as a local master browser for the +workgroup. Any MS Windows NT/2K/XP/2003 machine should be +able to do this, as will Windows 9x machines (although these +tend to get rebooted more often, so it's not such a good idea +to use these). To make a Samba server a local master browser +set the following options in the [global] section of the +smb.conf file :

    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, +or they will war with each other over which is to be the local +master browser.

    The "local master" parameter allows Samba to act as a local master +browser. The "preferred master" causes nmbd to force a browser +election on startup and the "os level" parameter sets Samba high +enough so that it should win any browser elections.

    This overlapping works best when the speeds of disk and network access -are similar, having very little effect when the speed of one is much -greater than the other.

    If you have an NT machine on the subnet that you wish to +be the local master browser then you can disable Samba from +becoming a local master browser by setting the following +options in the [global] section of the smb.conf file :

    The default value is 16384, but very little experimentation has been -done yet to determine the optimal value, and it is likely that the best -value will vary greatly between systems anyway. A value over 65536 is -pointless and will cause you to allocate memory unnecessarily.

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

    20.4. Max xmit18.7. Setting up Browsing in a DOMAIN

    At startup the client and server negotiate a "maximum transmit" size, -which limits the size of nearly all SMB commands. You can set the -maximum size that Samba will negotiate using the "max xmit = " option -in smb.conf. Note that this is the maximum size of SMB request that -Samba will accept, but not the maximum size that the *client* will accept. -The client maximum receive size is sent to Samba by the client and Samba -honours this limit.

    It defaults to 65536 bytes (the maximum), but it is possible that some -clients may perform better with a smaller transmit unit. Trying values -of less than 2048 is likely to cause severe problems.

    If you are adding Samba servers to a Windows NT Domain then +you must not set up a Samba server as a domain master browser. +By default, a Windows NT Primary Domain Controller for a Domain +name is also the Domain master browser for that name, and many +things will break if a Samba server registers the Domain master +browser NetBIOS name (DOMAIN<1B>) with WINS instead of the PDC.

    In most cases the default is the best option.

    20.5. Log level

    For subnets other than the one containing the Windows NT PDC +you may set up Samba servers as local master browsers as +described. To make a Samba server a local master browser set +the following options in the [global] section of the smb.conf +file :

    If you set the log level (also known as "debug level") higher than 2 -then you may suffer a large drop in performance. This is because the -server flushes the log file after each operation, which can be very -expensive.

    20.6. Read raw

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

    The "read raw" operation is designed to be an optimised, low-latency -file read operation. A server may choose to not support it, -however. and Samba makes support for "read raw" optional, with it -being enabled by default.

    If you wish to have a Samba server fight the election with machines +on the same subnet you may set the "os level" parameter to lower +levels. By doing this you can tune the order of machines that +will become local master browsers if they are running. For +more details on this see the section "FORCING SAMBA TO BE THE MASTER" +below.

    In some cases clients don't handle "read raw" very well and actually -get lower performance using it than they get using the conventional -read operations.

    If you have Windows NT machines that are members of the domain +on all subnets, and you are sure they will always be running then +you can disable Samba from taking part in browser elections and +ever becoming a local master browser by setting following options +in the [global] section of the smb.conf file :

    So you might like to try "read raw = no" and see what happens on your -network. It might lower, raise or not affect your performance. Only -testing can really tell.

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

    20.7. Write raw18.8. Forcing samba to be the master

    The "write raw" operation is designed to be an optimised, low-latency -file write operation. A server may choose to not support it, -however. and Samba makes support for "write raw" optional, with it -being enabled by default.

    Who becomes the "master browser" is determined by an election process +using broadcasts. Each election packet contains a number of parameters +which determine what precedence (bias) a host should have in the +election. By default Samba uses a very low precedence and thus loses +elections to just about anyone else.

    Some machines may find "write raw" slower than normal write, in which -case you may wish to change this option.

    20.8. Slow Clients

    If you want Samba to win elections then just set the "os level" global +option in smb.conf to a higher number. It defaults to 0. Using 34 +would make it win all elections over every other system (except other +samba systems!)

    One person has reported that setting the protocol to COREPLUS rather -than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).

    A "os level" of 2 would make it beat WfWg and Win95, but not MS Windows +NT/2K Server. A MS Windows NT/2K Server domain controller uses level 32.

    I suspect that his PC's (386sx16 based) were asking for more data than -they could chew. I suspect a similar speed could be had by setting -"read raw = no" and "max xmit = 2048", instead of changing the -protocol. Lowering the "read size" might also help.

    20.9. Slow Logins

    The maximum os level is 255

    Slow logins are almost always due to the password checking time. Using -the lowest practical "password level" will improve things a lot. You -could also enable the "UFC crypt" option in the Makefile.

    If you want samba to force an election on startup, then set the +"preferred master" global option in smb.conf to "yes". Samba will +then have a slight advantage over other potential master browsers +that are not preferred master browsers. Use this parameter with +care, as if you have two hosts (whether they are windows 95 or NT or +samba) on the same local subnet both set with "preferred master" to +"yes", then periodically and continually they will force an election +in order to become the local master browser.

    If you want samba to be a "domain master browser", then it is +recommended that you also set "preferred master" to "yes", because +samba will not become a domain master browser for the whole of your +LAN or WAN if it is not also a local master browser on its own +broadcast isolated subnet.

    It is possible to configure two samba servers to attempt to become +the domain master browser for a domain. The first server that comes +up will be the domain master browser. All other samba servers will +attempt to become the domain master browser every 5 minutes. They +will find that another samba server is already the domain master +browser and will fail. This provides automatic redundancy, should +the current domain master browser fail.

    20.10. Client tuning18.9. Making samba the domain master

    Often a speed problem can be traced to the client. The client (for -example Windows for Workgroups) can often be tuned for better TCP -performance.

    See your client docs for details. In particular, I have heard rumours -that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a -large impact on performance.

    Also note that some people have found that setting DefaultRcvWindow in -the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a -big improvement. I don't know why.

    My own experience wth DefaultRcvWindow is that I get much better -performance with a large value (16384 or larger). Other people have -reported that anything over 3072 slows things down enourmously. One -person even reported a speed drop of a factor of 30 when he went from -3072 to 8192. I don't know why.

    The domain master is responsible for collating the browse lists of +multiple subnets so that browsing can occur between subnets. You can +make samba act as the domain master by setting "domain master = yes" +in smb.conf. By default it will not be a domain master.

    It probably depends a lot on your hardware, and the type of unix box -you have at the other end of the link.

    Note that you should NOT set Samba to be the domain master for a +workgroup that has the same name as an NT Domain.

    Paul Cochrane has done some testing on client side tuning and come -to the following conclusions:

    When samba is the domain master and the master browser it will listen +for master announcements (made roughly every twelve minutes) from local +master browsers on other subnets and then contact them to synchronise +browse lists.

    Install the W2setup.exe file from www.microsoft.com. This is an -update for the winsock stack and utilities which improve performance.

    If you want samba to be the domain master then I suggest you also set +the "os level" high enough to make sure it wins elections, and set +"preferred master" to "yes", to get samba to force an election on +startup.

    Configure the win95 TCPIP registry settings to give better -perfomance. I use a program called MTUSPEED.exe which I got off the -net. There are various other utilities of this type freely available. -The setting which give the best performance for me are:

    Note that all your servers (including samba) and clients should be +using a WINS server to resolve NetBIOS names. If your clients are only +using broadcasting to resolve NetBIOS names, then two things will occur:

    1. MaxMTU Remove

    2. RWIN Remove

      your local master browsers will be unable to find a domain master + browser, as it will only be looking on the local subnet. +

    3. MTUAutoDiscover Disable

      if a client happens to get hold of a domain-wide browse list, and + a user attempts to access a host in that list, it will be unable to + resolve the NetBIOS name of that host. +

    MTUBlackHoleDetect Disable

  • If, however, both samba and your clients are using a WINS server, then:

    Time To Live Enabled

    1. Time To Live - HOPS 32

      your local master browsers will contact the WINS server and, as long as + samba has registered that it is a domain master browser with the WINS + server, your local master browser will receive samba's ip address + as its domain master browser. +

    2. NDI Cache Size 0

    I tried virtually all of the items mentioned in the document and -the only one which made a difference to me was the socket options. It -turned out I was better off without any!!!!!

    In terms of overall speed of transfer, between various win95 clients -and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE -drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.

    The figures are:          Put              Get 
-P166 client 3Com card:    420-440kB/s      500-520kB/s
-P100 client 3Com card:    390-410kB/s      490-510kB/s
-DX4-75 client NE2000:     370-380kB/s      330-350kB/s

    I based these test on transfer two files a 4.5MB text file and a 15MB -textfile. The results arn't bad considering the hardware Samba is -running on. It's a crap machine!!!!

    The updates mentioned in 1 and 2 brought up the transfer rates from -just over 100kB/s in some clients.

    when a client receives a domain-wide browse list, and a user attempts + to access a host in that list, it will contact the WINS server to + resolve the NetBIOS name of that host. as long as that host has + registered its NetBIOS name with the same WINS server, the user will + be able to see that host. +

    18.10. Note about broadcast addresses

    A new client is a P333 connected via a 100MB/s card and hub. The -transfer rates from this were good: 450-500kB/s on put and 600+kB/s -on get.

    If your network uses a "0" based broadcast address (for example if it +ends in a 0) then you will strike problems. Windows for Workgroups +does not seem to support a 0's broadcast and you will probably find +that browsing and name lookups won't work.

    18.11. Multiple interfaces

    Looking at standard FTP throughput, Samba is a bit slower (100kB/s -upwards). I suppose there is more going on in the samba protocol, but -if it could get up to the rate of FTP the perfomance would be quite -staggering.

    Samba now supports machines with multiple network interfaces. If you +have multiple interfaces then you will need to use the "interfaces" +option in smb.conf to configure them. See smb.conf(5) for details.

    Chapter 21. Creating Group Prolicy Files

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

    21.1. Windows '9x19.1. Instructions

    You need the Win98 Group Policy Editor to -set Group Profiles up under Windows '9x. It can be found on the Original -full product Win98 installation CD under -tools/reskit/netadmin/poledit. You install this -using the Add/Remove Programs facility and then click on the 'Have Disk' -tab.

    The Distributed File System (or Dfs) provides a means of + separating the logical view of files and directories that users + see from the actual physical locations of these resources on the + network. It allows for higher availability, smoother storage expansion, + load balancing etc. For more information about Dfs, refer to Microsoft documentation.

    Use the Group Policy Editor to create a policy file that specifies the -location of user profiles and/or the This document explains how to host a Dfs tree on a Unix + machine (for Dfs-aware clients to browse) using Samba.

    To enable SMB-based DFS for Samba, configure it with the + --with-msdfs option. Once built, a + Samba server can be made a Dfs server by setting the global + boolean host msdfs parameter in the My Documents etc. -stuff. You then save these settings in a file called -smb.conf + file. You designate a share as a Dfs root using the share + level boolean msdfs root parameter. A Dfs root directory on + Samba hosts Dfs links in the form of symbolic links that point + to other servers. For example, a symbolic link + Config.POL that needs to be placed in -the root of the [NETLOGON] share. If your Win98 is configured to log onto -the Samba Domain, it will automatically read this file and update the -Win9x/Me registry of the machine that is logging on.

    All of this is covered in the Win98 Resource Kit documentation.

    If you do not do it this way, then every so often Win9x/Me will check the -integrity of the registry and will restore it's settings from the back-up -copy of the registry it stores on each Win9x/Me machine. Hence, you will -occasionally notice things changing back to the original settings.

    The following all refers to Windows NT/200x profile migration - not to policies. -We need a separate section on policies (NTConfig.Pol) for NT4/200x.

    21.2. Windows NT 4

    junction->msdfs:storage1\share1 in + the share directory acts as the Dfs junction. When Dfs-aware + clients attempt to access the junction link, they are redirected + to the storage location (in this case, \\storage1\share1).

    Unfortunately, the Resource Kit info is Win NT4 or 200x specific.

    Dfs trees on Samba work with all Dfs-aware clients ranging + from Windows 95 to 2000.

    Here is a quick guide:

    Here's an example of setting up a Dfs tree on a Samba + server.

    # The smb.conf file:
+[global]
+	netbios name = SAMBA
+	host msdfs   = yes
+
+[dfs]
+	path = /export/dfsroot
+	msdfs root = yes
+

    • On your NT4 Domain Controller, right click on 'My Computer', then -select the tab labelled 'User Profiles'.

    • Select a user profile you want to migrate and click on it.

      In the /export/dfsroot directory we set up our dfs links to + other servers on the network.

      root# cd /export/dfsroot

      I am using the term "migrate" lossely. You can copy a profile to -create a group profile. You can give the user 'Everyone' rights to the -profile you copy this to. That is what you need to do, since your samba -domain is not a member of a trust relationship with your NT4 PDC.

    • Click the 'Copy To' button.

    • In the box labelled 'Copy Profile to' add your new path, eg: -c:\temp\foobarroot# chown root /export/dfsroot

    • Click on the button labelled 'Change' in the "Permitted to use" box.

    • Click on the group 'Everyone' and then click OK. This closes the -'chose user' box.

    • Now click OK.

    Follow the above for every profile you need to migrate.

    21.2.1. Side bar Notes

    root# chmod 755 /export/dfsroot

    You should obtain the SID of your NT4 domain. You can use smbpasswd to do -this. Read the man page.

    root# ln -s msdfs:storageA\\shareA linka

    With Samba-3.0.0 alpha code you can import all you NT4 domain accounts -using the net samsync method. This way you can retain your profile -settings as well as all your users.

    21.2.2. Mandatory profiles

    root# ln -s msdfs:serverB\\share,serverC\\share linkb

    The above method can be used to create mandatory profiles also. To convert -a group profile into a mandatory profile simply locate the NTUser.DAT file -in the copied profile and rename it to NTUser.MAN.

    21.2.3. moveuser.exe

    You should set up the permissions and ownership of + the directory acting as the Dfs root such that only designated + users can create, delete or modify the msdfs links. Also note + that symlink names should be all lowercase. This limitation exists + to have Samba avoid trying all the case combinations to get at + the link name. Finally set up the symbolic links to point to the + network shares you want, and start Samba.

    The W2K professional resource kit has moveuser.exe. moveuser.exe changes -the security of a profile from one user to another. This allows the account -domain to change, and/or the user name to change.

    Users on Dfs-aware clients can now browse the Dfs tree + on the Samba server at \\samba\dfs. Accessing + links linka or linkb (which appear as directories to the client) + takes users directly to the appropriate shares on the network.

    21.2.4. Get SID19.1.1. Notes

    You can identify the SID by using GetSID.exe from the Windows NT Server 4.0 -Resource Kit.

    Windows NT 4.0 stores the local profile information in the registry under -the following key: -HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

    Under the ProfileList key, there will be subkeys named with the SIDs of the -users who have logged on to this computer. (To find the profile information -for the user whose locally cached profile you want to move, find the SID for -the user with the GetSID.exe utility.) Inside of the appropriate user's -subkey, you will see a string value named ProfileImagePath.

    21.3. Windows 2000/XP

    You must first convert the profile from a local profile to a domain -profile on the MS Windows workstation as follows:

    • Log on as the LOCAL workstation administrator.

      Windows clients need to be rebooted + if a previously mounted non-dfs share is made a dfs + root or vice versa. A better way is to introduce a + new share and make it the dfs root.

    • Right click on the 'My Computer' Icon, select 'Properties'

      Currently there's a restriction that msdfs + symlink names should all be lowercase.

    • Click on the 'User Profiles' tab

      For security purposes, the directory + acting as the root of the Dfs tree should have ownership + and permissions set so that only designated users can + modify the symbolic links in the directory.

    Chapter 20. Stackable VFS modules

    20.1. Introduction and configuration

    Select the profile you wish to convert (click on it once)

  • Since samba 3.0, samba supports stackable VFS(Virtual File System) modules. +Samba passes each request to access the unix file system thru the loaded VFS modules. +This chapter covers all the modules that come with the samba source and references to +some external modules.

    Click on the button 'Copy To'

  • You may have problems to compile these modules, as shared libraries are +compiled and linked in different ways on different systems. +They currently have been tested against GNU/linux and IRIX.

    In the "Permitted to use" box, click on the 'Change' button.

  • To use the VFS modules, create a share similar to the one below. The +important parameter is the vfs object parameter which must point to +the exact pathname of the shared library objects. For example, to log all access +to files and use a recycle bin: + +
           [audit]
+                comment = Audited /data directory
+                path = /data
+                vfs object = /path/to/audit.so /path/to/recycle.so
+                writeable = yes
+                browseable = yes

    Click on the 'Look in" area that lists the machine name, when you click -here it will open up a selection box. Click on the domain to which the -profile must be accessible.

    The modules are used in the order they are specified.

    Further documentation on writing VFS modules for Samba can be found in +the Samba Developers Guide.

    • 20.2. Included modules

    20.2.1. audit

    A simple module to audit file access to the syslog +facility. The following operations are logged: +

    shareconnect/disconnect

    You will need to log on if a logon box opens up. Eg: In the connect -as: MIDEARTH\root, password: mypassword.

    directory opens/create/remove
    file open/close/rename/unlink/chmod

  • 20.2.2. recycle

    To make the profile capable of being used by anyone select 'Everyone'

  • A recycle-bin like modules. When used any unlink call +will be intercepted and files moved to the recycle +directory instead of beeing deleted.

    Click OK. The Selection box will close.

  • Supported options: +

    vfs_recycle_bin:repository

    Now click on the 'Ok' button to create the profile in the path you -nominated.

    • FIXME

    vfs_recycle_bin:keeptree

    Done. You now have a profile that can be editted using the samba-3.0.0 -profiles tool.

    FIXME

    vfs_recycle_bin:versions

    FIXME

    vfs_recycle_bin:touch

    Under NT/2K the use of mandotory profiles forces the use of MS Exchange -storage of mail data. That keeps desktop profiles usable.

    FIXME

    vfs_recycle_bin:maxsize

    FIXME

    vfs_recycle_bin:exclude

    FIXME

    vfs_recycle_bin:exclude_dir

    FIXME

    vfs_recycle_bin:noversions

    FIXME

    20.2.3. netatalk

    A netatalk module, that will ease co-existence of samba and +netatalk file sharing services.

    Advantages compared to the old netatalk module: +

    it doesn't care about creating of .AppleDouble forks, just keeps ones in sync
    if share in smb.conf doesn't contain .AppleDouble item in hide or veto list, it will be added automatically

    • This is a security check new to Windows XP (or maybe only -Windows XP service pack 1). It can be disabled via a group policy in -Active Directory. The policy is:

      "Computer Configuration\Administrative Templates\System\User -Profiles\Do not check for user ownership of Roaming Profile Folders"

      ...and it should be set to "Enabled". -Does the new version of samba have an Active Directory analogue? If so, -then you may be able to set the policy through this.

      If you cannot set group policies in samba, then you may be able to set -the policy locally on each machine. If you want to try this, then do -the following (N.B. I don't know for sure that this will work in the -same way as a domain group policy):

    • On the XP workstation log in with an Administrator account.

    • Click: "Start", "Run"

    • Type: "mmc"

    • Click: "OK"

    • A Microsoft Management Console should appear.

    • Click: File, "Add/Remove Snap-in...", "Add"

    • Double-Click: "Group Policy"

    • Click: "Finish", "Close"

    • Click: "OK"

    • In the "Console Root" window:

    20.3. VFS modules available elsewhere

    Expand: "Local Computer Policy", "Computer Configuration",

  • This section contains a listing of various other VFS modules that +have been posted but don't currently reside in the Samba CVS +tree for one reason ot another (e.g. it is easy for the maintainer +to have his or her own CVS tree).

    "Administrative Templates", "System", "User Profiles"

  • No statemets about the stability or functionality any module +should be implied due to its presence here.

    20.3.1. DatabaseFS

    Double-Click: "Do not check for user ownership of Roaming Profile

  • URL: http://www.css.tayloru.edu/~elorimer/databasefs/index.php

    Folders"

  • By Eric Lorimer.

    Select: "Enabled"

  • I have created a VFS module which implements a fairly complete read-only +filesystem. It presents information from a database as a filesystem in +a modular and generic way to allow different databases to be used +(originally designed for organizing MP3s under directories such as +"Artists," "Song Keywords," etc... I have since applied it to a student +roster database very easily). The directory structure is stored in the +database itself and the module makes no assumptions about the database +structure beyond the table it requires to run.

    Click: OK"

  • Any feedback would be appreciated: comments, suggestions, patches, +etc... If nothing else, hopefully it might prove useful for someone +else who wishes to create a virtual filesystem.

    • 20.3.2. vscan

    Close the whole console. You do not need to save the settings (this -refers to the console settings rather than the policies you have -changed).

  • URL: http://www.openantivirus.org/

    Reboot

    • samba-vscan is a proof-of-concept module for Samba, which +uses the VFS (virtual file system) features of Samba 2.2.x/3.0 +alphaX. Of couse, Samba has to be compiled with VFS support. +samba-vscan supports various virus scanners and is maintained +by Rainer Link.

    Chapter 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 @@ -17123,8 +16501,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 @@ -17155,8 +16533,8 @@ CLASS="SECT1" >

    22.3. Using interface protection21.3. Using interface protection

    By default Samba will accept connections on any network interface that @@ -17191,8 +16569,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 @@ -17221,8 +16599,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 @@ -17260,8 +16638,8 @@ CLASS="SECT1" >

    22.6. Upgrading Samba21.6. Upgrading Samba

    Please check regularly on http://www.samba.org/ for updates and @@ -17276,14 +16654,14 @@ CLASS="CHAPTER" >Chapter 23. Unicode/CharsetsChapter 22. Unicode/Charsets

    23.1. What are charsets and unicode?22.1. What are charsets and unicode?

    Computers communicate in numbers. In texts, each number will be @@ -17332,8 +16710,8 @@ CLASS="SECT1" >

    23.2. Samba and charsets22.2. Samba and charsets

    As of samba 3.0, samba can (and will) talk unicode over the wire. Internally, @@ -17408,6 +16786,65 @@ CLASS="TOC" >Table 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?

    Chapter 23. Samba performance issues

    23.1. Comparisons

    The Samba server uses TCP to talk to the client. Thus if you are +trying to see if it performs well you should really compare it to +programs that use the same protocol. The most readily available +programs for file transfer that use TCP are ftp or another TCP based +SMB server.

    If you want to test against something like a NT or WfWg server then +you will have to disable all but TCP on either the client or +server. Otherwise you may well be using a totally different protocol +(such as Netbeui) and comparisons may not be valid.

    Generally you should find that Samba performs similarly to ftp at raw +transfer speed. It should perform quite a bit faster than NFS, +although this very much depends on your system.

    Several people have done comparisons between Samba and Novell, NFS or +WinNT. In some cases Samba performed the best, in others the worst. I +suspect the biggest factor is not Samba vs some other system but the +hardware and drivers used on the various systems. Given similar +hardware Samba should certainly be competitive in speed with other +systems.

    23.2. Socket options

    There are a number of socket options that can greatly affect the +performance of a TCP based server like Samba.

    The socket options that Samba uses are settable both on the command +line with the -O option, or in the smb.conf file.

    The "socket options" section of the smb.conf manual page describes how +to set these and gives recommendations.

    Getting the socket options right can make a big difference to your +performance, but getting them wrong can degrade it by just as +much. The correct settings are very dependent on your local network.

    The socket option TCP_NODELAY is the one that seems to make the +biggest single difference for most networks. Many people report that +adding "socket options = TCP_NODELAY" doubles the read performance of +a Samba drive. The best explanation I have seen for this is that the +Microsoft TCP/IP stack is slow in sending tcp ACKs.

    23.3. Read size

    The option "read size" affects the overlap of disk reads/writes with +network reads/writes. If the amount of data being transferred in +several of the SMB commands (currently SMBwrite, SMBwriteX and +SMBreadbraw) is larger than this value then the server begins writing +the data before it has received the whole packet from the network, or +in the case of SMBreadbraw, it begins writing to the network before +all the data has been read from disk.

    This overlapping works best when the speeds of disk and network access +are similar, having very little effect when the speed of one is much +greater than the other.

    The default value is 16384, but very little experimentation has been +done yet to determine the optimal value, and it is likely that the best +value will vary greatly between systems anyway. A value over 65536 is +pointless and will cause you to allocate memory unnecessarily.

    23.4. Max xmit

    At startup the client and server negotiate a "maximum transmit" size, +which limits the size of nearly all SMB commands. You can set the +maximum size that Samba will negotiate using the "max xmit = " option +in smb.conf. Note that this is the maximum size of SMB request that +Samba will accept, but not the maximum size that the *client* will accept. +The client maximum receive size is sent to Samba by the client and Samba +honours this limit.

    It defaults to 65536 bytes (the maximum), but it is possible that some +clients may perform better with a smaller transmit unit. Trying values +of less than 2048 is likely to cause severe problems.

    In most cases the default is the best option.

    23.5. Log level

    If you set the log level (also known as "debug level") higher than 2 +then you may suffer a large drop in performance. This is because the +server flushes the log file after each operation, which can be very +expensive.

    23.6. Read raw

    The "read raw" operation is designed to be an optimised, low-latency +file read operation. A server may choose to not support it, +however. and Samba makes support for "read raw" optional, with it +being enabled by default.

    In some cases clients don't handle "read raw" very well and actually +get lower performance using it than they get using the conventional +read operations.

    So you might like to try "read raw = no" and see what happens on your +network. It might lower, raise or not affect your performance. Only +testing can really tell.

    23.7. Write raw

    The "write raw" operation is designed to be an optimised, low-latency +file write operation. A server may choose to not support it, +however. and Samba makes support for "write raw" optional, with it +being enabled by default.

    Some machines may find "write raw" slower than normal write, in which +case you may wish to change this option.

    23.8. Slow Clients

    One person has reported that setting the protocol to COREPLUS rather +than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).

    I suspect that his PC's (386sx16 based) were asking for more data than +they could chew. I suspect a similar speed could be had by setting +"read raw = no" and "max xmit = 2048", instead of changing the +protocol. Lowering the "read size" might also help.

    23.9. Slow Logins

    Slow logins are almost always due to the password checking time. Using +the lowest practical "password level" will improve things a lot. You +could also enable the "UFC crypt" option in the Makefile.

    23.10. Client tuning

    Often a speed problem can be traced to the client. The client (for +example Windows for Workgroups) can often be tuned for better TCP +performance.

    See your client docs for details. In particular, I have heard rumours +that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a +large impact on performance.

    Also note that some people have found that setting DefaultRcvWindow in +the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a +big improvement. I don't know why.

    My own experience wth DefaultRcvWindow is that I get much better +performance with a large value (16384 or larger). Other people have +reported that anything over 3072 slows things down enourmously. One +person even reported a speed drop of a factor of 30 when he went from +3072 to 8192. I don't know why.

    It probably depends a lot on your hardware, and the type of unix box +you have at the other end of the link.

    Paul Cochrane has done some testing on client side tuning and come +to the following conclusions:

    Install the W2setup.exe file from www.microsoft.com. This is an +update for the winsock stack and utilities which improve performance.

    Configure the win95 TCPIP registry settings to give better +perfomance. I use a program called MTUSPEED.exe which I got off the +net. There are various other utilities of this type freely available. +The setting which give the best performance for me are:

    1. MaxMTU Remove

    2. RWIN Remove

    3. MTUAutoDiscover Disable

    4. MTUBlackHoleDetect Disable

    5. Time To Live Enabled

    6. Time To Live - HOPS 32

    7. NDI Cache Size 0

    I tried virtually all of the items mentioned in the document and +the only one which made a difference to me was the socket options. It +turned out I was better off without any!!!!!

    In terms of overall speed of transfer, between various win95 clients +and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE +drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.

    The figures are:          Put              Get 
+P166 client 3Com card:    420-440kB/s      500-520kB/s
+P100 client 3Com card:    390-410kB/s      490-510kB/s
+DX4-75 client NE2000:     370-380kB/s      330-350kB/s

    I based these test on transfer two files a 4.5MB text file and a 15MB +textfile. The results arn't bad considering the hardware Samba is +running on. It's a crap machine!!!!

    The updates mentioned in 1 and 2 brought up the transfer rates from +just over 100kB/s in some clients.

    A new client is a P333 connected via a 100MB/s card and hub. The +transfer rates from this were good: 450-500kB/s on put and 600+kB/s +on get.

    Looking at standard FTP throughput, Samba is a bit slower (100kB/s +upwards). I suppose there is more going on in the samba protocol, but +if it could get up to the rate of FTP the perfomance would be quite +staggering.

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

    26.3.1. Compiling samba with Active Directory support

    26.3.1.1. Installing the required packages for Debian

    26.3.1.2. Installing the required packages for RedHat

    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?