From d164bb1772e6c4b1761bea86dc4b8f0940764995 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sat, 5 Apr 2003 23:39:01 +0000 Subject: Update for other contributors to. (This used to be commit d12a1bb8260673a5c280960b21957e68b241e540) --- docs/htmldocs/Samba-HOWTO-Collection.html | 10800 +++++++++++++++++----------- 1 file changed, 6643 insertions(+), 4157 deletions(-) (limited to 'docs/htmldocs') diff --git a/docs/htmldocs/Samba-HOWTO-Collection.html b/docs/htmldocs/Samba-HOWTO-Collection.html index 73bc3eb60a..9b79518cec 100644 --- a/docs/htmldocs/Samba-HOWTO-Collection.html +++ b/docs/htmldocs/Samba-HOWTO-Collection.html @@ -32,20 +32,41 @@ CLASS="AUTHOR" NAME="AEN4" >SAMBA Team

<samba@samba.org>

Edited by

John H Terpstra

Jelmer Vernooij

Gerald (Jerry) Carter

Abstract

Last Update : Wed Jan 15

This book is a collection of HOWTOs added to Samba documentation over the years. I try to ensure that all are current, but sometimes the is a larger job @@ -66,6 +87,17 @@ TARGET="_top" >jelmer@samba.org.

This documentation is distributed under the GNU General Public License (GPL) version 2. A copy of the license is included with the Samba source distribution. A copy can be found on-line at http://www.fsf.org/licenses/gpl.txt

Cheers, jerry

1.1. Obtaining and installing samba
1.2. Configuring samba
1.3. Try listing the shares available on your server
1.4. Try connecting with the unix client
1.5. Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client
1.6. What If Things Don't Work?
2.1. Discussion
2.2. How browsing functions and how to deploy stable and dependable browsing using Samba
2.3. Use of the "Remote Announce" parameterUse of the Remote Announce parameter
2.4. Use of the "Remote Browse Sync" parameterUse of the Remote Browse Sync parameter
2.5. Use 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. XML
4.1. Stand Alone Server
4.2. Domain Member Server
4.3. Domain Controller
5.1. User and Share security level
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. What other help can I get?
6.7. Domain Control for Windows 9x/ME
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?
10. Advanced Network Manangement Information
10.1. Remote Server Administration
11. UNIX Permission Bits and Windows NT Access Control Lists
11.1. 10.1. Viewing and changing UNIX permissions using the NT security dialogs
11.2. 10.2. How to view file security on a Samba share
11.3. 10.3. Viewing file ownership
11.4. 10.4. Viewing file or directory permissions
11.5. 10.5. Modifying file or directory permissions
11.6. 10.6. Interaction with the standard Samba create mask parameters
11.7. 10.7. Interaction with the standard Samba file attribute mapping
12. 11. Group mapping HOWTO
13. Configuring PAM for distributed but centrally -managed authenticationConfiguring Group Mapping
13.1. Samba and PAM
13.2. Distributed Authentication
13.3. PAM Configuration in smb.conf
14. 12. Printing Support
14.1. 12.1. Introduction
14.2. 12.2. Configuration
14.3. 12.3. The Imprints Toolset
14.4. 12.4. Diagnosis
15. 13. CUPS Printing Support
15.1. 13.1. Introduction
15.2. CUPS - RAW Print Through Mode13.2. Configuring smb.conf for CUPS
15.3. The CUPS Filter Chains13.3. CUPS - RAW Print Through Mode
15.4. 13.4. CUPS as a network PostScript RIP -- CUPS drivers working on server, Adobe +PostScript driver with CUPS-PPDs downloaded to clients
13.5. Windows Terminal Servers (WTS) as CUPS clients
13.6. Setting up CUPS for driver download
13.7. Sources of CUPS drivers / PPDs
13.8. The CUPS Filter Chains
13.9. CUPS Print Drivers and Devices
15.5. 13.10. Limiting the number of pages users can print
15.6. 13.11. Advanced Postscript Printing from MS Windows
15.7. 13.12. Auto-Deletion of CUPS spool files
16. 14. Unified Logons between Windows NT and UNIX using Winbind
16.1. 14.1. Abstract
16.2. 14.2. Introduction
16.3. 14.3. What Winbind Provides
16.4. 14.4. How Winbind Works
16.5. 14.5. Installation and Configuration
16.6. 14.6. Limitations
16.7. 14.7. Conclusion
17. Policy Management - Hows and Whys15. Advanced Network Manangement
17.1. System Policies15.1. Configuring Samba Share Access Controls
18. Profile Management15.2. Remote Server Administration
18.1. Roaming Profiles15.3. Network Logon Script Magic
19. Integrating MS Windows networks with Samba16. System and Account Policies
19.1. Name Resolution in a pure Unix/Linux world16.1. Creating and Managing System Policies
19.2. Name resolution as used within MS Windows networking16.2. Managing Account/User Policies
20. Improved browsing in samba17. Desktop Profile Management
20.1. Overview of browsing17.1. Roaming Profiles
20.2. Browsing support in samba17.2. Mandatory profiles
20.3. Problem resolution17.3. Creating/Managing Group Profiles
20.4. Browsing across subnets17.4. Default Profile for Windows Users
20.5. Setting up a WINS server18. PAM Configuration for Centrally Managed Authentication
20.6. Setting up Browsing in a WORKGROUP18.1. Samba and PAM
20.7. Setting up Browsing in a DOMAIN18.2. Distributed Authentication
20.8. Forcing samba to be the master18.3. PAM Configuration in smb.conf
20.9. Making samba the domain master19. Stackable VFS modules
20.10. Note about broadcast addresses19.1. Introduction and configuration
20.11. Multiple interfaces19.2. Included modules
19.3. VFS modules available elsewhere
21. 20. Hosting a Microsoft Distributed File System tree on Samba
21.1. 20.1. Instructions
21. Integrating MS Windows networks with Samba
21.1. Name Resolution in a pure Unix/Linux world
21.2. Name resolution as used within MS Windows networking
22. Stackable VFS modulesImproved browsing in samba
22.1. Introduction and configurationOverview of browsing
22.2. Included modulesBrowsing support in samba
22.3. VFS modules available elsewhereProblem resolution
22.4. Browsing across subnets
22.5. Setting up a WINS server
22.6. Setting up Browsing in a WORKGROUP
22.7. Setting up Browsing in a DOMAIN
22.8. Forcing samba to be the master
22.9. Making samba the domain master
22.10. Note about broadcast addresses
22.11. Multiple interfaces
23.1. Introduction
23.2. Using host based protection
23.3. Using interface protection
23.4. Using a firewall
23.5. Using a IPC$ share deny
23.6. Upgrading Samba
24.1. What are charsets and unicode?
24.2. Samba and charsets
25. Samba performance issuesSWAT - The Samba Web Admininistration Tool
25.1. ComparisonsSWAT Features and Benefits
25.2. Socket options26. Migration from NT4 PDC to Samba-3 PDC
25.3. Read size26.1. Planning and Getting Started
25.4. Max xmit26.2. Managing Samba-3 Domain Control
27. Samba performance issues
27.1. Comparisons
27.2. Socket options
27.3. Read size
27.4. Max xmit
25.5. 27.5. Log level
25.6. 27.6. Read raw
25.7. 27.7. Write raw
25.8. 27.8. Slow Clients
25.9. 27.9. Slow Logins
25.10. 27.10. Client tuning
26. 28. Portability
26.1. 28.1. HPUX
26.2. 28.2. SCO Unix
26.3. 28.3. DNIX
26.4. 28.4. RedHat Linux Rembrandt-II
26.5. 28.5. AIX
27. 29. Samba and other CIFS clients
27.1. 29.1. Macintosh clients?
27.2. 29.2. OS2 Client
27.3. 29.3. Windows for Workgroups
27.4. 29.4. Windows '95/'98
27.5. 29.5. Windows 2000 Service Pack 2
29.6. Windows NT 3.1
28. 30. How to compile SAMBA
28.1. 30.1. Access Samba source code via CVS
28.2. 30.2. Accessing the samba sources via rsync and ftp
28.3. 30.3. Building the Binaries
28.4. 30.4. Starting the smbd and nmbd
29. 31. Reporting Bugs
29.1. 31.1. Introduction
29.2. 31.2. General info
29.3. 31.3. Debug levels
29.4. 31.4. Internal errors
29.5. 31.5. Attaching to a running process
29.6. 31.6. Patches
30. 32. The samba checklist
30.1. 32.1. Introduction
30.2. 32.2. Assumptions
30.3. Tests32.3. The tests
30.4. 32.4. Still having troubles?

Introduction

1.1. Obtaining and installing samba
1.2. Configuring samba
1.2.1. Editing the smb.conf file
1.2.2. SWAT
1.3. Try listing the shares available on your server
1.4. Try connecting with the unix client
1.5. Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client
1.6. What If Things Don't Work?
1.6.1. Scope IDs
1.6.2. Locking
2.1. Discussion
2.2. How browsing functions and how to deploy stable and dependable browsing using Samba
2.3. Use of the "Remote Announce" parameterUse of the Remote Announce parameter
2.4. Use of the "Remote Browse Sync" parameterUse of the Remote Browse Sync parameter
2.5. Use 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. Creating the database
3.7.2. Configuring
3.7.3. Using plaintext passwords or encrypted password
3.7.4. Getting non-column data from the table
3.8. XML

1.1. Obtaining and installing samba

1.2. Configuring samba

1.2.1. Editing the smb.conf file

1.2.1.1. Test your config file with

1.2.2. SWAT

1.3. Try listing the shares available on your server

1.4. Try connecting with the unix client

1.5. Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client

1.6. What If Things Don't Work?

1.6.1. Scope IDs

1.6.2. Locking

Note: MS Windows 2000 and later can be configured to operate with NO NetBIOS +>MS Windows 2000 and later can be configured to operate with NO NetBIOS over TCP/IP. Samba-3 and later also supports this mode of operation.

2.1. Discussion

Normally, only unicast UDP messaging can be forwarded by routers. The -"remote announce" parameter to smb.conf helps to project browse announcements -to remote network segments via unicast UDP. Similarly, the "remote browse sync" -parameter of smb.conf implements browse list collation using unicast UDP.

remote announce +parameter to smb.conf helps to project browse announcements +to remote network segments via unicast UDP. Similarly, the +remote browse sync parameter of smb.conf +implements browse list collation using unicast UDP.

Secondly, in those networks where Samba is the only SMB server technology wherever possible nmbd should be configured on one (1) machine as the WINS server. This makes it easy to manage the browsing environment. If each network segment is configured with it's own Samba WINS server, then the only way to -get cross segment browsing to work is by using the "remote announce" and -the "remote browse sync" parameters to your smb.conf file.

remote announce and the remote browse sync +parameters to your smb.conf file.

If only one WINS server is used for an entire multi-segment network then -the use of the "remote announce" and the "remote browse sync" parameters -should NOT be necessary.

remote announce and the +remote browse sync parameters should NOT be necessary.

As of Samba-3 WINS replication is being worked on. The bulk of the code has +>As of Samba 3 WINS replication is being worked on. The bulk of the code has been committed, but it still needs maturation.

Right now samba WINS does not support MS-WINS replication. This means that when setting up Samba as a WINS server there must only be one nmbd configured as a WINS server on the network. Some sites have used multiple Samba WINS -servers for redundancy (one server per subnet) and then used "remote browse -sync" and "remote announce" to affect browse list collation across all +servers for redundancy (one server per subnet) and then used +remote browse sync and remote announce +to affect browse list collation across all segments. Note that this means clients will only resolve local names, and must be configured to use DNS to resolve names on other subnets in order to resolve the IP addresses of the servers they can see on other @@ -1828,7 +2028,7 @@ CLASS="SECT1" >

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

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 @@ -1873,14 +2077,23 @@ 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 +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 +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. @@ -1895,21 +2108,40 @@ CLASS="SECT1" >

2.3. Use of the "Remote Announce" parameter2.3. Use of the Remote Announce parameter

The "remote announce" parameter of smb.conf can be used to forcibly ensure +>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: +The syntax of the remote announce parameter is: 

	remote announce = a.b.c.d [e.f.g.h] ...
remote announce = a.b.c.d [e.f.g.h] ... _or_ 
	remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ...
remote announce = a.b.c.d/WORKGROUP [e.f.g.h/WORKGROUP] ... where: @@ -1919,7 +2151,14 @@ where: CLASS="VARIABLELIST" >
a.b.c.d and e.f.g.h
a.b.c.d and +e.f.g.h

is either the LMB (Local Master Browser) IP address @@ -1934,7 +2173,10 @@ undesirable but may be necessary if we do NOT know the IP address of the remote LMB.

WORKGROUP
WORKGROUP

is optional and can be either our own workgroup @@ -1953,30 +2195,49 @@ CLASS="SECT1" >

2.4. 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 +>The remote browse sync parameter of +smb.conf is used to announce to another LMB that it must synchronise it's NetBIOS name list with our Samba LMB. It works ONLY if the Samba server that has this option is simultaneously the LMB on it's network segment.

The syntax of the "remote browse sync" parameter is: +>The syntax of the remote browse sync parameter is: 

remote browse sync = a.b.c.d
remote browse sync = a.b.c.d -where a.b.c.d is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.

a.b.c.d is either the IP address of the remote LMB or else is the network broadcast address of the remote segment.

2.5. Use of WINS

lmhosts files that must reside on all clients in the +absence of WINS.

WINS also serves the purpose of forcing browse list synchronisation by all LMB's. LMB's must synchronise their browse list with the DMB (domain master @@ -2018,8 +2283,15 @@ machines that have not registered with a WINS server will fail name to address lookup attempts by other clients and will therefore cause workstation access errors.

To configure Samba as a WINS server just add "wins support = yes" to the -smb.conf file [globals] section.

To configure Samba as a WINS server just add +wins support = yes to the smb.conf +file [globals] section.

To configure Samba to register with a WINS server just add "wins server = a.b.c.d" to your smb.conf file [globals] section.

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

Encrypted password support allows auto-matic share +>Encrypted password support allows automatic share (resource) reconnects.

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

samba-patches@samba.org and jerry@samba.org.

3.6.4. Schema and Relationship to the RFC 2307 posixAccount

jerry@samba.org

3.6.5. Configuring Samba with LDAP

3.6.5.1. OpenLDAP configuration

root# cp samba.schema /etc/openldap/schema/cp samba.schema /etc/openldap/schema/

Next, include the

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. Creating the database

3.7.2. Configuring

3.7.3. Using plaintext passwords or encrypted password

3.7.4. Getting non-column data from the table

3.8. XML

The usage of pdb_xml is pretty straightforward. To export data, use: -pdbedit -e xml:filenamepdbedit -e xml:filename (where filename is the name of the file to put the data in)

To import data, use: -pdbedit -i xml:filename -e current-pdbpdbedit -i xml:filename -e current-pdb Where filename is the name to read the data from and current-pdb to put it in.

Introduction

4.1. Stand Alone Server
4.2. Domain Member Server
4.3. Domain Controller
4.3.1. Domain Controller Types
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.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. What other help can I get?
6.7. Domain Control for Windows 9x/ME
6.7.1. Configuration Instructions: Network Logons
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

4.2. Domain Member Server

4.3. Domain Controller

4.3.1. Domain Controller Types

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.3.1. Configuring Samba for Seemless Windows Network Integration

5.1.3.2. Use MS Windows NT as an authentication server

5.1.4. Domain Level Security

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

5.1.5. ADS Level Security

6.1. Prerequisite Reading

6.2. Background

6.3. Configuring the Samba Domain Controller

Encrypted passwords must be enabled. For more details on how to do this, refer to ENCRYPTION.html.

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. What other help can I get?

6.7. Domain Control for Windows 9x/ME

6.7.1. Configuration Instructions: Network Logons

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 ads server = your.kerberos.server

You do *not* need a smbpasswd file, and older clients will - be authenticated as if "security = domain", although it won't do any harm + 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

The minimal configuration for krb5.conf is:

The minimal configuration for krb5.conf is:

Test your config by doing a "kinit USERNAME@REALM" and making sure that
+>Test your config by doing a kinit USERNAME@REALM and making sure that
   your password is accepted by the Win2000 KDC. 
NOTE: The realm must be uppercase. 
The realm must be uppercase. 
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
@@ -6560,13 +6894,28 @@ 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. 
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.
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
+straight to Test with smbclient now. 
+Creating a computer account 
+and testing your servers
+is only needed if you want kerberos
 support for smbd and winbindd.

8.3. Create the computer account

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

8.3.1. Possible errors

8.4. Test your server setup

On a Windows 2000 client try net use * \\server\shareOn 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 ticketsklist 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.

-k option to choose kerberos authentication.

8.6. Notes

9.1. Joining an NT Domain with Samba 3.0

9.2. Why is this better than security = server?

Introduction

10. Advanced Network Manangement Information
10.1. Remote Server Administration
11. UNIX Permission Bits and Windows NT Access Control Lists
11.1. 10.1. Viewing and changing UNIX permissions using the NT security dialogs
11.2. 10.2. How to view file security on a Samba share
11.3. 10.3. Viewing file ownership
11.4. 10.4. Viewing file or directory permissions
11.4.1. 10.4.1. File Permissions
11.4.2. 10.4.2. Directory Permissions
11.5. 10.5. Modifying file or directory permissions
11.6. 10.6. Interaction with the standard Samba create mask parameters
11.7. 10.7. Interaction with the standard Samba file attribute mapping
12. 11. Group mapping HOWTO
13. Configuring PAM for distributed but centrally -managed authentication
13.1. Samba and PAM
13.2. Distributed Authentication
13.3. PAM Configuration in smb.confConfiguring Group Mapping
14. 12. Printing Support
14.1. 12.1. Introduction
14.2. 12.2. Configuration
14.2.1. 12.2.1. Creating [print$]
14.2.2. 12.2.2. Setting Drivers for Existing Printers
14.2.3. 12.2.3. Support a large number of printers
14.2.4. 12.2.4. Adding New Printers via the Windows NT APW
14.2.5. 12.2.5. Samba and Printer Ports
14.3. 12.3. The Imprints Toolset
14.3.1. 12.3.1. What is Imprints?
14.3.2. 12.3.2. Creating Printer Driver Packages
14.3.3. 12.3.3. The Imprints server
14.3.4. 12.3.4. The Installation Client
14.4. 12.4. Diagnosis
14.4.1. 12.4.1. Introduction
14.4.2. 12.4.2. Debugging printer problems
14.4.3. 12.4.3. What printers do I have?
14.4.4. 12.4.4. Setting up printcap and print servers
14.4.5. 12.4.5. Job sent, no output
14.4.6. 12.4.6. Job sent, strange output
14.4.7. 12.4.7. Raw PostScript printed
14.4.8. 12.4.8. Advanced Printing
14.4.9. 12.4.9. Real debugging
15. 13. CUPS Printing Support
15.1. 13.1. Introduction
15.2. CUPS - RAW Print Through Mode13.2. Configuring smb.conf for CUPS
15.3. The CUPS Filter Chains13.3. CUPS - RAW Print Through Mode
15.4. 13.4. CUPS as a network PostScript RIP -- CUPS drivers working on server, Adobe +PostScript driver with CUPS-PPDs downloaded to clients
13.5. Windows Terminal Servers (WTS) as CUPS clients
13.6. Setting up CUPS for driver download
13.7. Sources of CUPS drivers / PPDs
13.7.1. cupsaddsmb
13.8. The CUPS Filter Chains
13.9. CUPS Print Drivers and Devices
15.4.1. 13.9.1. Further printing steps
15.5. 13.10. Limiting the number of pages users can print
15.6. 13.11. Advanced Postscript Printing from MS Windows
15.7. 13.12. Auto-Deletion of CUPS spool files
16. 14. Unified Logons between Windows NT and UNIX using Winbind
16.1. 14.1. Abstract
16.2. 14.2. Introduction
16.3. 14.3. What Winbind Provides
16.3.1. 14.3.1. Target Uses
16.4. 14.4. How Winbind Works
16.4.1. 14.4.1. Microsoft Remote Procedure Calls
16.4.2. 14.4.2. Microsoft Active Directory Services
16.4.3. 14.4.3. Name Service Switch
16.4.4. 14.4.4. Pluggable Authentication Modules
16.4.5. 14.4.5. User and Group ID Allocation
16.4.6. 14.4.6. Result Caching
16.5. 14.5. Installation and Configuration
16.5.1. 14.5.1. Introduction
16.5.2. 14.5.2. Requirements
16.5.3. 14.5.3. Testing Things Out
16.6. 14.6. Limitations
16.7. 14.7. Conclusion
17. Policy Management - Hows and Whys15. Advanced Network Manangement
17.1. System Policies15.1. Configuring Samba Share Access Controls
17.1.1. Creating and Managing Windows 9x/Me Policies15.1.1. Share Permissions Management
17.1.2. Creating and Managing Windows NT4 Style Policy Files15.2. Remote Server Administration
17.1.3. Creating and Managing MS Windows 200x Policies15.3. Network Logon Script Magic

18. Profile Management16. System and Account Policies
18.1. Roaming Profiles16.1. Creating and Managing System Policies
18.1.1. Windows NT Configuration
18.1.2. Windows 9X Configuration16.1.1. Windows 9x/Me Policies
18.1.3. Win9X and WinNT Configuration16.1.2. Windows NT4 Style Policy Files
18.1.4. Windows 9X Profile Setup
18.1.5. Windows NT Workstation 4.0
18.1.6. Windows NT/200x Server16.1.3. MS Windows 200x / XP Professional Policies
18.1.7. Sharing Profiles between W9x/Me and NT4/200x/XP workstations16.2. Managing Account/User Policies
18.1.8. Windows NT 416.2.1. With Windows NT4/200x
18.1.9. Windows 2000/XP16.2.2. With a Samba PDC
19. Integrating MS Windows networks with Samba17. Desktop Profile Management
19.1. Name Resolution in a pure Unix/Linux world17.1. Roaming Profiles
19.1.1. /etc/hosts17.1.1. Samba Configuration for Profile Handling
19.1.2. /etc/resolv.conf17.1.2. Windows Client Profile Configuration Information
19.1.3. /etc/host.conf17.1.3. Sharing Profiles between W9x/Me and NT4/200x/XP workstations
19.1.4. /etc/nsswitch.conf17.1.4. Profile Migration from Windows NT4/200x Server to Samba
19.2. Name resolution as used within MS Windows networking17.2. Mandatory profiles
19.2.1. The NetBIOS Name Cache17.3. Creating/Managing Group Profiles
19.2.2. The LMHOSTS file17.4. Default Profile for Windows Users
19.2.3. HOSTS file17.4.1. MS Windows 9x/Me
19.2.4. DNS Lookup17.4.2. MS Windows NT4 Workstation
19.2.5. WINS Lookup17.4.3. MS Windows 200x/XP
20. Improved browsing in samba18. PAM Configuration for Centrally Managed Authentication
20.1. Overview of browsing18.1. Samba and PAM
20.2. Browsing support in samba18.2. Distributed Authentication
20.3. Problem resolution18.3. PAM Configuration in smb.conf
20.4. Browsing across subnets19. Stackable VFS modules
20.4.1. How does cross subnet browsing work ?19.1. Introduction and configuration
20.5. Setting up a WINS server19.2. Included modules
20.6. Setting up Browsing in a WORKGROUP19.2.1. audit
20.7. Setting up Browsing in a DOMAIN19.2.2. extd_audit
20.8. Forcing samba to be the master19.2.3. recycle
20.9. Making samba the domain master19.2.4. netatalk
19.3. VFS modules available elsewhere
20.10. Note about broadcast addresses19.3.1. DatabaseFS
20.11. Multiple interfaces19.3.2. vscan
21. 20. Hosting a Microsoft Distributed File System tree on Samba
21.1. 20.1. Instructions
21.1.1. 20.1.1. Notes
22. Stackable VFS modules21. Integrating MS Windows networks with Samba
22.1. Introduction and configuration21.1. Name Resolution in a pure Unix/Linux world
22.2. Included modules21.1.1. /etc/hosts
21.1.2. /etc/resolv.conf
21.1.3. /etc/host.conf
21.1.4. /etc/nsswitch.conf
21.2. Name resolution as used within MS Windows networking
22.2.1. audit21.2.1. The NetBIOS Name Cache
22.2.2. recycle21.2.2. The LMHOSTS file
22.2.3. netatalk21.2.3. HOSTS file
21.2.4. DNS Lookup
21.2.5. WINS Lookup
22.3. VFS modules available elsewhere22. Improved browsing in samba
22.3.1. DatabaseFS22.1. Overview of browsing
22.3.2. vscan22.2. Browsing support in samba
22.3. Problem resolution
22.4. Browsing across subnets
22.4.1. How does cross subnet browsing work ?
22.5. Setting up a WINS server
22.6. Setting up Browsing in a WORKGROUP
22.7. Setting up Browsing in a DOMAIN
22.8. Forcing samba to be the master
22.9. Making samba the domain master
22.10. Note about broadcast addresses
22.11. Multiple interfaces
23.1. Introduction
23.2. Using host based protection
23.3. Using interface protection
23.4. Using a firewall
23.5. Using a IPC$ share deny
23.6. Upgrading Samba
24.1. What are charsets and unicode?
24.2. Samba and charsets

Chapter 10. Advanced Network Manangement Information

10.1. Remote Server Administration

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

Chapter 11. UNIX Permission Bits and Windows NT Access Control Lists

Chapter 10. UNIX Permission Bits and Windows NT Access Control Lists

11.1. Viewing and changing UNIX permissions using the NT +NAME="AEN1499" +>10.1. Viewing and changing UNIX permissions using the NT security dialogs

All access to Unix/Linux system file via Samba is controlled at + the operating system file access control level. When trying to + figure out file access problems it is vitally important to identify + the identity of the Windows user as it is presented by Samba at + the point of file access. This can best be determined from the + Samba log files. +

11.2. How to view file security on a Samba share10.2. How to view file security on a Samba share

From an NT4/2000/XP client, single-click with the right @@ -7929,8 +8344,8 @@ CLASS="SECT1" >

11.3. Viewing file ownership10.3. Viewing file ownership

Clicking on the

11.4. Viewing file or directory permissions10.4. Viewing file or directory permissions

The third button is the

11.4.1. File Permissions10.4.1. File Permissions

The standard UNIX user/group/world triple and @@ -8131,8 +8546,8 @@ CLASS="SECT2" >

11.4.2. Directory Permissions10.4.2. Directory Permissions

Directories on an NT NTFS file system have two @@ -8163,8 +8578,8 @@ CLASS="SECT1" >

11.5. Modifying file or directory permissions10.5. Modifying file or directory permissions

Modifying file and directory permissions is as simple @@ -8259,8 +8674,8 @@ CLASS="SECT1" >

11.6. Interaction with the standard Samba create mask +NAME="AEN1594" +>10.6. Interaction with the standard Samba create mask parameters

11.7. Interaction with the standard Samba file attribute +NAME="AEN1648" +>10.7. Interaction with the standard Samba file attribute mapping

Chapter 12. Group mapping HOWTOChapter 11. Configuring Group Mapping

Starting with Samba 3.0 alpha 2, a new group mapping function is available. The @@ -8570,9 +8985,9 @@ CLASS="COMMAND" >domain admins group by running the command:

smbgroupedit -c "Domain Admins" -u domadmsmbgroupedit -c "Domain Admins" -u domadm

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

smbgroupedit -vsmbgroupedit -v

Chapter 13. Configuring PAM for distributed but centrally -managed authentication

Chapter 12. Printing Support

13.1. Samba and PAM12.1. Introduction

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

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

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

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

  • 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"
-
    +>Support for downloading printer driver + files to Windows 95/98/NT/2000 clients upon demand.

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

	#%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 -sample system include:

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

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

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

  • The following example for the login program replaces the use of -the pam_pwdb.so module which uses the system -password database (/etc/passwd, -/etc/shadow, /etc/group) with -the module pam_smbpass.so which uses the Samba -database which contains the Microsoft MD4 encrypted password -hashes. This database is stored in either -/usr/local/samba/private/smbpasswd, -/etc/samba/smbpasswd, or in -/etc/samba.d/smbpasswd, depending on the -Samba implementation for your Unix/Linux system. The -pam_smbpass.so module is provided by -Samba version 2.2.1 or later. It can be compiled by specifying the ---with-pam_smbpass options when running Samba's -configure script. For more information -on the pam_smbpass module, see the documentation -in the source/pam_smbpass directory of the Samba -source distribution.

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

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

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

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

    There has been some initial confusion about what all this means +and whether or not it is a requirement for printer drivers to be +installed on a Samba host in order to support printing from Windows +clients. As a side note, Samba does not use these drivers in any way to process +spooled files. They are utilized entirely by the clients.

    	#%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
    The following MS KB article, may be of some help if you are dealing with +Windows 2000 clients: How to Add Printers with No User +Interaction in Windows 2000

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

    	#%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
    http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP

    12.2. Configuration

    [print$] vs. [printer$]
     

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

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

    Default: obey pam restrictions = no

    Chapter 14. Printing Support

    14.1. Introduction

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

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

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

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

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

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

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

    There has been some initial confusion about what all this means -and whether or not it is a requirement for printer drivers to be -installed on a Samba host in order to support printing from Windows -clients. As a side note, Samba does not use these drivers in any way to process -spooled files. They are utilized entirely by the clients.

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

    http://support.microsoft.com/support/kb/articles/Q189/1/05.ASP

    14.2. Configuration

    [print$] vs. [printer$]
     

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

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

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

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

    14.2.1. Creating [print$]12.2.1. Creating [print$]

    In order to support the uploading of printer driver @@ -9233,14 +9296,14 @@ Samba follows this model as well.

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

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

    14.2.2. Setting Drivers for Existing Printers12.2.2. Setting Drivers for Existing Printers

    The initial listing of printers in the Samba host's @@ -9395,8 +9458,8 @@ CLASS="SECT2" >

    14.2.3. Support a large number of printers12.2.3. Support a large number of printers

    One issue that has arisen during the development @@ -9415,13 +9478,16 @@ setdriver command

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

    14.2.4. Adding New Printers via the Windows NT APW12.2.4. Adding New Printers via the Windows NT APW

    By default, Samba offers all printer shares defined in

    14.2.5. Samba and Printer Ports12.2.5. Samba and Printer Ports

    Windows NT/2000 print servers associate a port with each printer. These normally @@ -9651,8 +9724,8 @@ CLASS="SECT1" >

    14.3. The Imprints Toolset12.3. The Imprints Toolset

    The Imprints tool set provides a UNIX equivalent of the @@ -9669,8 +9742,8 @@ CLASS="SECT2" >

    14.3.1. What is Imprints?12.3.1. What is Imprints?

    Imprints is a collection of tools for supporting the goals @@ -9701,8 +9774,8 @@ CLASS="SECT2" >

    14.3.2. Creating Printer Driver Packages12.3.2. Creating Printer Driver Packages

    The process of creating printer driver packages is beyond @@ -9717,8 +9790,8 @@ CLASS="SECT2" >

    14.3.3. The Imprints server12.3.3. The Imprints server

    The Imprints server is really a database server that @@ -9741,8 +9814,8 @@ CLASS="SECT2" >

    14.3.4. The Installation Client12.3.4. The Installation Client

    More information regarding the Imprints installation client @@ -9835,16 +9908,16 @@ CLASS="SECT1" >

    14.4. Diagnosis12.4. Diagnosis

    14.4.1. Introduction12.4.1. Introduction

    This is a short description of how to debug printing problems with @@ -9918,8 +9991,8 @@ CLASS="SECT2" >

    14.4.2. Debugging printer problems12.4.2. Debugging printer problems

    One way to debug printing problems is to start by replacing these @@ -9975,8 +10048,8 @@ CLASS="SECT2" >

    14.4.3. What printers do I have?12.4.3. What printers do I have?

    You can use the 'testprns' program to check to see if the printer @@ -10004,8 +10077,8 @@ CLASS="SECT2" >

    14.4.4. Setting up printcap and print servers12.4.4. Setting up printcap and print servers

    You may need to set up some printcaps for your Samba system to use. @@ -10088,8 +10161,8 @@ CLASS="SECT2" >

    14.4.5. Job sent, no output12.4.5. Job sent, no output

    This is the most frustrating part of printing. You may have sent the @@ -10133,8 +10206,8 @@ CLASS="SECT2" >

    14.4.6. Job sent, strange output12.4.6. Job sent, strange output

    Once you have the job printing, you can then start worrying about @@ -10179,8 +10252,8 @@ CLASS="SECT2" >

    14.4.7. Raw PostScript printed12.4.7. Raw PostScript printed

    This is a problem that is usually caused by either the print spooling @@ -10194,8 +10267,8 @@ CLASS="SECT2" >

    14.4.8. Advanced Printing12.4.8. Advanced Printing

    Note that you can do some pretty magic things by using your @@ -10210,8 +10283,8 @@ CLASS="SECT2" >

    14.4.9. Real debugging12.4.9. Real debugging

    If the above debug tips don't help, then maybe you need to bring in @@ -10225,14 +10298,14 @@ CLASS="CHAPTER" >Chapter 15. CUPS Printing SupportChapter 13. CUPS Printing Support

    15.1. Introduction13.1. Introduction

    The Common Unix Print System (CUPS) has become very popular, but to many it is @@ -10253,29 +10326,142 @@ many ways this gives CUPS similar capabilities to the MS Windows print monitorin system. Of course, if you are a CUPS advocate, you would agrue that CUPS is better! In any case, let us now move on to explore how one may configure CUPS for interfacing with MS Windows print clients via Samba.

    CUPS is a newcomer in the UNIX printing scene, +which has convinced many people upon first trial already. However, it has quite a few +new features, which make it different from other, more traditional printing systems.

    15.2. CUPS - RAW Print Through Mode13.2. Configuring smb.conf for CUPS

    When CUPS printers are configured for RAW print-through mode operation it is the -responsibility of the Samba client to fully render the print job (file) in a format -that is suitable for direct delivery to the printer. In this case CUPS will NOT -do any print file format conversion work.

    The CUPS files that need to be correctly set for RAW mode printers to work are: - -

    • Printing with CUPS in the most basic smb.conf +setup in Samba-3 only needs two settings: printing = cups and +printcap = cups. While CUPS itself doesn't need a printcap +anymore, the cupsd.conf configuration file knows two directives +(example: Printcap /etc/printcap and PrintcapFormat +BSD), which control if such a file should be created for the +convenience of third party applications. Make sure it is set! For details see +man cupsd.conf and other CUPS-related documentation.

      If SAMBA is compiled against libcups, then printcap = cups uses the +CUPS API to list printers, submit jobs, etc. Otherwise it maps to the System V commands +with an additional -oraw option for printing. On a Linux system, +you can use the ldd command to find out details (ldd may not be +present on other OS platforms, or its function may be embodied by a different command):

      transmeta:/home/kurt # ldd `which smbd`
+        libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
+        libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
+        libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
+        libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
+        libnsl.so.1 => /lib/libnsl.so.1 (0x401ec000)
+        libpam.so.0 => /lib/libpam.so.0 (0x40202000)
+        libc.so.6 => /lib/libc.so.6 (0x4020b000)
+        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

      The line "libcups.so.2 => /usr/lib/libcups.so.2 +(0x40123000)" shows there is CUPS support compiled into this version of +Samba. If this is the case, and printing = cups is set, then any +otherwise manually set print command in smb.conf is ignored.

    13.3. CUPS - RAW Print Through Mode

    When used in raw print through mode is will be necessary to use the printer +vendor's drivers in each Windows client PC.

    When CUPS printers are configured for RAW print-through mode operation it is the +responsibility of the Samba client to fully render the print job (file) in a format +that is suitable for direct delivery to the printer. In this case CUPS will NOT +do any print file format conversion work.

    The CUPS files that need to be correctly set for RAW mode printers to work are: + +

    • /etc/cups/mime.types

      15.3. The CUPS Filter Chains13.4. CUPS as a network PostScript RIP -- CUPS drivers working on server, Adobe +PostScript driver with CUPS-PPDs downloaded to clients

      The following diagrams reveal how CUPS handles print jobs.

      CUPS is perfectly able to use PPD files (PostScript +Printer Descriptions). PPDs can control all print device options. They +are usually provided by the manufacturer -- if you own a PostSript printer, +that is. PPD files are always a component of PostScript printer drivers on MS +Windows or Apple Mac OS systems. They are ASCII files containing +user-selectable print options, mapped to appropriate PostScript, PCL or PJL +commands for the target printer. Printer driver GUI dialogs translate these +options "on-the-fly" into buttons and drop-down lists for the user to +select.

      CUPS can load, without any conversions, the PPD file from +any Windows (NT is recommended) PostScript driver and handle the options. +There is a web browser interface to the print options (select +http://localhost:631/printers/ and click on one "Configure Printer" button +to see it), a commandline interface (see man lpoptions or +try if you have lphelp on your system) plus some different GUI frontends on Linux +UNIX, which can present PPD options to the users. PPD options are normally +meant to become evaluated by the PostScript RIP on the real PostScript +printer.

      CUPS doesn't stop at "real" PostScript printers in its +usage of PPDs. The CUPS developers have extended the PPD concept, to also +describe available device and driver options for non-PostScript printers +through CUPS-PPDs.

      This is logical, as CUPS includes a fully featured +PostScript interpreter (RIP). This RIP is based on Ghostscript. It can +process all received PostScript (and additionally many other file formats) +from clients. All CUPS-PPDs geared to non-PostScript printers contain an +additional line, starting with the keyword *cupsFilter. +This line +tells the CUPS print system which printer-specific filter to use for the +interpretation of the accompanying PostScript. Thus CUPS lets all its +printers appear as PostScript devices to its clients, because it can act as a +PostScript RIP for those printers, processing the received PostScript code +into a proper raster print format.

      CUPS-PPDs can also be used on Windows-Clients, on top of a +PostScript driver (recommended is the Adobe one).

      This feature enables CUPS to do a few tricks no other +spooler can do:

      • act as a networked PostScript RIP (Raster Image Processor), handling + printfiles from all client platforms in a uniform way;

      • act as a central accounting and billing server, as all files are passed + through the pstops Filter and are therefor logged in + the CUPS page_log. - NOTE: this + can not happen with "raw" print jobs, which always remain unfiltered + per definition;

      • enable clients to consolidate on a single PostScript driver, even for + many different target printers.

    13.5. Windows Terminal Servers (WTS) as CUPS clients

    This setup may be of special interest to people +experiencing major problems in WTS environments. WTS need often a multitude +of non-PostScript drivers installed to run their clients' variety of +different printer models. This often imposes the price of much increased +instability. In many cases, in an attempt to overcome this problem, site +administrators have resorted to restrict the allowed drivers installed on +their WTS to one generic PCL- and one PostScript driver. This however +restricts the clients in the amount of printer options available for them -- +often they can't get out more then simplex prints from one standard paper +tray, while their devices could do much better, if driven by a different +driver!

    Using an Adobe PostScript driver, enabled with a CUPS-PPD, +seems to be a very elegant way to overcome all these shortcomings. The +PostScript driver is not known to cause major stability problems on WTS (even +if used with many different PPDs). The clients will be able to (again) chose +paper trays, duplex printing and other settings. However, there is a certain +price for this too: a CUPS server acting as a PostScript RIP for its clients +requires more CPU and RAM than just to act as a "raw spooling" device. Plus, +this setup is not yet widely tested, although the first feedbacks look very +promising...

    13.6. Setting up CUPS for driver download

    The cupsadsmb utility (shipped with all current +CUPS versions) makes the sharing of any (or all) installed CUPS printers very +easy. Prior to using it, you need the following settings in smb.conf:

    #########################################################################
-#
-# CUPS in and of itself has this (general) filter chain (CAPITAL
-# letters are FILE-FORMATS or MIME types, other are filters (this is
-# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
-#
-# SOMETHNG-FILEFORMAT
-#      |
-#      |
-#      V
-#     somethingtops
-#      |
-#      |
-#      V
-# APPLICATION/POSTSCRIPT
-#      |
-#      |
-#      V
-#     pstops
-#      |
-#      |
-#      V
-# APPLICATION/VND.CUPS-POSTSCRIPT
-#      |
-#      |
-#      V
-#     pstoraster   # as shipped with CUPS, independent from any Ghostscipt
-#      |           # installation on the system
-#      |  (= "postscipt interpreter")
-#      |
-#      V
-# APPLICATION/VND.CUPS-RASTER
-#      |
-#      |
-#      V
-#     rastertosomething  (f.e. Gimp-Print filters may be plugged in here)
-#      |   (= "raster driver")
-#      |
-#      V
-# SOMETHING-DEVICE-SPECIFIC
-#      |
-#      |
-#      V
-#     backend
-#
-#
-# ESP PrintPro has some enhanced "rastertosomething" filters as compared to
-# CUPS, and also a somewhat improved "pstoraster" filter.
-#
-# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
-#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
-#
-#########################################################################
    [global] + load printers = yes + printing = cups + printcap name = cups + + [printers] + comment = All Printers + path = /var/spool/samba + browseable = no + public = yes + guest ok = yes + writable = no + printable = yes + printer admin = root + + [print$] + comment = Printer Drivers + path = /etc/samba/drivers + browseable = yes + guest ok = no + read only = yes + write list = root +

    For licensing reasons the necessary files of the Adobe +Postscript driver can not be distributed with either Samba or CUPS. You need +to download them yourself from the Adobe website. Once extracted, create a +drivers directory in the CUPS data directory (usually +/usr/share/cups/). Copy the Adobe files using +UPPERCASE filenames, to this directory as follows:

    #########################################################################
-#
-# This is how "cupsomatic" comes into play:
-# =========================================
-#
-# SOMETHNG-FILEFORMAT
-#      |
-#      |
-#      V
-#    somethingtops
-#      |
-#      |
-#      V
-# APPLICATION/POSTSCRIPT
-#      |
-#      |
-#      V
-#    pstops
-#      |
-#      |
-#      V
-# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
-#      |                                          |
-#      |                                          V
-#      V                                         cupsomatic
-#    pstoraster                                  (constructs complicated
-#      |  (= "postscipt interpreter")            Ghostscript commandline
-#      |                                         to let the file be
-#      V                                         processed by a
-# APPLICATION/VND.CUPS-RASTER                    "-sDEVICE=s.th."
-#      |                                         call...)
-#      |                                          |
-#      V                                          |
-#    rastertosomething                          V
-#      |    (= "raster driver")     +-------------------------+
-#      |                            | Ghostscript at work.... |
-#      V                            |                         |
-# SOMETHING-DEVICE-SPECIFIC         *-------------------------+
-#      |                                          |
-#      |                                          |
-#      V                                          |
-#    backend >------------------------------------+
-#      |
-#      |
-#      V
-#    THE PRINTER
-#
-#
-# Note, that cupsomatic "kidnaps" the printfile after the
-# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it through
-# the CUPS-external, systemwide Ghostscript installation, bypassing the
-# "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
-# "rastertosomething", and hands the rasterized file directly to the CUPS
-# backend...
-#
-# cupsomatic is not made by the CUPS developers. It is an independent
-# contribution to printing development, made by people from
-# Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
-#
-# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
-#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
-#
-#########################################################################
    ADFONTS.MFM + ADOBEPS4.DRV + ADOBEPS4.HLP + ADOBEPS5.DLL + ADOBEPSU.DLL + ADOBEPSU.HLP + DEFPRTR2.PPD + ICONLIB.DLL +

    Users of the ESP Print Pro software are able to install +their "Samba Drivers" package for this purpose with no problem.

    13.7. Sources of CUPS drivers / PPDs

    On the internet you can find now many thousand CUPS-PPD +files (with their companion filters), in many national languages, +supporting more than 1.000 non-PostScript models.

    NOTE: the cupsomatic trick from Linuxprinting.org is +working different from the other drivers. While the other drivers take the +generic CUPS raster (produced by CUPS' own pstoraster PostScript RIP) as +their input, cupsomatic "kidnaps" the PostScript inside CUPS, before +RIP-ping, deviates it to an external Ghostscript installation (which now +becomes the RIP) and gives it back to a CUPS backend once Ghostscript is +finished. -- CUPS versions from 1.1.15 and later will provide their pstoraster +PostScript RIP function again inside a system-wide Ghostscript +installation rather than in "their own" pstoraster filter. (This +CUPS-enabling Ghostscript version may be installed either as a +patch to GNU or AFPL Ghostscript, or as a complete ESP Ghostscript package). +However, this will not change the cupsomatic approach of guiding the printjob +along a different path through the filtering system than the standard CUPS +way...

    Once you installed a printer inside CUPS with one of the +recommended methods (the lpadmin command, the web browser interface or one of +the available GUI wizards), you can use cupsaddsmb to share the +printer via Samba. cupsaddsmb prepares the driver files for +comfortable client download and installation upon their first contact with +this printer share.

    13.7.1. cupsaddsmb

    The cupsaddsmb command copies the needed files +for convenient Windows client installations from the previously prepared CUPS +data directory to your [print$] share. Additionally, the PPD +associated with this printer is copied from /etc/cups/ppd/ to +[print$].

    root#  cupsaddsmb -U root infotec_IS2027
+Password for root required to access localhost via SAMBA: [type in password 'secret']

    To share all printers and drivers, use the -a +parameter instead of a printer name.

    Probably you want to see what's going on. Use the +-v parameter to get a more verbose output:

    Probably you want to see what's going on. Use the +-v parameter to get a more verbose output:

    Note: The following line shave been wrapped so that information is not lost.
+ 
+root#  cupsaddsmb -v -U root infotec_IS2027
+    Password for root required to access localhost via SAMBA:
+    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir W32X86;put
+       /var/spool/cups/tmp/3cd1cc66376c0 W32X86/infotec_IS2027.PPD;put /usr/share/cups/drivers/
+       ADOBEPS5.DLL W32X86/ADOBEPS5.DLL;put /usr/share/cups/drivers/ADOBEPSU.DLLr
+       W32X86/ADOBEPSU.DLL;put /usr/share/cups/drivers/ADOBEPSU.HLP W32X86/ADOBEPSU.HLP'
+    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
+    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
+    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
+    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
+    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
+    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \W32X86/infotec_IS2027.PPD (17394.6 kb/s)
+      (average 17395.2 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS5.DLL as \W32X86/ADOBEPS5.DLL (10877.4 kb/s)
+      (average 11343.0 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPSU.DLL as \W32X86/ADOBEPSU.DLL (5095.2 kb/s)
+      (average 9260.4 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPSU.HLP as \W32X86/ADOBEPSU.HLP (8828.7 kb/s)
+      (average 9247.1 kb/s)
+
+    Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir WIN40;put
+      /var/spool/cups/tmp/3cd1cc66376c0 WIN40/infotec_IS2027.PPD;put
+      /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;put
+      /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV;put
+      /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP;put
+      /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD;put
+      /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL;put
+      /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
+    added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
+    added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
+    added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
+    Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
+    NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
+    putting file /var/spool/cups/tmp/3cd1cc66376c0 as \WIN40/infotec_IS2027.PPD (26091.5 kb/s)
+      (average 26092.8 kb/s)
+    putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (11241.6 kb/s)
+      (average 11812.9 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (16640.6 kb/s)
+      (average 14679.3 kb/s)
+    putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (11285.6 kb/s)
+      (average 14281.5 kb/s)
+    putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (823.5 kb/s)
+      (average 12944.0 kb/s)
+    putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (19226.2 kb/s)
+      (average 13169.7 kb/s)
+    putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (18666.1 kb/s)
+      (average 13266.7 kb/s)
+
+    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows NT x86"
+       "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"'
+    cmd = adddriver "Windows NT x86" "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:
+       ADOBEPSU.HLP:NULL:RAW:NULL"
+    Printer Driver infotec_IS2027 successfully installed.
+
+    Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows 4.0"
+       "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:
+       ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
+    cmd = adddriver "Windows 4.0" "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:
+       ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
+    Printer Driver infotec_IS2027 successfully installed.
+
+    Running command: rpcclient localhost -N -U'root%secret'
+       -c 'setdriver infotec_IS2027 infotec_IS2027'
+    cmd = setdriver infotec_IS2027 infotec_IS2027
+    Succesfully set infotec_IS2027 to driver infotec_IS2027.
+
+    root#

    If you look closely, you'll discover your root password was transfered unencrypted over +the wire, so beware! Also, if you look further her, you'll discover error messages like +NT_STATUS_OBJECT_NAME_COLLISION in between. They occur, because +the directories WIN40 and W32X86 already +existed in the [print$] driver download share (from a previous driver +installation). They are harmless here.

    Now your printer is prepared for the clients to use. From +a client, browse to the CUPS/Samba server, open the "Printers" +share, right-click on this printer and select "Install..." or +"Connect..." (depending on the Windows version you use). Now their +should be a new printer in your client's local "Printers" folder, +named (in my case) "infotec_IS2027 on kdebitshop"

    NOTE: +cupsaddsmb will only reliably work i +with CUPS version 1.1.15 or higher +and Samba from 2.2.4. If it doesn't work, or if the automatic printer +driver download to the clients doesn't succeed, you can still manually +install the CUPS printer PPD on top of the Adobe PostScript driver on +clients and then point the client's printer queue to the Samba printer +share for connection, should you desire to use the CUPS networked +PostScript RIP functions.

    13.8. The CUPS Filter Chains

    The following diagrams reveal how CUPS handles print jobs.

    #########################################################################
 #
-# And this is how it works for ESP PrintPro from 4.3:
-# ===================================================
+# CUPS in and of itself has this (general) filter chain (CAPITAL
+# letters are FILE-FORMATS or MIME types, other are filters (this is
+# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
 #
 # something" filters as compared to
+# CUPS, and also a somewhat improved "pstoraster" filter.
+#
 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
 #       CUPS and ESP PrintPro plug-in where rasterto#########################################################################
 #
-# This is how "cupsomatic" would come into play with ESP PrintPro:
-# ================================================================
-#
+# This is how "cupsomatic" comes into play:
+# =========================================
 #
 # something                          V
-#      |   (= "raster driver")      +-------------------------+
+#      |    (= "raster driver")     +-------------------------+
 #      |                            | Ghostscript at work.... |
 #      V                            |                         |
 # SOMETHING-DEVICE-SPECIFIC         *-------------------------+
@@ -10826,6 +11365,21 @@ CLASS="REPLACEABLE"
 #      V
 #    THE PRINTER
 #
+#
+# Note, that cupsomatic "kidnaps" the printfile after the
+# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it through
+# the CUPS-external, systemwide Ghostscript installation, bypassing the
+# "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
+# "rastertosomething", and hands the rasterized file directly to the CUPS
+# backend...
+#
+# cupsomatic is not made by the CUPS developers. It is an independent
+# contribution to printing development, made by people from
+# Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
+#
 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
 #       CUPS and ESP PrintPro plug-in where rasterto#########################################################################
 #
-# And this is how it works for CUPS from 1.1.15:
-# ==============================================
+# And this is how it works for ESP PrintPro from 4.3:
+# ===================================================
 #
 # something
+>  (f.e. Gimp-Print filters may be plugged in here)
 #      |   (= "raster driver")
 #      |
 #      V
@@ -10892,22 +11441,6 @@ CLASS="REPLACEABLE"
 #      V
 #     backend
 #
-#
-# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
-#       Ghostscript. GNU Ghostscript needs to be patched to handle the
-#       CUPS requirement; ESP Ghostscript has this builtin. In any case,
-#       "gs -h" needs to show up a "cups" device. pstoraster is now a
-#       calling an appropriate "gs -sDEVICE=cups..." commandline to do
-#       the job. It will output "application/vnd.cup-raster", which will
-#       be finally processed by a CUPS raster driver "rastertosomething"
-#       Note the difference to "cupsomatic", which will *not* output
-#       CUPS-raster, but a final version of the printfile, ready to be
-#       sent to the printer. cupsomatic also doesn't use the "cups"
-#       devicemode in Ghostscript, but one of the classical devicemodes....
-#
 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
 #       CUPS and ESP PrintPro plug-in where rasterto#########################################################################
 #
-# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
-# ========================================================================
+# This is how "cupsomatic" would come into play with ESP PrintPro:
+# ================================================================
+#
 #
 # somethingtops
@@ -10940,20 +11474,170 @@ CLASS="REPLACEABLE"
 #      |
 #      |
 #      V
-#     pstops
+#    pstops
 #      |
 #      |
 #      V
-# APPLICATION/VND.CUPS-POSTSCRIPT-----+
-#                                     |
-#                  +------------------v------------------------------+
-#                  | Ghostscript        . Ghostscript at work....    |
-#                  | at work...         . (with "-sDEVICE=           |
-#                  | (with              .            s.th."        |
-#                  | "-sDEVICE=cups")   .                            |
+# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
+#      |                                          |
+#      |                                          V
+#      V                                         cupsomatic
+#    gsrip                                       (constructs complicated
+#      |  (= "postscipt interpreter")            Ghostscript commandline
+#      |                                         to let the file be
+#      V                                         processed by a
+# APPLICATION/VND.CUPS-RASTER                    "-sDEVICE=s.th."
+#      |                                         call...)
+#      |                                          |
+#      V                                          |
+#    rastertosomething                          V
+#      |   (= "raster driver")      +-------------------------+
+#      |                            | Ghostscript at work.... |
+#      V                            |                         |
+# SOMETHING-DEVICE-SPECIFIC         *-------------------------+
+#      |                                          |
+#      |                                          |
+#      V                                          |
+#    backend >------------------------------------+
+#      |
+#      |
+#      V
+#    THE PRINTER
+#
+# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
+#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
+#
+#########################################################################
    #########################################################################
+#
+# And this is how it works for CUPS from 1.1.15:
+# ==============================================
+#
+# SOMETHNG-FILEFORMAT
+#      |
+#      |
+#      V
+#     somethingtops
+#      |
+#      |
+#      V
+# APPLICATION/POSTSCRIPT
+#      |
+#      |
+#      V
+#     pstops
+#      |
+#      |
+#      V
+# APPLICATION/VND.CUPS-POSTSCRIPT-----+
+#                                     |
+#                  +------------------v------------------------------+
+#                  | Ghostscript                                     |
+#                  | at work...                                      |
+#                  | (with                                           |
+#                  | "-sDEVICE=cups")                                |
+#                  |                                                 |
+#                  |         (= "postscipt interpreter")             |
+#                  |                                                 |
+#                  +------------------v------------------------------+
+#                                     |
+#                                     |
+# APPLICATION/VND.CUPS-RASTER >-------+
+#      |
+#      |
+#      V
+#     rastertosomething
+#      |   (= "raster driver")
+#      |
+#      V
+# SOMETHING-DEVICE-SPECIFIC
+#      |
+#      |
+#      V
+#     backend
+#
+#
+# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
+#       Ghostscript. GNU Ghostscript needs to be patched to handle the
+#       CUPS requirement; ESP Ghostscript has this builtin. In any case,
+#       "gs -h" needs to show up a "cups" device. pstoraster is now a
+#       calling an appropriate "gs -sDEVICE=cups..." commandline to do
+#       the job. It will output "application/vnd.cup-raster", which will
+#       be finally processed by a CUPS raster driver "rastertosomething"
+#       Note the difference to "cupsomatic", which will *not* output
+#       CUPS-raster, but a final version of the printfile, ready to be
+#       sent to the printer. cupsomatic also doesn't use the "cups"
+#       devicemode in Ghostscript, but one of the classical devicemodes....
+#
+# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
+#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
+#
+#########################################################################
    #########################################################################
+#
+# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
+# ========================================================================
+#
+# SOMETHNG-FILEFORMAT
+#      |
+#      |
+#      V
+#     somethingtops
+#      |
+#      |
+#      V
+# APPLICATION/POSTSCRIPT
+#      |
+#      |
+#      V
+#     pstops
+#      |
+#      |
+#      V
+# APPLICATION/VND.CUPS-POSTSCRIPT-----+
+#                                     |
+#                  +------------------v------------------------------+
+#                  | Ghostscript        . Ghostscript at work....    |
+#                  | at work...         . (with "-sDEVICE=           |
+#                  | (with              .            s.th."        |
+#                  | "-sDEVICE=cups")   .                            |
 #                  |                    .                            |
 #                  | (CUPS standard)    .      (cupsomatic)          |
 #                  |                    .                            |
@@ -10993,8 +11677,8 @@ CLASS="SECT1"
 >
    15.4. CUPS Print Drivers and Devices13.9. CUPS Print Drivers and Devices
    CUPS ships with good support for HP LaserJet type printers. You can install
@@ -11023,8 +11707,8 @@ CLASS="SECT2"
 >
    15.4.1. Further printing steps13.9.1. Further printing steps
    Always also consult the database on linuxprinting.org for all recommendations
@@ -11079,7 +11763,8 @@ at "/some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
        "lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P /some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
        "lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \
+          -P /some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"

    Note, that for all the "Foomatic-PPDs" from Linuxprinting.org, you also need @@ -11347,8 +12032,8 @@ CLASS="SECT1" >

    15.5. Limiting the number of pages users can print13.10. Limiting the number of pages users can print

    The feature you want is dependent on the real print subsystem you're using. @@ -11365,7 +12050,8 @@ and are spanning any time period you want.

      lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100
    lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 \ + -o job-page-limit=100

    This would limit every single user to print 100 pages or 1024 KB of data (whichever comes first) within the last 604.800 seconds ( = 1 week).

    >it guarantees to not write an PJL-headerit guarantees to not write an PJL-header

    These are the items CUPS logs in the "page_log" for every single *page* of a job:

    	* Printer name
-	* User name
-	* Job ID
-	* Time of printing
-	* the page number
-	* the number of copies
-	* a billing info string (optional)

    Printer name
    User name
    Job ID
    Time of printing
    the page number
    the number of copies
    a billing info string (optional)

    Here is an extract of my CUPS server's page_log file to illustrate the format and included items:

    	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 1 2  #marketing
 	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 2 2  #marketing
 	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 3 2  #marketing
 	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 4 2  #marketing
 	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 5 2  #marketing
-	infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 6 2  #marketing

    This was Job ID "40", printed on "infotec_IS2027" by user "kurt", a 6-page job @@ -11513,7 +12227,7 @@ BORDER="0" >page counting will go into the "backends" (these talk directly to the printer and will increase the count in sync with the - actual printing process -- a jam at the 5th sheet will lead to a stop in the counting)

       cups-samba.install
-   cups-samba.license
-   cups-samba.readme
-   cups-samba.remove
-   cups-samba.ss

    cups-samba.install + cups-samba.license + cups-samba.readme + cups-samba.remove + cups-samba.ss + +

    These have been packaged with the ESP meta packager software "EPM". The *.install and *.remove files are simple shell script, which untars the @@ -11563,18 +12279,20 @@ CLASS="FILENAME" >/usr/share/cups/drivers/. Its contents are 3 files:

       cupsdrvr.dll
-   cupsui.dll
-   cups.hlp

    cupsdrvr.dll + cupsui.dll + cups.hlp + +

    ATTENTION: due to a bug one CUPS release puts the Due to a bug one CUPS release puts the cups.hlp @@ -11604,10 +12322,12 @@ CLASS="FILENAME" >. To work around this, copy/move the file after running the "./cups-samba.install" script manually to the right place:

          cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/

    cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/ + +

    NOTE 1: Win 9x/ME clients won't work with this driver. For these you'd -still need to use the ADOBE*.* drivers as previously.

    Win 9x/ME clients won't work with this driver. For these you'd + still need to use the ADOBE*.* drivers as previously. +

    NOTE 2: It is not harming if you've still the ADOBE*.* driver files from -previous installations in the "/usr/share/cups/drivers/" directory. -The new cupsaddsmb (from 1.1.16) will automatically use the -"newest" installed driver (which here then is the CUPS drivers).

    It is not harming if you've still the ADOBE*.* driver files from + previous installations in the "/usr/share/cups/drivers/" directory. + The new cupsaddsmb (from 1.1.16) will automatically use the + "newest" installed driver (which here then is the CUPS drivers). +

    NOTE 3: Should your Win clients have had the old ADOBE*.* files and the -Adobe PostScript drivers installed, the download and installation -of the new CUPS PostScript driver for Windows NT/2k/XP will fail -at first.

    It is not enough to "delete" the printer (as the driver files -will still be kept by the clients and re-used if you try to -re-install the printer). To really get rid of the Adobe driver -files on the clients, open the "Printers" folder (possibly via -"Start --> Settings --> Control Panel --> Printers"), right-click -onto the folder background and select "Server Properties". A -new dialog opens; select the "Drivers" tab; on the list select -the driver you want to delete and click on the "Delete" button. -(This will only work if there is no single printer left which -uses that particular driver -- you need to "delete" all printers -using this driver in the "Printers" folder first.)

    Should your Win clients have had the old ADOBE*.* files and the + Adobe PostScript drivers installed, the download and installation + of the new CUPS PostScript driver for Windows NT/2k/XP will fail + at first. +

    It is not enough to "delete" the printer (as the driver files + will still be kept by the clients and re-used if you try to + re-install the printer). To really get rid of the Adobe driver + files on the clients, open the "Printers" folder (possibly via + "Start --> Settings --> Control Panel --> Printers"), right-click + onto the folder background and select "Server Properties". A + new dialog opens; select the "Drivers" tab; on the list select + the driver you want to delete and click on the "Delete" button. + (This will only work if there is no single printer left which + uses that particular driver -- you need to "delete" all printers + using this driver in the "Printers" folder first.) +

    Once you have successfully downloaded the CUPS PostScript driver -to a client, you can easily switch all printers to this one -by proceeding as described elsewhere in the "Samba HOWTO -Collection" to change a driver for an existing printer.

    Once you have successfully downloaded the CUPS PostScript driver + to a client, you can easily switch all printers to this one + by proceeding as described elsewhere in the "Samba HOWTO + Collection" to change a driver for an existing printer. +

    15.6. Advanced Postscript Printing from MS Windows13.11. Advanced Postscript Printing from MS Windows

    Let the Windows Clients use a PostScript driver to deliver poistscript to @@ -11961,8 +12686,8 @@ CLASS="SECT1" >

    15.7. Auto-Deletion of CUPS spool files13.12. Auto-Deletion of CUPS spool files

    Samba print files pass thru two "spool" directories. One the incoming directory @@ -11975,11 +12700,27 @@ For CUPS it is normally "/var/spool/cups/", as set by the cupsd.conf directive it is most likely the Samba part.

    For the CUPS part, you may want to consult:

       http://localhost:631/sam.html#PreserveJobFiles and
-   http://localhost:631/sam.html#PreserveJobHistory and
-   http://localhost:631/sam.html#MaxJobs

    http://localhost:631/sam.html#PreserveJobFiles
    http://localhost:631/sam.html#PreserveJobHistory
    http://localhost:631/sam.html#MaxJobs

    There are the settings described for your CUPS daemon, which could lead to completed job files not being deleted.

    If you have more problems, post the output of these commands:

       grep -v ^# /etc/cups/cupsd.conf | grep -v ^$
-   grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;"

    (adapt paths as needed). These commands sanitize the files @@ -12091,14 +12832,14 @@ CLASS="CHAPTER" >Chapter 16. Unified Logons between Windows NT and UNIX using WinbindChapter 14. Unified Logons between Windows NT and UNIX using Winbind

    16.1. Abstract14.1. Abstract

    Integration of UNIX and Microsoft Windows NT through @@ -12124,8 +12865,8 @@ CLASS="SECT1" >

    16.2. Introduction14.2. Introduction

    It is well known that UNIX and Microsoft Windows NT have @@ -12178,8 +12919,8 @@ CLASS="SECT1" >

    16.3. What Winbind Provides14.3. What Winbind Provides

    Winbind unifies UNIX and Windows NT account management by @@ -12220,8 +12961,8 @@ CLASS="SECT2" >

    16.3.1. Target Uses14.3.1. Target Uses

    Winbind is targeted at organizations that have an @@ -12244,8 +12985,8 @@ CLASS="SECT1" >

    16.4. How Winbind Works14.4. How Winbind Works

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

    16.4.1. Microsoft Remote Procedure Calls14.4.1. Microsoft Remote Procedure Calls

    Over the last few years, efforts have been underway @@ -12290,8 +13031,8 @@ CLASS="SECT2" >

    16.4.2. Microsoft Active Directory Services14.4.2. Microsoft Active Directory Services

    Since late 2001, Samba has gained the ability to @@ -12309,8 +13050,8 @@ CLASS="SECT2" >

    16.4.3. Name Service Switch14.4.3. Name Service Switch

    The Name Service Switch, or NSS, is a feature that is @@ -12389,8 +13130,8 @@ CLASS="SECT2" >

    16.4.4. Pluggable Authentication Modules14.4.4. Pluggable Authentication Modules

    Pluggable Authentication Modules, also known as PAM, @@ -12438,8 +13179,8 @@ CLASS="SECT2" >

    16.4.5. User and Group ID Allocation14.4.5. User and Group ID Allocation

    When a user or group is created under Windows NT @@ -12464,8 +13205,8 @@ CLASS="SECT2" >

    16.4.6. Result Caching14.4.6. Result Caching

    An active system can generate a lot of user and group @@ -12487,8 +13228,8 @@ CLASS="SECT1" >

    16.5. Installation and Configuration14.5. Installation and Configuration

    Many thanks to John Trostel

    16.5.1. Introduction14.5.1. Introduction

    This HOWTO describes the procedures used to get winbind up and @@ -12565,8 +13306,8 @@ CLASS="SECT2" >

    16.5.2. Requirements14.5.2. Requirements

    If you have a samba configuration file that you are currently @@ -12635,8 +13376,8 @@ CLASS="SECT2" >

    16.5.3. Testing Things Out14.5.3. Testing Things Out

    Before starting, it is probably best to kill off all the SAMBA @@ -12680,8 +13421,8 @@ CLASS="SECT3" >

    16.5.3.1. Configure and compile SAMBA14.5.3.1. Configure and compile SAMBA

    The configuration and compilation of SAMBA is pretty straightforward. @@ -12746,8 +13487,8 @@ CLASS="SECT3" >

    16.5.3.2. Configure 14.5.3.2. Configure nsswitch.conf and the @@ -12851,8 +13592,8 @@ CLASS="SECT3" >

    16.5.3.3. Configure smb.conf14.5.3.3. Configure smb.conf

    Several parameters are needed in the smb.conf file to control @@ -12926,8 +13667,8 @@ CLASS="SECT3" >

    16.5.3.4. Join the SAMBA server to the PDC domain14.5.3.4. Join the SAMBA server to the PDC domain

    Enter the following command to make the SAMBA server join the @@ -12964,8 +13705,8 @@ CLASS="SECT3" >

    16.5.3.5. Start up the winbindd daemon and test it!14.5.3.5. Start up the winbindd daemon and test it!

    Eventually, you will want to modify your smb startup script to @@ -13100,16 +13841,16 @@ CLASS="SECT3" >

    16.5.3.6. Fix the init.d startup scripts14.5.3.6. Fix the init.d startup scripts

    16.5.3.6.1. Linux14.5.3.6.1. Linux

    The

    16.5.3.6.2. Solaris14.5.3.6.2. Solaris

    On solaris, you need to modify the @@ -13302,8 +14043,8 @@ CLASS="SECT4" >

    16.5.3.6.3. Restarting14.5.3.6.3. Restarting

    If you restart the

    16.5.3.7. Configure Winbind and PAM14.5.3.7. Configure Winbind and PAM

    If you have made it this far, you know that winbindd and samba are working @@ -13384,8 +14125,8 @@ CLASS="SECT4" >

    16.5.3.7.1. Linux/FreeBSD-specific PAM configuration14.5.3.7.1. Linux/FreeBSD-specific PAM configuration

    The

    16.5.3.7.2. Solaris-specific configuration14.5.3.7.2. Solaris-specific configuration

    The /etc/pam.conf needs to be changed. I changed this file so that my Domain @@ -13600,8 +14341,8 @@ CLASS="SECT1" >

    16.6. Limitations14.6. Limitations

    Winbind has a number of limitations in its current @@ -13642,8 +14383,8 @@ CLASS="SECT1" >

    16.7. Conclusion14.7. Conclusion

    The winbind system, through the use of the Name Service @@ -13658,16 +14399,271 @@ NAME="AEN2664" CLASS="CHAPTER" >

    Chapter 17. Policy Management - Hows and Whys

    Chapter 15. Advanced Network Manangement

    This section attempts to document peripheral issues that are of great importance to network +administrators who want to improve network resource access control, to automate the user +environment, and to make their lives a little easier.

    15.1. Configuring Samba Share Access Controls

    This section deals with how to configure Samba per share access control restrictions. +By default samba sets no restrictions on the share itself. Restrictions on the share itself +can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can +connect to a share. In the absence of specific restrictions the default setting is to allow +the global user Everyone Full Control (ie: Full control, Change and Read).

    At this time Samba does NOT provide a tool for configuring access control setting on the Share +itself. Samba does have the capacity to store and act on access control settings, but the only +way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for +Computer Management.

    Samba stores the per share access control settings in a file called share_info.tdb. +The location of this file on your system will depend on how samba was compiled. The default location +for samba's tdb files is under /usr/local/samba/var. If the tdbdump +utility has been compiled and installed on your system then you can examine the contents of this file +by: tdbdump share_info.tdb.

    15.1.1. Share Permissions Management

    The best tool for the task is platform dependant. Choose the best tool for your environmemt.

    15.1.1.1. Windows NT4 Workstation/Server

    The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. +Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. +You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below.

    Instructions

    1. Launch the NT4 Server Manager, click on the Samba server you want to administer, then from the menu +select Computer, then click on the Shared Directories entry.

    2. Now click on the share that you wish to manage, then click on the Properties tab, next click on + the Permissions tab. Now you can Add or change access control settings as you wish.

    15.1.1.2. Windows 200x/XP

    On MS Windows NT4/200x/XP system access control lists on the share itself are set using native +tools, usually from filemanager. For example, in Windows 200x: right click on the shared folder, +then select 'Sharing', then click on 'Permissions'. The default Windows NT4/200x permission allows +Everyone Full Control on the Share.

    MS Windows 200x and later all comes with a tool called the 'Computer Management' snap-in for the +Microsoft Management Console (MMC). This tool is located by clicking on Control Panel -> +Administrative Tools -> Computer Management.

    Instructions

    1. After launching the MMC with the Computer Management snap-in, click on the menu item 'Action', + select 'Connect to another computer'. If you are not logged onto a domain you will be prompted + to enter a domain login user identifier and a password. This will authenticate you to the domain. + If you where already logged in with administrative privilidge this step is not offered.

    2. If the Samba server is not shown in the Select Computer box, then type in the name of the target +Samba server in the field 'Name:'. Now click on the [+] next to 'System Tools', then on the [+] +next to 'Shared Folders' in the left panel.

    3. Now in the right panel, double-click on the share you wish to set access control permissions on. +Then click on the tab 'Share Permissions'. It is now possible to add access control entities +to the shared folder. Do NOT forget to set what type of access (full control, change, read) you +wish to assign for each entry.

    Be careful. If you take away all permissions from the Everyone user without removing this user +then effectively no user will be able to access the share. This is a result of what is known as +ACL precidence. ie: Everyone with NO ACCESS means that MaryK who is part of the group Everyone +will have no access even if this user is given explicit full control access.

    15.2. Remote Server Administration

    How do I get 'User Manager' and 'Server Manager'?

    Since I don't need to buy an NT4 Server, 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 9x / Me +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

    15.3. Network Logon Script Magic

    This section needs work. Volunteer contributions most welcome. Please send your patches or updates +to John Terpstra.

    Chapter 16. System and Account Policies

    17.1. System Policies16.1. Creating and Managing System Policies

    Under MS Windows platforms, particularly those following the release of MS Windows @@ -13699,7 +14695,7 @@ CLASS="EMPHASIS" > under the Start->Programs->Administrative ToolsStart -> Programs -> Administrative Tools menu item. For MS Windows NT4 and later clients this file must be called

    Before embarking on the configuration of network and system policies it is highly -advisable to read the documentation available from Microsoft's web site from +advisable to read the documentation available from Microsoft's web site regarding Implementing Profiles and Policies in Windows NT 4.0Implementing Profiles and Policies in Windows NT 4.0 from http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp available from Microsoft. There are a large number of documents in addition to this old one that should also be read and understood. Try searching on the Microsoft web site for "Group Policies".

    17.1.1. Creating and Managing Windows 9x/Me Policies16.1.1. Windows 9x/Me Policies

    You need the Win98 Group Policy Editor to set Group Profiles up under Windows 9x/Me. @@ -13739,25 +14735,25 @@ It can be found on the Original full product Win98 installation CD under tools/reskit/netadmin/poledit. You install this using the +>. 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 +> etc. stuff. 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 +be placed in the root of the [NETLOGON] share. If 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.

    Further details are covered in the Win98 Resource Kit documentation.

    If you do not do it this way, then every so often Win9x/Me will check the +>If you do not take the right steps, 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.

    17.1.2. Creating and Managing Windows NT4 Style Policy Files16.1.2. Windows NT4 Style Policy Files

    To create or edit

    17.1.2.1. Registry Tattoos16.1.2.1. Registry Tattoos

    With NT4 style registry based policy changes, a large number of settings are not -automatically reversed as the user logs off. Since the settings that were in the -NTConfig.POL file were applied to the client machine registry and that apply to the -hive key HKEY_LOCAL_MACHINE are permanent until explicitly reveresd. This is known -as tattooing. It can have serious consequences down-stream and the administrator must -be extreemly careful not to lock out the ability to manage the machine at a later date.

    With NT4 style registry based policy changes, a large number of settings are not + automatically reversed as the user logs off. Since the settings that were in the + NTConfig.POL file were applied to the client machine registry and that apply to the + hive key HKEY_LOCAL_MACHINE are permanent until explicitly reversed. This is known + as tattooing. It can have serious consequences down-stream and the administrator must + be extremely careful not to lock out the ability to manage the machine at a later date. +

    17.1.3. Creating and Managing MS Windows 200x Policies16.1.3. MS Windows 200x / XP Professional Policies

    Windows NT4 System policies allows setting of registry parameters specific to @@ -13922,45 +14919,47 @@ CLASS="SECT3" >

    17.1.3.1. Administration of Win2K Policies16.1.3.1. Administration of Win2K / XP Policies

    Instructions

    Instead of using the tool called "The System Policy Editor", commonly called Poledit (from the executable name poledit.exe), GPOs are created and managed using a Microsoft Management Console (MMC) snap-in as follows:

      1. Go to the Windows 200x / XP menu Go to the Windows 200x / XP menu Start->Programs->Adminsitrative ToolsStart->Programs->Administrative Tools - and select the MMC snap-in called "Active Directory Users and Computers" -

      2. Select the domain or organizational unit (OU) that you wish to manage, then right click - to open the context menu for that object, select the properties item. -

        Select the domain or organizational unit (OU) that you wish to manage, then right click +to open the context menu for that object, select the properties item.

      3. Now left click on the Group Policy tab, then left click on the New tab. Type a name - for the new policy you will create. -

        Now left click on the Group Policy tab, then left click on the New tab. Type a name +for the new policy you will create.

      4. Now left click on the Edit tab to commence the steps needed to create the GPO. -

        Now left click on the Edit tab to commence the steps needed to create the GPO.

    All policy configuration options are controlled through the use of policy administrative templates. These files have a .adm extension, both in NT4 as well as in Windows 200x / XP. @@ -14000,6 +14999,107 @@ use this powerful tool. Please refer to the resource kit manuals for specific us >

    16.2. Managing Account/User Policies

    Policies can define a specific user's settings or the settings for a group of users. The resulting +policy file contains the registry settings for all users, groups, and computers that will be using +the policy file. Separate policy files for each user, group, or computer are not not necessary.

    If you create a policy that will be automatically downloaded from validating domain controllers, +you should name the file NTconfig.POL. As system administrator, you have the option of renaming the +policy file and, by modifying the Windows NT-based workstation, directing the computer to update +the policy from a manual path. You can do this by either manually changing the registry or by using +the System Policy Editor. This path can even be a local path such that each machine has its own policy file, +but if a change is necessary to all machines, this change must be made individually to each workstation.

    When a Windows NT4/200x/XP machine logs onto the network the NETLOGON share on the authenticating domain +controller for the presence of the NTConfig.POL file. If one exists it is downloaded, parsed and then +applied to the user's part of the registry.

    MS Windows 200x/XP clients that log onto an MS Windows Active Directory security domain may additionally, +acquire policy settings through Group Policy Objects (GPOs) that are defined and stored in Active Directory +itself. The key benefit of using AS GPOs is that they impose no registry tatooing effect. +This has considerable advanage compared with the use of NTConfig.POL (NT4) style policy updates.

    Inaddition to user access controls that may be imposed or applied via system and/or group policies +in a manner that works in conjunction with user profiles, the user management environment under +MS Windows NT4/200x/XP allows per domain as well as per user account restrictions to be applied. +Common restrictions that are frequently used includes:

    Logon Hours
    Password Aging
    Permitted Logon from certain machines only
    Account type (Local or Global)
    User Rights

    16.2.1. With Windows NT4/200x

    The tools that may be used to configure these types of controls from the MS Windows environment are: +The NT4 User Manager for domains, the NT4 System and Group Policy Editor, the registry editor (regedt32.exe). +Under MS Windows 200x/XP this is done using the Microsoft Managment Console (MMC) with approapriate +"snap-ins", the registry editor, and potentially also the NT4 System and Group Policy Editor.

    16.2.2. With a Samba PDC

    With a Samba Domain Controller, the new tools for managing of user account and policy information includes: +smbpasswd, pdbedit, smbgroupedit, net, rpcclient.. The administrator should read the +man pages for these tools and become familiar with their use.

    Chapter 18. Profile ManagementChapter 17. Desktop Profile Management

    18.1. Roaming Profiles17.1. Roaming Profiles

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

    Roaming profiles support is different for Win9x / Me +and Windows NT4/200x.

    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 +>Windows 9x / Me 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.

    Windows NT4/200x clients send a NetSAMLogon RPC request, which contains many fields, +including a separate field for the location of the user's profiles.

    18.1.1. Windows NT Configuration17.1.1. Samba Configuration for Profile Handling

    To support WinNT clients, in the [global] section of smb.conf set the +>This section documents how to configure Samba for MS Windows client profile support.

    17.1.1.1. NT4/200x User Profiles

    To support Windowns NT4/200x clients, in the [global] section of smb.conf set the following (for example):

    logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
    logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath + + This is typically implemented like: + + logon path = \\%L\Profiles\%u + + where: + %L translates to the name of the Samba server + %u translates to the user name

    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.

    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. Please refer to the man page for smb.conf in respect of the different +symantics of %L and %N, as well as %U and %u.

    18.1.2. Windows 9X Configuration

    17.1.1.2. Windows 9x / Me User Profiles

    To support Win9X clients, you must use the "logon home" parameter. Samba has +>To support Windows 9x / Me 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 +>By using the logon home parameter, you are restricted to putting Win9x / Me 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
    logon home = \\%L\%U\.profiles

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

    Not only that, but 'net use/home' will also work, because of a feature in -Win9X. It removes any directory stuff off the end of the home directory area +Windows 9x / Me. 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".

    18.1.3. Win9X and WinNT Configuration

    17.1.1.3. Mixed Windows 9x / Me and Windows NT4/200x User Profiles

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

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

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

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

    18.1.4. Windows 9X Profile Setup17.1.2. Windows Client Profile Configuration Information

    17.1.2.1. Windows 9x / Me 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". @@ -14220,7 +15319,7 @@ and deny them write access to this file.

  • On the Windows 95 machine, go to Control Panel | Passwords and +> On the Windows 9x / Me 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. @@ -14228,8 +15327,8 @@ TYPE="1" >

  • On the Windows 95 machine, go to Control Panel | Network | - Client for Microsoft Networks | Preferences. Select 'Log on to +> On the Windows 9x / Me 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. @@ -14237,12 +15336,12 @@ TYPE="1" >

    • Under Windows 95, Profiles are downloaded from the Primary Logon. +>Under Windows 9x / Me 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 @@ -14251,26 +15350,26 @@ but bear in mind that the user will be authenticated against this domain and profiles downloaded from it, if that domain logon server supports it), user name and user's password.

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

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

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

    If you have made the folders / files read-only on the samba server, -then you will get errors from the w95 machine on logon and logout, as +then you will get errors from the Windows 9x / Me 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 +you have any errors reported by the Windows 9x / Me machine, check the Unix file permissions and ownership rights on the profile directory contents, on the samba server.

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

    [Exit the registry editor]. + + [Exit the registry editor]. +

  • 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). + directory listed in the ProfilePath (this is likely to be + c:\windows\profiles\username), ask them if they + have any important files stored on their desktop or in their start menu. + Delete the contents of the directory ProfilePath (making a backup if any + of the files are needed).

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

  • log off the windows 95 client. +> log off the windows 9x / Me client.

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

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

    • 18.1.5. Windows NT Workstation 4.0

    17.1.2.2. Windows NT4 Workstation

    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.

    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 +"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 +>The entry for the NT4 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", +>In the profile directory, Windows NT4 creates more folders than Windows 9x / Me. +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.

    18.1.6. Windows NT/200x Server

    17.1.2.3. Windows 2000/XP Professional

    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.

    18.1.7. Sharing Profiles between W9x/Me and NT4/200x/XP workstations

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

    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.

      Log on as the LOCAL workstation administrator. +

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

    18.1.8. Windows NT 4

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

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

    Click on the 'User Profiles' tab +

  • Here is a quick guide:

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

    • Click on the button 'Copy To' +

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

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

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

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

      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.

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

    • Click the 'Copy To' button.

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

    • In the box labelled 'Copy Profile to' add your new path, eg: +> 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 c:\temp\foobarprofiles tool.

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

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

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

      On the XP workstation log in with an Administrator account.

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

      Click: "Start", "Run"

    • Now click OK.

      Type: "mmc"

  • Follow the above for every profile you need to migrate.

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

    A Microsoft Management Console should appear.

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

    18.1.8.2. Mandatory profiles

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

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

    18.1.8.3. moveuser.exe

    Double-Click: "Group Policy"

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

    18.1.8.4. Get SID

    Click: "Finish", "Close"

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

    Click: "OK"

  • 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

    In the "Console Root" window:

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

    18.1.9. Windows 2000/XP

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

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

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

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

    • Log on as the LOCAL workstation administrator.

      Folders"

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

      Select: "Enabled"

    • Click on the 'User Profiles' tab

      Click: OK"

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

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

    • Click on the button 'Copy To'

      Reboot

    • 17.1.3. Sharing Profiles between W9x/Me and NT4/200x/XP workstations

    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.

    17.1.4. Profile Migration from Windows NT4/200x Server to Samba

    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.

    17.1.4.1. Windows NT4 Profile Management Tools

    Unfortunately, the Resource Kit information is specific to the version of MS Windows +NT4/200x. The correct resource kit is required for each platform.

    Here is a quick guide:

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

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

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

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

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

      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.

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

      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 OK. The Selection box will close.

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

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

      Now click OK.

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

    Follow the above for every profile you need to migrate.

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

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

    17.1.4.4. Get SID

    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.

    17.2. Mandatory profiles

    A Mandatory Profile is a profile that the user does NOT have the ability to overwrite. +During the user's session it may be possible to change the desktop environment, but +as the user logs out all changes made will be lost. If it is desired to NOT allow the +user any ability to change the desktop environment then this must be done through +policy settings. See previous chapter.

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

    Under NO circumstances should the profile directory (or it's contents) be made read-only +as this may render the profile un-usable.

    For MS Windows NT4/200x/XP 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.

    For MS Windows 9x / Me it is the User.DAT file that must be renamed to User.MAN to +affect a mandatory profile.

    17.3. Creating/Managing Group Profiles

    Most organisations are arranged into departments. There is a nice benenfit in +this fact since usually most users in a department will require the same desktop +applications and the same desktop layout. MS Windows NT4/200x/XP will allow the +use of Group Profiles. A Group Profile is a profile that is created firstly using +a template (example) user. Then using the profile migration tool (see above) the +profile is assigned access rights for the user group that needs to be given access +to the group profile.

    The next step is rather important. PLEASE NOTE: Instead of assigning a group profile +to users (ie: Using User Manager) on a "per user" basis, the group itself is assigned +the now modified profile.

    • Be careful with group profiles, if the user who is a member of a group also + has a personal profile, then the result will be a fusion (merge) of the two. +

    17.4. Default Profile for Windows Users

    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:

    MS Windows 9x / Me and NT4/200x/XP will use a default profile for any user for whom +a profile does not already exist. Armed with a knowledge of where the default profile +is located on the Windows workstation, and knowing which registry keys affect the path +from which the default profile is created, it is possible to modify the default profile +to one that has been optimised for the site. This has significant administrative +advantages.

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

    17.4.1. MS Windows 9x/Me

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

    To enable default per use profiles in Windows 9x / Me you can either use the Windows 98 System +Policy Editor or change the registry directly.

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

  • To enable default per user profiles in Windows 9x / Me, launch the System Policy Editor, then +select File -> Open Registry, then click on the Local Computer icon, click on Windows 98 System, +select User Profiles, click on the enable box. Do not forget to save the registry changes.

    On the XP workstation log in with an Administrator account.

  • To modify the registry directly, launch the Registry Editor (regedit.exe), select the hive +HKEY_LOCAL_MACHINE\Network\Logon. Now add a DWORD type key with the name +"User Profiles", to enable user profiles set the value to 1, to disable user profiles set it to 0.

  • When a user logs on to a Windows 9x / Me machine, the local profile path, +HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProfileList, is checked +for an existing entry for that user:

    Type: "mmc"

  • If the user has an entry in this registry location, Windows 9x / Me checks for a locally cached +version of the user profile. Windows 9x / Me also checks the user's home directory (or other +specified directory if the location has been modified) on the server for the User Profile. +If a profile exists in both locations, the newer of the two is used. If the User Profile exists +on the server, but does not exist on the local machine, the profile on the server is downloaded +and used. If the User Profile only exists on the local machine, that copy is used.

    Click: "OK"

  • If a User Profile is not found in either location, the Default User Profile from the Windows 9x / Me +machine is used and is copied to a newly created folder for the logged on user. At log off, any +changes that the user made are written to the user's local profile. If the user has a roaming +profile, the changes are written to the user's profile on the server.

    • 17.4.2. MS Windows NT4 Workstation

    A Microsoft Management Console should appear.

  • On MS Windows NT4 the default user profile is obtained from the location +%SystemRoot%\Profiles which in a default installation will translate to +C:\WinNT\Profiles. Under this directory on a clean install there will be +three (3) directories: Administrator, All Users, Default User.

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

  • The All Users directory contains menu settings that are common across all +system users. The Default User directory contains menu entries that are +customisable per user depending on the profile settings chosen/created.

    Double-Click: "Group Policy"

  • When a new user first logs onto an MS Windows NT4 machine a new profile is created from:

    Click: "Finish", "Close"

  • All Users settings
    Default User settings (contains the default NTUser.DAT file)

    Click: "OK"

  • In the "Console Root" window:

  • When a user logs onto an MS Windows NT4 machine that is a member of a Microsoft security domain +the following steps are followed in respect of profile handling:

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

    1. "Administrative Templates", "System", "User Profiles"

      The users' account information which is obtained during the logon process contains + the location of the users' desktop profile. The profile path may be local to the + machine or it may be located on a network share. If there exists a profile at the location + of the path from the user account, then this profile is copied to the location + %SystemRoot%\Profiles\%USERNAME%. This profile then inherits the + settings in the All Users profile in the %SystemRoot%\Profiles + location. +

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

      If the user account has a profile path, but at it's location a profile does not exist, + then a new profile is created in the %SystemRoot%\Profiles\%USERNAME% + directory from reading the Default User profile. +

    3. Folders"

      If the NETLOGON share on the authenticating server (logon server) contains a policy file + (NTConfig.POL) then it's contents are applied to the NTUser.DAT + which is applied to the HKEY_CURRENT_USER part of the registry. +

    4. Select: "Enabled"

      When the user logs out, if the profile is set to be a roaming profile it will be written + out to the location of the profile. The NTuser.DAT file is then + re-created from the contents of the HKEY_CURRENT_USER contents. + Thus, should there not exist in the NETLOGON share an NTConfig.POL at the + next logon, the effect of the provious NTConfig.POL will still be held + in the profile. The effect of this is known as tatooing. +

    Click: OK"

  • MS Windows NT4 profiles may be Local or Roaming. A Local profile +will stored in the %SystemRoot%\Profiles\%USERNAME% location. A roaming profile will +also remain stored in the same way, unless the following registry key is created:

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

  • 	HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\winlogon\
+	"DeleteRoamingCache"=dword:00000001
    + +In which case, the local copy (in %SystemRoot%\Profiles\%USERNAME%) will be +deleted on logout.

    Reboot

    • Under MS Windows NT4 default locations for common resources (like My Documents +may be redirected to a network share by modifying the following registry keys. These changes may be affected +via use of the System Policy Editor (to do so may require that you create your owns template extension +for the policy editor to allow this to be done through the GUI. Another way to do this is by way of first +creating a default user profile, then while logged in as that user, run regedt32 to edit the key settings.

    The Registry Hive key that affects the behaviour of folders that are part of the default user profile +are controlled by entries on Windows NT4 is:

            HKEY_CURRENT_USER
+                \Software
+                        \Microsoft
+                                \Windows
+                                        \CurrentVersion
+                                                \Explorer
+                                                        \User Shell Folders\

    The above hive key contains a list of automatically managed folders. The default entries are:

            Name            Default Value
+        --------------  -----------------------------------------
+        AppData         %USERPROFILE%\Application Data
+        Desktop         %USERPROFILE%\Desktop
+        Favorites       %USERPROFILE%\Favorites
+        NetHood         %USERPROFILE%\NetHood
+        PrintHood       %USERPROFILE%\PrintHood
+        Programs        %USERPROFILE%\Start Menu\Programs
+        Recent          %USERPROFILE%\Recent
+        SendTo          %USERPROFILE%\SendTo
+        Start Menu      %USERPROFILE%\Start Menu
+        Startup         %USERPROFILE%\Start Menu\Programs\Startup
+
    +

    The registry key that contains the location of the default profile settings is: + +

    	HKEY_LOCAL_MACHINE
+		\SOFTWARE
+			\Microsoft
+				\Windows
+					\CurrentVersion
+						\Explorer
+							\User Shell Folders
    + +The default entries are: + +
    	Common Desktop		%SystemRoot%\Profiles\All Users\Desktop
+	Common Programs		%SystemRoot%\Profiles\All Users\Programs
+	Common Start Menu	%SystemRoot%\Profiles\All Users\Start Menu
+	Common Startu	p	%SystemRoot%\Profiles\All Users\Start Menu\Progams\Startup

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

    17.4.3. MS Windows 200x/XP

    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.

    MS Windows XP Home Edition does use default per user profiles, but can not participate + in domain security, can not log onto an NT/ADS style domain, and thus can obtain the profile + only from itself. While there are benefits in doing this the beauty of those MS Windows + clients that CAN participate in domain logon processes allows the administrator to create + a global default profile and to enforce it through the use of Group Policy Objects (GPOs). +

    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.

    When a new user first logs onto MS Windows 200x/XP machine the default profile is obtained from +C:\Documents and Settings\Default User. The administrator can modify (or change +the contents of this location and MS Windows 200x/XP will gladly user it. This is far from the optimum +arrangement since it will involve copying a new default profile to every MS Windows 200x/XP client +workstation.

    When MS Windows 200x/XP participate in a domain security context, and if the default user +profile is not found, then the client will search for a default profile in the NETLOGON share +of the authenticating server. ie: In MS Windows parlance: +%LOGONSERVER%\NETLOGON\Default User and if one exits there it will copy this +to the workstation to the C:\Documents and Settings\ under the Windows +login name of the user.

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

    This path translates, in Samba parlance, to the smb.conf [NETLOGON] share. The directory + should be created at the root of this share and msut be called Default Profile. +

    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.

    19.1. Name Resolution in a pure Unix/Linux world

    If a default profile does not exist in this location then MS Windows 200x/XP will use the local +default profile.

    The key configuration files covered in this section are:

    On loging out, the users' desktop profile will be stored to the location specified in the registry +settings that pertain to the user. If no specific policies have been created, or passed to the client +during the login process (as Samba does automatically), then the user's profile will be written to +the local machine only under the path C:\Documents and Settings\%USERNAME%.

    Those wishing to modify the default behaviour can do so through up to three methods:

    • /etc/hosts

      Modify the registry keys on the local machine manually and place the new default profile in the + NETLOGON share root - NOT recommended as it is maintenance intensive. +

    • /etc/resolv.conf

      Create an NT4 style NTConfig.POL file that specified this behaviour and locate this file + in the root of the NETLOGON share along with the new default profile. +

    • /etc/host.conf

      Create a GPO that enforces this through Active Directory, and place the new default profile + in the NETLOGON share. +

    /etc/nsswitch.confThe Registry Hive key that affects the behaviour of folders that are part of the default user profile +are controlled by entries on Windows 200x/XP is:

    	HKEY_CURRENT_USER
+		\Software
+			\Microsoft
+				\Windows
+					\CurrentVersion
+						\Explorer
+							\User Shell Folders\

    19.1.1. /etc/hosts

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

    The above hive key contains a list of automatically managed folders. The default entries are:

    	
    	127.0.0.1	localhost localhost.localdomain
-	192.168.1.1	bigbox.caldera.com	bigbox	alias4box
    The purpose of /etc/hosts is to provide a 
-name resolution mechanism so that uses do not need to remember 
-IP addresses.
    	Name		Default Value
+	--------------	-----------------------------------------
+	AppData		%USERPROFILE%\Application Data
+	Cache		%USERPROFILE%\Local Settings\Temporary Internet Files
+	Cookies		%USERPROFILE%\Cookies
+	Desktop		%USERPROFILE%\Desktop
+	Favorites	%USERPROFILE%\Favorites
+	History		%USERPROFILE%\Local Settings\History
+	Local AppData	%USERPROFILE%\Local Settings\Application Data
+	Local Settings	%USERPROFILE%\Local Settings
+	My Pictures	%USERPROFILE%\My Documents\My Pictures
+	NetHood		%USERPROFILE%\NetHood
+	Personal	%USERPROFILE%\My Documents
+	PrintHood	%USERPROFILE%\PrintHood
+	Programs	%USERPROFILE%\Start Menu\Programs
+	Recent		%USERPROFILE%\Recent
+	SendTo		%USERPROFILE%\SendTo
+	Start Menu	%USERPROFILE%\Start Menu
+	Startup		%USERPROFILE%\Start Menu\Programs\Startup
+	Templates	%USERPROFILE%\Templates
+
    +

    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

    There is also an entry called "Default" that has no value set. The default entry is of type REG_SZ, all +the others are of type REG_EXPAND_SZ.

    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

    It makes a huge difference to the speed of handling roaming user profiles if all the folders are +stored on a dedicated location on a network server. This means that it will NOT be necessary to +write Outlook PST file over the network for every login and logout.

    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.

    To set this to a network location you could use the following examples: + +
    	%LOGONSERVER%\%USERNAME%\Default Folders
    + +This would store the folders in the user's home directory under a directory called "Default Folders" + +You could also use: + +
    	\\SambaServer\FolderShare\%USERNAME%
    + +in which case the default folders will be stored in the server named SambaServer +in the share called FolderShare under a directory that has the name of the MS Windows +user as seen by the Linux/Unix file system.

    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.

    Please note that once you have created a default profile share, you MUST migrate a user's profile +(default or custom) to it.

    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.

    MS Windows 200x/XP profiles may be Local or Roaming. +A roaming profile will be cached locally unless the following registry key is created:

    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.

    	HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\winlogon\
+	"DeleteRoamingCache"=dword:00000001
    + +In which case, the local cache copy will be deleted on logout.

    19.1.2. /etc/resolv.conf

    This file tells the name resolution libraries:

    • The name of the domain to which the machine - belongs -

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

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

    Chapter 18. PAM Configuration for Centrally Managed Authentication

    19.1.3. 18.1. Samba and PAM

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

    PAM provides a mechanism that disconnects these security programs +from the underlying authentication/authorization infrastructure. +PAM is configured either through one 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:

    /etc/pam.conf (Solaris), +or by editing individual files that are located in /etc/pam.d.

    	order hosts,bind
-	multi on

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

    19.1.4. 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 /etc/nsswitch.conf

    /lib/security. If the module + is located other than default then the path may be specified as: + + 
    	auth       required      /other_path/pam_strange_module.so
+
    +

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

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

    	# /etc/nsswitch.conf
-	#
-	# Name Service Switch configuration file.
+>	#%PAM-1.0
+	# The PAM configuration file for the `login' service
 	#
-
-	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

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

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

    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.

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

    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: The following example for the login program replaces the use of +the pam_pwdb.so module which uses the system +password database (/etc/passwd, +/etc/shadow, /etc/group) with +the module pam_smbpass.so which uses the Samba +database which contains the Microsoft MD4 encrypted password +hashes. This database is stored in either +/usr/local/samba/private/smbpasswd, +/etc/samba/smbpasswd, or in +/etc/samba.d/smbpasswd, depending on the +Samba implementation for your Unix/Linux system. The +pam_smbpass.so module is provided by +Samba version 2.2.1 or later. It can be compiled by specifying the +make -nsswitch/libnss_wins.so). The resulting library should -then be installed in the --with-pam_smbpass options when running Samba's +/lib directory and -the "wins" parameter needs to be added to the "hosts:" line in -the configure script. For more information +on 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.

    19.2. Name resolution as used within MS Windows networking

    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.

    The following are typical NetBIOS name/service type registrations:

    pam_smbpass module, see the documentation +in the source/pam_smbpass directory of the Samba +source distribution.

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

    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 The following is the PAM configuration file for a particular +Linux system. The default condition uses /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.

    pam_pwdb.so.

    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.

    	#%PAM-1.0
+	# The PAM configuration file for the `samba' service
+	#
+	auth       required     pam_pwdb.so nullok nodelay shadow audit
+	account    required     pam_pwdb.so audit nodelay
+	session    required     pam_pwdb.so nodelay
+	password   required     pam_pwdb.so shadow md5

    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.

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

    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.

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

    19.2.1. The NetBIOS Name Cache

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

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

    19.2.2. The LMHOSTS file

    This file is usually located in MS Windows NT 4.0 or -2000 in 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 C:\WINNT\SYSTEM32\DRIVERS\ETC and contains -the IP Address and the machine name in matched pairs. The +>pam_stack.so module that allows all +authentication to be configured in a single central file. The LMHOSTS file performs NetBIOS name -to IP address mapping oriented.

    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.

    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.

    19.2.3. HOSTS file

    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.

    19.2.4. DNS Lookup

    18.2. Distributed Authentication

    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.

    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.

    19.2.5. WINS Lookup

    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:

    18.3. PAM Configuration in smb.conf

    	wins support = Yes

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

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

    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. 

    	wins support = No
-	wins server = xxx.xxx.xxx.xxx
    Default: obey pam restrictions = no

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

    Chapter 20. Improved browsing in samba

    Chapter 19. Stackable VFS modules

    20.1. Overview of browsing19.1. Introduction and configuration

    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.

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

    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.

    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.

    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.

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

    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.

    The modules are used in the order they are specified.

    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.

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

    20.3. Problem resolution19.2. Included modules

    19.2.1. audit

    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.

    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

    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.

    19.2.2. extd_audit

    This module is identical with the 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.audit module above except +that it sends audit logs to both syslog as well as the smbd log file/s. The +loglevel for this module is set in the smb.conf file. At loglevel = 0, only file +and directory deletions and directory and file creations are logged. At loglevel = 1 +file opens are renames and permission changes are logged , while at loglevel = 2 file +open and close calls are logged also.

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

    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.

    FIXME

    vfs_recycle_bin:versions

    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)

    FIXME

    vfs_recycle_bin:touch

    FIXME

    vfs_recycle_bin:maxsize

    FIXME

    vfs_recycle_bin:exclude

    FIXME

    vfs_recycle_bin:exclude_dir

    FIXME

    vfs_recycle_bin:noversions

    FIXME

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

    20.4. Browsing across subnets19.3. VFS modules available elsewhere

    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.

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

    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.

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

    20.4.1. How does cross subnet browsing work ?19.3.1. DatabaseFS

    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 :

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

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

    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.

    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.

    19.3.2. vscan

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

    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.

    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 20. Hosting a Microsoft Distributed File System tree on Samba

    20.1. Instructions

    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.

    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.

    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.

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

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

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

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

    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.

    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
+># The smb.conf file:
+[global]
+	netbios name = SAMBA
+	host msdfs   = yes
 
-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.

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

    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.

    root# cd /export/dfsroot

    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 :

    root# chown root /export/dfsroot

    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.
    root# chmod 755 /export/dfsroot

    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.

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

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

    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.

    20.1.1. Notes

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

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

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

    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.

    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.

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

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

    21.1. Name Resolution in a pure Unix/Linux world

    The key configuration files covered in this section are:

    • /etc/hosts

    • /etc/resolv.conf

    • /etc/host.conf

    • /etc/nsswitch.conf

    21.1.1. /etc/hosts

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

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

    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

    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

    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.

    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.

    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.

    21.1.2. /etc/resolv.conf

    This file tells the name resolution libraries:

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

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

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

    21.1.3. /etc/host.conf

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

    	order hosts,bind
+	multi on

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

    21.1.4. /etc/nsswitch.conf

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

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

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

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

    21.2. Name resolution as used within MS Windows networking

    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.

    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.

    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.

    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.

    21.2.1. The NetBIOS Name Cache

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

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

    21.2.2. The LMHOSTS file

    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.

    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.

    21.2.3. HOSTS file

    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.

    21.2.4. DNS Lookup

    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.

    21.2.5. WINS Lookup

    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.

    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.

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

    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.
    wins support = Yes

    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 :

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

    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.

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

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

    1. 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. Attempts to connect to these inaccessible computers will fail, but the - names will not be removed from the network neighbourhood lists. -

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

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

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

    wins support = yes

    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.

    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 :

    wins server = >name or IP address<

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

    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.

    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.

    Chapter 22. Improved browsing in samba

    20.6. Setting up Browsing in a WORKGROUP22.1. Overview of browsing

    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.

    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 :

    SMB networking provides a mechanism by which clients can access a list +of machines in a network, a so-called 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 :

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

    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.

    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 :

    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.

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

    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.

    20.7. Setting up Browsing in a DOMAIN22.2. Browsing support in samba

    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.

    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.

    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 :

    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.

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

    If you wish to have a Samba server fight the election with machines -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.

    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.

    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 :

    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.

    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 domain master = no - local master = no - preferred master = no - os level = 0

    remote announce in the +smb.conf man page.

    20.8. Forcing samba to be the master22.3. Problem resolution

    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.

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

    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.

    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.

    The maximum os level is 255

    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.

    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.

    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.

    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.

    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.

    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 other big problem people have is that their broadcast address, +netmask or IP address is wrong (specified with the "interfaces" option +in smb.conf)

    20.9. Making samba the domain master22.4. Browsing across subnets

    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:

    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.

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

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

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

      22.4.1. How does cross subnet browsing work ?

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

    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.

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

    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)

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

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

    20.10. Note about broadcast addresses

    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.

    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.

    20.11. Multiple interfaces

    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.

    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. Hosting a Microsoft Distributed File System tree on Samba

    21.1. Instructions

    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.

    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.

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

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

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

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

    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

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

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

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

    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 :

    # The smb.conf file:
-[global]
-	netbios name = SAMBA
-	host msdfs   = yes
+>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(*)
 
-[dfs]
-	path = /export/dfsroot
-	msdfs root = yes
-

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

    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.

    root# cd /export/dfsroot

    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.

    root# chown root /export/dfsroot

    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.

    root# chmod 755 /export/dfsroot

    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.

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

    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 :

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

    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.

    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.

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

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

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

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

        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. Currently there's a restriction that msdfs - symlink names should all be lowercase.

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

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

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

    Chapter 22. Stackable VFS modules

    22.1. Introduction and configuration22.5. Setting up a WINS server

    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.

    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

    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.

    wins support = yes

    To use the VFS modules, create a share similar to the one below. The -important parameter is the 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 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
    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.

    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 :

    wins server = >name or IP address<

    The modules are used in the order they are specified.

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

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

    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.

    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.

    22.2. Included modules22.6. Setting up Browsing in a WORKGROUP

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

    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 :

    domain master = yes

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

    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 :

    Supported options: -

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

    vfs_recycle_bin:repository

    FIXME

    vfs_recycle_bin:keeptree

    FIXME

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

    FIXME

    vfs_recycle_bin:touch
    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 :

    FIXME

    vfs_recycle_bin:maxsize
    domain master = no
+local master = yes
+preferred master = yes
+os level = 65

    FIXME

    vfs_recycle_bin:exclude
    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.

    FIXME

    vfs_recycle_bin:exclude_dir
    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.

    FIXME

    vfs_recycle_bin:noversions
    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 :

    FIXME

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

    22.2.3. netatalk

    22.7. Setting up Browsing in a DOMAIN

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

    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.

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

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

    If you wish to have a Samba server fight the election with machines +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 browser +below.

    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 :

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

    22.3. VFS modules available elsewhere22.8. Forcing samba to be the master

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

    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.

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

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

    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.

    The maximum os level is 255

    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.

    22.3.1. DatabaseFS

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

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

    1. By Eric Lorimer.

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

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

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

    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.

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

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

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

    22.3.2. vscan

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

    22.10. Note about broadcast addresses

    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.

    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.

    22.11. Multiple interfaces

    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.

    23.1. Introduction

    23.2. Using host based protection

    23.3. Using interface protection

    23.4. Using a firewall

    23.5. Using a IPC$ share deny

    23.6. Upgrading Samba

    24.1. What are charsets and unicode?

    24.2. Samba and charsets

    25. SWAT - The Samba Web Admininistration Tool
    25.1. SWAT Features and Benefits
    25.1.1. The SWAT Home Page
    25.1.2. Global Settings
    25.1.3. The SWAT Wizard
    25.1.4. Share Settings
    25.1.5. Printing Settings
    25.1.6. The Status Page
    25.1.7. The Password Change Page
    26. Migration from NT4 PDC to Samba-3 PDC
    26.1. Planning and Getting Started
    26.1.1. Objectives
    26.1.2. Steps In Migration Process
    26.2. Managing Samba-3 Domain Control
    27. Samba performance issues
    25.1. 27.1. Comparisons
    25.2. 27.2. Socket options
    25.3. 27.3. Read size
    25.4. 27.4. Max xmit
    25.5. 27.5. Log level
    25.6. 27.6. Read raw
    25.7. 27.7. Write raw
    25.8. 27.8. Slow Clients
    25.9. 27.9. Slow Logins
    25.10. 27.10. Client tuning
    26. 28. Portability
    26.1. 28.1. HPUX
    26.2. 28.2. SCO Unix
    26.3. 28.3. DNIX
    26.4. 28.4. RedHat Linux Rembrandt-II
    26.5. 28.5. AIX
    26.5.1. 28.5.1. Sequential Read Ahead
    27. 29. Samba and other CIFS clients
    27.1. 29.1. Macintosh clients?
    27.2. 29.2. OS2 Client
    27.2.1. 29.2.1. How can I configure OS/2 Warp Connect or OS/2 Warp 4 as a client for Samba?
    27.2.2. 29.2.2. How can I configure OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x for Samba?
    27.2.3. 29.2.3. Are there any other issues when OS/2 (any version) is used as a client?
    27.2.4. 29.2.4. How do I get printer driver download working for OS/2 clients?
    27.3. 29.3. Windows for Workgroups
    27.3.1. 29.3.1. Use latest TCP/IP stack from Microsoft
    27.3.2. 29.3.2. Delete .pwl files after password change
    27.3.3. 29.3.3. Configure WfW password handling
    27.3.4. 29.3.4. Case handling of passwords
    27.3.5. 29.3.5. Use TCP/IP as default protocol
    27.4. 29.4. Windows '95/'98
    27.5. 29.5. Windows 2000 Service Pack 2
    29.6. Windows NT 3.1
    28. 30. How to compile SAMBA
    28.1. 30.1. Access Samba source code via CVS
    28.1.1. 30.1.1. Introduction
    28.1.2. 30.1.2. CVS Access to samba.org
    28.2. 30.2. Accessing the samba sources via rsync and ftp
    28.3. 30.3. Building the Binaries
    28.3.1. 30.3.1. Compiling samba with Active Directory support
    28.4. 30.4. Starting the smbd and nmbd
    28.4.1. 30.4.1. Starting from inetd.conf
    28.4.2. 30.4.2. Alternative: starting it as a daemon
    29. 31. Reporting Bugs
    29.1. 31.1. Introduction
    29.2. 31.2. General info
    29.3. 31.3. Debug levels
    29.4. 31.4. Internal errors
    29.5. 31.5. Attaching to a running process
    29.6. 31.6. Patches
    30. 32. The samba checklist
    30.1. 32.1. Introduction
    30.2. 32.2. Assumptions
    30.3. Tests
    30.3.1. Test 1
    30.3.2. Test 2
    30.3.3. Test 3
    30.3.4. Test 4
    30.3.5. Test 5
    30.3.6. Test 6
    30.3.7. Test 7
    30.3.8. Test 8
    30.3.9. Test 9
    30.3.10. Test 10
    30.3.11. Test 1132.3. The tests
    30.4. 32.4. Still having troubles?

    Chapter 25. SWAT - The Samba Web Admininistration Tool

    This is a rough guide to SWAT.

    25.1. SWAT Features and Benefits

    You must use at least the following ...

    25.1.1. The SWAT Home Page

    Blah blah here.

    25.1.2. Global Settings

    Document steps right here!

    25.1.3. The SWAT Wizard

    Lots of blah blah here.

    25.1.4. Share Settings

    Document steps right here!

    25.1.5. Printing Settings

    Document steps right here!

    25.1.6. The Status Page

    Document steps right here!

    25.1.7. The Password Change Page

    Document steps right here!

    Chapter 26. Migration from NT4 PDC to Samba-3 PDC

    This is a rough guide to assist those wishing to migrate from NT4 domain control to +Samba-3 based domain control.

    26.1. Planning and Getting Started

    You must use at least the following ...

    26.1.1. Objectives

    Blah blah objectives here.

    26.1.2. Steps In Migration Process

    Document steps right here!

    26.2. Managing Samba-3 Domain Control

    Lots of blah blah here.

    Chapter 25. Samba performance issues

    Chapter 27. Samba performance issues

    25.1. Comparisons27.1. Comparisons

    The Samba server uses TCP to talk to the client. Thus if you are @@ -17388,8 +19824,8 @@ CLASS="SECT1" >

    25.2. Socket options27.2. Socket options

    There are a number of socket options that can greatly affect the @@ -17416,8 +19852,8 @@ CLASS="SECT1" >

    25.3. Read size27.3. Read size

    The option "read size" affects the overlap of disk reads/writes with @@ -17442,8 +19878,8 @@ CLASS="SECT1" >

    25.4. Max xmit27.4. Max xmit

    At startup the client and server negotiate a "maximum transmit" size, @@ -17465,8 +19901,8 @@ CLASS="SECT1" >

    25.5. Log level27.5. Log level

    If you set the log level (also known as "debug level") higher than 2 @@ -17479,8 +19915,8 @@ CLASS="SECT1" >

    25.6. Read raw27.6. Read raw

    The "read raw" operation is designed to be an optimised, low-latency @@ -17501,8 +19937,8 @@ CLASS="SECT1" >

    25.7. Write raw27.7. Write raw

    The "write raw" operation is designed to be an optimised, low-latency @@ -17518,8 +19954,8 @@ CLASS="SECT1" >

    25.8. Slow Clients27.8. Slow Clients

    One person has reported that setting the protocol to COREPLUS rather @@ -17535,8 +19971,8 @@ CLASS="SECT1" >

    25.9. Slow Logins27.9. Slow Logins

    Slow logins are almost always due to the password checking time. Using @@ -17548,8 +19984,8 @@ CLASS="SECT1" >

    25.10. Client tuning27.10. Client tuning

    Often a speed problem can be traced to the client. The client (for @@ -17656,7 +20092,7 @@ CLASS="CHAPTER" >Chapter 26. PortabilityChapter 28. Portability

    Samba works on a wide range of platforms but the interface all the platforms provide is not always compatible. This chapter contains @@ -17666,8 +20102,8 @@ CLASS="SECT1" >

    26.1. HPUX28.1. HPUX

    HP's implementation of supplementary groups is, er, non-standard (for @@ -17696,8 +20132,8 @@ CLASS="SECT1" >

    26.2. SCO Unix28.2. SCO Unix

    @@ -17713,8 +20149,8 @@ CLASS="SECT1" >

    26.3. DNIX28.3. DNIX

    DNIX has a problem with seteuid() and setegid(). These routines are @@ -17820,8 +20256,8 @@ CLASS="SECT1" >

    26.4. RedHat Linux Rembrandt-II28.4. RedHat Linux Rembrandt-II

    By default RedHat Rembrandt-II during installation adds an @@ -17844,16 +20280,16 @@ CLASS="SECT1" >

    26.5. AIX28.5. AIX

    26.5.1. Sequential Read Ahead28.5.1. Sequential Read Ahead

    Disabling Sequential Read Ahead using "vmtune -r 0" improves @@ -17867,7 +20303,7 @@ CLASS="CHAPTER" >Chapter 27. Samba and other CIFS clientsChapter 29. Samba and other CIFS clients

    This chapter contains client-specific information.

    27.1. Macintosh clients?29.1. Macintosh clients?

    Yes.

    27.2. OS2 Client29.2. OS2 Client

    27.2.1. How can I configure OS/2 Warp Connect or +NAME="AEN4207" +>29.2.1. How can I configure OS/2 Warp Connect or OS/2 Warp 4 as a client for Samba?

    27.2.2. How can I configure OS/2 Warp 3 (not Connect), +NAME="AEN4222" +>29.2.2. How can I configure OS/2 Warp 3 (not Connect), OS/2 1.2, 1.3 or 2.x for Samba?

    27.2.3. Are there any other issues when OS/2 (any version) +NAME="AEN4231" +>29.2.3. Are there any other issues when OS/2 (any version) is used as a client?

    27.2.4. How do I get printer driver download working +NAME="AEN4235" +>29.2.4. How do I get printer driver download working for OS/2 clients?

    27.3. Windows for Workgroups29.3. Windows for Workgroups

    27.3.1. Use latest TCP/IP stack from Microsoft29.3.1. Use latest TCP/IP stack from Microsoft

    Use the latest TCP/IP stack from microsoft if you use Windows @@ -18131,8 +20567,8 @@ CLASS="SECT2" >

    27.3.2. Delete .pwl files after password change29.3.2. Delete .pwl files after password change

    WfWg does a lousy job with passwords. I find that if I change my @@ -18151,8 +20587,8 @@ CLASS="SECT2" >

    27.3.3. Configure WfW password handling29.3.3. Configure WfW password handling

    There is a program call admincfg.exe @@ -18170,8 +20606,8 @@ CLASS="SECT2" >

    27.3.4. Case handling of passwords29.3.4. Case handling of passwords

    Windows for Workgroups uppercases the password before sending it to the server. Unix passwords can be case-sensitive though. Check the

    27.3.5. Use TCP/IP as default protocol29.3.5. Use TCP/IP as default protocol

    To support print queue reporting you may find @@ -18204,8 +20640,8 @@ CLASS="SECT1" >

    27.4. Windows '95/'9829.4. Windows '95/'98

    When using Windows 95 OEM SR2 the following updates are recommended where Samba @@ -18252,8 +20688,8 @@ CLASS="SECT1" >

    27.5. Windows 2000 Service Pack 229.5. Windows 2000 Service Pack 2

    @@ -18319,15 +20755,49 @@ for the profile. This default ACL includes

    DOMAIN\user "Full Control"

    NOTE : This bug does not occur when using winbind to -create accounts on the Samba host for Domain users.

    This bug does not occur when using winbind to +create accounts on the Samba host for Domain users.

    29.6. Windows NT 3.1

    If you have problems communicating across routers with Windows +NT 3.1 workstations, read this Microsoft Knowledge Base article.

    Chapter 28. How to compile SAMBAChapter 30. How to compile SAMBA

    You can obtain the samba source from the

    28.1. Access Samba source code via CVS30.1. Access Samba source code via CVS

    28.1.1. Introduction30.1.1. Introduction

    Samba is developed in an open environment. Developers use CVS @@ -18379,8 +20849,8 @@ CLASS="SECT2" >

    28.1.2. CVS Access to samba.org30.1.2. CVS Access to samba.org

    The machine samba.org runs a publicly accessible CVS @@ -18392,8 +20862,8 @@ CLASS="SECT3" >

    28.1.2.1. Access via CVSweb30.1.2.1. Access via CVSweb

    You can access the source code via your @@ -18413,8 +20883,8 @@ CLASS="SECT3" >

    28.1.2.2. Access via cvs30.1.2.2. Access via cvs

    You can also access the source code via a @@ -18454,9 +20924,9 @@ TYPE="1" > Run the command

    cvs -d :pserver:cvs@samba.org:/cvsroot login cvs -d :pserver:cvs@samba.org:/cvsroot login

    Run the command

    cvs -d :pserver:cvs@samba.org:/cvsroot co samba cvs -d :pserver:cvs@samba.org:/cvsroot co samba

    and defining a tag name. A list of branch tag names can be found on the "Development" page of the samba web site. A common request is to obtain the - latest 2.2 release code. This could be done by using the following command. + latest 2.2 release code. This could be done by using the following userinput.

    cvs -d :pserver:cvs@samba.org:/cvsroot co -r SAMBA_2_2 samba cvs -d :pserver:cvs@samba.org:/cvsroot co -r SAMBA_2_2 samba

    cvs update -d -P cvs update -d -P

    28.2. Accessing the samba sources via rsync and ftp30.2. Accessing the samba sources via rsync and ftp

    pserver.samba.org also exports unpacked copies of most parts of the CVS tree at

    28.3. Building the Binaries30.3. Building the Binaries

    To do this, first run the program To do this, first run the program ./configure - in the source directory. This should automatically configure Samba for your operating system. If you have unusual needs then you may wish to run

    28.3.1. Compiling samba with Active Directory support30.3.1. Compiling samba with Active Directory support

    In order to compile samba with ADS support, you need to have installed @@ -18682,8 +21152,8 @@ CLASS="SECT3" >

    28.3.1.1. Installing the required packages for Debian30.3.1.1. Installing the required packages for Debian

    On Debian you need to install the following packages:

    28.3.1.2. Installing the required packages for RedHat30.3.1.2. Installing the required packages for RedHat

    On RedHat this means you should have at least:

    28.4. Starting the smbd and nmbd30.4. Starting the smbd and nmbd

    You must choose to start smbd and nmbd either - as daemons or from inetd. Don't try + as daemons or from inetdDon't try to do both! Either you can put them in inetd.conf and have them started on demand - by inetdinetd, or you can start them as daemons either from the command line or in

    The main advantage of starting smbdThe main advantage of starting smbd - and nmbdnmbd using the recommended daemon method is that they will respond slightly more quickly to an initial connection request.

    28.4.1. Starting from inetd.conf30.4.1. Starting from inetd.conf

    NOTE; The following will be different if @@ -18857,19 +21327,39 @@ CLASS="FILENAME" >

    NOTE: On many systems you may need to use the "interfaces" option in smb.conf to specify the IP address - and netmask of your interfaces. Run ifconfigifconfig as root if you don't know what the broadcast is for your - net. nmbdnmbd tries to determine it at run - time, but fails on some unixes. See the section on "testing nmbd" - for a method of finding if you need to do this.

    !!!WARNING!!! Many unixes only accept around 5 +>Many unixes only accept around 5 parameters on the command line in inetd.confinetd.

    Restart inetd, perhaps just send - it a HUP. If you have installed an earlier version of nmbd nmbd then you may need to kill nmbd as well.

    28.4.2. Alternative: starting it as a daemon30.4.2. Alternative: starting it as a daemon

    To start the server as a daemon you should create @@ -18938,13 +21432,37 @@ CLASS="COMMAND" CLASS="COMMAND" >smbd.

    NOTE: If you use the SVR4 style init system then +>If you use the SVR4 style init system then you may like to look at the examples/svr4-startup script to make Samba fit into that system.

    Chapter 29. Reporting BugsChapter 31. Reporting Bugs

    29.1. Introduction31.1. Introduction

    The email address for bug reports for stable releases is samba@samba.org. @@ -19005,8 +21523,8 @@ CLASS="SECT1" >

    29.2. General info31.2. General info

    Before submitting a bug report check your config for silly @@ -19015,8 +21533,7 @@ you've misconfigured something and run testparm to test your config file for correct syntax.

    Have you run through the diagnosis? This is very important.

    29.3. Debug levels31.3. Debug levels

    If the bug has anything to do with Samba behaving incorrectly as a @@ -19061,9 +21578,15 @@ include = /usr/local/samba/lib/smb.conf.%mthen create a file /usr/local/samba/lib/smb.conf.machine/usr/local/samba/lib/smb.conf.machine where -"machine" is the name of the client you wish to debug. In that file +machine is the name of the client you wish to debug. In that file put any smb.conf commands you want, for example debuglevel = that has been used in older versions of Samba and is being retained for backwards -compatibility of smb.conf files.

    smb.conf     files.

    As the

    29.4. Internal errors31.4. Internal errors

    If you get a "INTERNAL ERROR" message in your log files it means that Samba got an unexpected signal while running. It is probably a segmentation fault and almost certainly means a bug in Samba (unless -you have faulty hardware or system software)

    If the message came from smbd then it will probably be accompanied by a message which details the last SMB message received by smbd. This @@ -19117,7 +21643,10 @@ include it in your bug report.

    You should also detail how to reproduce the problem, if possible. Please make this reasonably detailed.

    You may also find that a core file appeared in a "corefiles" +>You may also find that a core file appeared in a corefiles subdirectory of the directory where you keep your samba log files. This file is the most useful tool for tracking down the bug. To use it you do this:

    adding appropriate paths to smbd and core so gdb can find them. If you -don't have gdb then try "dbx". Then within the debugger use the -command "where" to give a stack trace of where the problem +don't have gdb then try dbx. Then within the debugger use the +command where to give a stack trace of where the problem occurred. Include this in your mail.

    If you known any assembly language then do a "disass" of the routine +>If you known any assembly language then do a disass of the routine where the problem occurred (if its in a library routine then disassemble the routine that called it) and try to work out exactly where the problem is by looking at the surrounding code. Even if you @@ -19144,15 +21682,30 @@ CLASS="SECT1" >

    29.5. Attaching to a running process31.5. Attaching to a running process

    Unfortunately some unixes (in particular some recent linux kernels) refuse to dump a core file if the task has changed uid (which smbd does often). To debug with this sort of system you could try to attach -to the running process using "gdb smbd PID" where you get PID from -smbstatus. Then use "c" to continue and try to cause the core dump +to the running process using gdb smbd PID where you get PID from +smbstatus. Then use c to continue and try to cause the core dump using the client. The debugger should catch the fault and tell you where it occurred.

    29.6. Patches31.6. Patches

    The best sort of bug report is one that includes a fix! If you send us -patches please use diff -udiff -u format if your version of -diff supports it, otherwise use diff -c4diff -c4. Make sure your do the diff against a clean version of the source and let me know exactly what version you used.

    Chapter 30. The samba checklistChapter 32. The samba checklist

    30.1. Introduction32.1. Introduction

    This file contains a list of tests you can perform to validate your @@ -19212,8 +21765,8 @@ CLASS="SECT1" >

    30.2. Assumptions32.2. Assumptions

    In all of the tests it is assumed you have a Samba server called @@ -19250,17 +21803,18 @@ CLASS="SECT1" >

    30.3. Tests32.3. The tests

    30.3.1. Test 1

    Diagnosing your samba server

    1. In the directory in which you store your smb.conf file, run the command "testparm smb.conf". If it reports any errors then your smb.conf @@ -19274,15 +21828,8 @@ CLASS="FILENAME" CLASS="FILENAME" >/usr/local/samba/lib

    30.3.2. Test 2

  • Run the command "ping BIGSERVER" from the PC and "ping ACLIENT" from the unix box. If you don't get a valid response then your TCP/IP @@ -19300,15 +21847,8 @@ you do have correct entries for the remainder of these tests.

    • 30.3.3. Test 3

  • Run the command "smbclient -L BIGSERVER" on the unix box. You should get a list of available shares back.

    • 30.3.4. Test 4

  • Run the command "nmblookup -B BIGSERVER __SAMBA__". You should get the IP address of your Samba server back.

    • 30.3.5. Test 5

  • run the command

    If ACLIENT doesn't resolve via DNS then use the IP address of the client in the above test.

    • 30.3.6. Test 6

  • Run the command

    This test will probably fail if your subnet mask and broadcast address are not correct. (Refer to TEST 3 notes above).

    • 30.3.7. Test 7

  • Run the command dir.

    • 30.3.8. Test 8

  • On the PC type the command

    • 30.3.9. Test 9

  • Run the command smb.conf. Turn it back on to fix.

    • 30.3.10. Test 10

  • Run the command preferred master = yes to ensure that an election is held at startup.

    • 30.3.11. Test 11

  • From file manager try to browse the server. Your samba server should appear in the browse list of your local workgroup (or the one you @@ -19683,6 +22167,8 @@ CLASS="COMMAND" > in your smb.conf file, or enable encrypted passwords AFTER compiling in support for encrypted passwords (refer to the Makefile).

    • 30.4. Still having troubles?32.4. Still having troubles?

    Try the mailing list or newsgroup, or use the ethereal utility to @@ -19706,7 +22192,7 @@ out the samba web page at http://samba.org/sambahttp://samba.org/samba/

    Also look at the other docs in the Samba package!