The Official Samba-3 HOWTO and

Reference Guide

Jelmer R. Vernooij, John H. Terpstra, and Gerald (Jerry) Carter

27th June 2005

ATTRIBUTION

Chapter 1, “How to Install and Test SAMBA”

• Andrew Tridgell <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Karl Auer <[email protected] >
• Dan Shearer <[email protected] >
Chapter 2, “Fast Start: Cure for Impatience”
• John H. Terpstra <[email protected] >
Chapter 3, “Server Types and Security Modes”
• Andrew Tridgell <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 4, “Domain Control”
• John H. Terpstra <[email protected] >
• Gerald (Jerry) Carter <[email protected] >
• David Bannon <[email protected] >
1
<mailto:[email protected]>
2
<mailto:[email protected]>
3
<mailto:[email protected]>
4
<mailto:[email protected]>
5
<mailto:[email protected]>
6
<mailto:[email protected]>
7
<mailto:[email protected]>
8
<mailto:[email protected]>
9
<mailto:[email protected]>
10
<mailto:[email protected]>
11
<mailto:[email protected]>
12
<mailto:[email protected]>

v
vi Attribution

• Guenther Deschner <[email protected] > (LDAP updates)

Chapter 5, “Backup Domain Control”
• John H. Terpstra <[email protected] >
• Volker Lendecke <[email protected] >
• Guenther Deschner <[email protected] > (LDAP updates)
Chapter 6, “Domain Membership”
• John H. Terpstra <[email protected] >
• Jeremy Allison <[email protected] >
• Gerald (Jerry) Carter <[email protected] >
• Andrew Tridgell <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• Guenther Deschner <[email protected] > (LDAP updates)
Chapter 7, “Standalone Servers”
• John H. Terpstra <[email protected] >
Chapter 8, “MS Windows Network Configuration Guide”
• John H. Terpstra <[email protected] >
Chapter 9, “Network Browsing”
• John H. Terpstra <[email protected] >
• Jelmer R. Vernooij <[email protected] >
13
<mailto:[email protected]>
14
<mailto:[email protected]>
15
<mailto:[email protected]>
16
<mailto:[email protected]>
17
<mailto:[email protected]>
18
<mailto:[email protected]>
19
<mailto:[email protected]>
20
<mailto:[email protected]>
21
<mailto:[email protected]>
22
<mailto:[email protected]>
23
<mailto:[email protected]>
24
<mailto:[email protected]>
25
<mailto:[email protected]>
26
<mailto:[email protected]>
Attribution vii

Chapter 10, “Account Information Databases”

• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Gerald (Jerry) Carter <[email protected] >
• Jeremy Allison <[email protected] >
• Guenther Deschner <[email protected] > (LDAP updates)
• Olivier (lem) Lemaire <[email protected] >
Chapter 11, “Group Mapping: MS Windows and UNIX”
• John H. Terpstra <[email protected] >
• Jean François Micouleau
• Gerald (Jerry) Carter <[email protected] >
Chapter 12, “Remote and Local Management: The Net Command”
• John H. Terpstra <[email protected] >
• Volker Lendecke <[email protected] >
• Guenther Deschner <[email protected] >
Chapter 13, “Identity Mapping (IDMAP)”
• John H. Terpstra <[email protected] >
Chapter 14, “User Rights and Privileges”
• Gerald (Jerry) Carter <[email protected] >
27
<mailto:[email protected]>
28
<mailto:[email protected]>
29
<mailto:[email protected]>
30
<mailto:[email protected]>
31
<mailto:[email protected]>
32
<mailto:[email protected]>
33
<mailto:[email protected]>
34
<mailto:[email protected]>
35
<mailto:[email protected]>
36
<mailto:[email protected]>
37
<mailto:[email protected]>
38
<mailto:[email protected]>
39
<mailto:[email protected]>
viii Attribution

• John H. Terpstra <[email protected] >

Chapter 15, “File, Directory, and Share Access Controls”
• John H. Terpstra <[email protected] >
• Jeremy Allison <[email protected] >
• Jelmer R. Vernooij <[email protected] > (drawing)
Chapter 16, “File and Record Locking”
• Jeremy Allison <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Eric Roseme <[email protected] >
Chapter 17, “Securing Samba”
• Andrew Tridgell <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 18, “Interdomain Trust Relationships”
• John H. Terpstra <[email protected] >
• Rafal Szczesniak <[email protected] >
• Jelmer R. Vernooij <[email protected] > (drawing)
• Stephen Langasek <[email protected] >
Chapter 19, “Hosting a Microsoft Distributed File System Tree”
40
<mailto:[email protected]>
41
<mailto:[email protected]>
42
<mailto:[email protected]>
43
<mailto:[email protected]>
44
<mailto:[email protected]>
45
<mailto:[email protected]>
46
<mailto:[email protected]>
47
<mailto:[email protected]>
48
<mailto:[email protected]>
49
<mailto:[email protected]>
50
<mailto:[email protected]>
51
<mailto:[email protected]>
52
<mailto:[email protected]>
53
<mailto:[email protected]>
Attribution ix

• Shirish Kalele <[email protected] >

• John H. Terpstra <[email protected] >
Chapter 20, “Classical Printing Support”
• Kurt Pfeifle <[email protected] >
• Gerald (Jerry) Carter <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 21, “CUPS Printing Support”
• Kurt Pfeifle <[email protected] >
• Ciprian Vizitiu <[email protected] > (drawings)
• Jelmer R. Vernooij <[email protected] > (drawings)
Chapter 22, “Stackable VFS modules”
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Tim Potter <[email protected] >
• Simo Sorce (original vfs skel README)
• Alexander Bokovoy (original vfs netatalk docs)
• Stefan Metzmacher (Update for multiple modules)
• Ed Riddle (original shadow copy docs)
Chapter 23, “Winbind: Use of Domain Accounts”
• Tim Potter <[email protected] >
54
<mailto:[email protected]>
55
<mailto:[email protected]>
56
<mailto:[email protected]>
57
<mailto:[email protected]>
58
<mailto:[email protected]>
59
<mailto:[email protected]>
60
<mailto:[email protected]>
61
<mailto:[email protected]>
62
<mailto:[email protected]>
63
<mailto:[email protected]>
64
<mailto:[email protected]>
65
<mailto:[email protected]>
x Attribution

• Andrew Tridgell <[email protected] >

• Naag Mummaneni <[email protected] > (Notes for Solaris)
• John Trostel <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 24, “Advanced Network Management”
• John H. Terpstra <[email protected] >
Chapter 25, “System and Account Policies”
• John H. Terpstra <[email protected] >
Chapter 26, “Desktop Profile Management”
• John H. Terpstra <[email protected] >
Chapter 27, “PAM-Based Distributed Authentication”
• John H. Terpstra <[email protected] >
• Stephen Langasek <[email protected] >
Chapter 28, “Integrating MS Windows Networks with Samba”
• John H. Terpstra <[email protected] >
Chapter 29, “Unicode/Charsets”
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
66
<mailto:[email protected]>
67
<mailto:[email protected]>
68
<mailto:[email protected]>
69
<mailto:[email protected]>
70
<mailto:[email protected]>
71
<mailto:[email protected]>
72
<mailto:[email protected]>
73
<mailto:[email protected]>
74
<mailto:[email protected]>
75
<mailto:[email protected]>
76
<mailto:[email protected]>
77
<mailto:[email protected]>
78
<mailto:[email protected]>
Attribution xi

• TAKAHASHI Motonobu <[email protected] > (Japanese char-

acter support)
Chapter 30, “Backup Techniques”
• John H. Terpstra <[email protected] >
Chapter 31, “High Availability”
• John H. Terpstra <[email protected] >
• Jeremy Allison <[email protected] >
Chapter 32, “Handling Large Directories”
• Jeremy Allison <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 33, “Upgrading from Samba-2.x to Samba-3.0.20”
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Gerald (Jerry) Carter <[email protected] >
Chapter 34, “Migration from NT4 PDC to Samba-3 PDC”
• John H. Terpstra <[email protected] >
Chapter 35, “SWAT: The Samba Web Administration Tool”
• John H. Terpstra <[email protected] >
Chapter 36, “The Samba Checklist”
• Andrew Tridgell <[email protected] >
79
<mailto:[email protected]>
80
<mailto:[email protected]>
81
<mailto:[email protected]>
82
<mailto:[email protected]>
83
<mailto:[email protected]>
84
<mailto:[email protected]>
85
<mailto:[email protected]>
86
<mailto:[email protected]>
87
<mailto:[email protected]>
88
<mailto:[email protected]>
89
<mailto:[email protected]>
90
<mailto:[email protected]>
xii Attribution

• Jelmer R. Vernooij <[email protected] >

• Dan Shearer <[email protected] >
Chapter 37, “Analyzing and Solving Samba Problems”
• Gerald (Jerry) Carter <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• David Bannon <[email protected] >
• Dan Shearer <[email protected] >
Chapter 38, “Reporting Bugs”
• John H. Terpstra <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• Andrew Tridgell <[email protected] >
Chapter 39, “How to Compile Samba”
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
• Andrew Tridgell <[email protected] >
Chapter 40, “Portability”
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >
Chapter 41, “Samba and Other CIFS Clients”
91
<mailto:[email protected]>
92
<mailto:[email protected]>
93
<mailto:[email protected]>
94
<mailto:[email protected]>
95
<mailto:[email protected]>
96
<mailto:[email protected]>
97
<mailto:[email protected]>
98
<mailto:[email protected]>
99
<mailto:[email protected]>
100
<mailto:[email protected]>
101
<mailto:[email protected]>
102
<mailto:[email protected]>
103
<mailto:[email protected]>
104
<mailto:[email protected]>
Attribution xiii

• Jelmer R. Vernooij <[email protected] >

• John H. Terpstra <[email protected] >
• Dan Shearer <[email protected] >
• Jim McDonough <[email protected] > (OS/2)
Chapter 42, “Samba Performance Tuning”
• Paul Cochrane <[email protected] >
• Jelmer R. Vernooij <[email protected] >
• John H. Terpstra <[email protected] >

105
<mailto:[email protected]>
106
<mailto:[email protected]>
107
<mailto:[email protected]>
108
<mailto:[email protected]>
109
<mailto:[email protected]>
110
<mailto:[email protected]>
111
<mailto:[email protected]>
PREFACE

The editors wish to thank you for your decision to purchase this book. The
Official Samba-3 HOWTO and Reference Guide is the result of many years
of accumulation of information, feedback, tips, hints, and happy solutions.
Please note that this book is a living document, the contents of which are
constantly being updated. We encourage you to contribute your tips, tech-
niques, helpful hints, and your special insight into the Windows networking
world to help make the next generation of this book even more valuable to
Samba users.
We have made a concerted effort to document more comprehensively than
has been done previously the information that may help you to better deploy
Samba and to gain more contented network users.
This book provides example configurations, it documents key aspects of Mi-
crosoft Windows networking, provides in-depth insight into the important
configuration of Samba-3, and helps to put all of these into a useful frame-
work.
The most recent electronic versions of this document can be found at <http:
//www.samba.org/> on the “Documentation” page.
Updates, patches and corrections are most welcome. Please email your
contributions to any one of the following:
Jelmer Vernooij ([email protected])112
John H. Terpstra ([email protected])113
Gerald (Jerry) Carter ([email protected])114
We wish to advise that only original and unencumbered material can be
published. Please do not submit content that is not your own work unless
proof of consent from the copyright holder accompanies your submission.

Conventions Used

The following notation conventions are used throughout this book:

xv
xvi Preface

• TOSHARG is used as an abbreviation for the book, “The Official

Samba-3 HOWTO and Reference Guide,” Editors: John H. Terpstra
and Jelmer R. Vernooij, Publisher: Prentice Hall, ISBN: 0131453556.
• Directories and filenames appear in mono-font. For example, /etc/
pam.conf.
• Executable names are bolded. For example, smbd.
• Menu items and buttons appear in bold. For example, click Next.
• Selecting a menu item is indicated as: Start → Control Panel →
Administrative Tools → Active Directory Users and Computers
FOREWORD

When John first asked me to write an introductory piece for his latest book,
I was somewhat mystified as to why he chose me. A conversation with John
provided some of the rationale, and he left it to me to fill in the rest of
the story. So, if you are willing to endure a little bit of background, I will
provide the part of the story that John wouldn’t provide.
I am the Director of Corporate Standards at Sun Microsystems, and man-
age Sun’s standards portfolio. Before that, I was the Director of Standards
at Netscape, which was when I met John. Before Sun, there was Digital
Equipment Corporation, also standards. I’ve written several books on stan-
dards, and tend to observe (and occasionally help) the technical and business
trends that drive standardization as a discipline. I tend to see standardiza-
tion as a management tool, not as a technical discipline and this is part of
the rationale that John provided.
The book that you have before you focuses on a particular standardized
way of doing something hence, it is a book about a standard. The most
important thing to keep in mind about a standard is the rationale for its
creation. Standards are created not for technical reasons, not for business
reasons, but for a deeper and much more compelling reason. Standards
are created and used to allow people to communicate in a meaningful way.
Every standard, if it is a true standard, has as its entire (and only) goal set
the increasing of relevant communication between people.
This primary goal cannot be met however, unless the standard is docu-
mented. I have been involved in too many standardization efforts when it
became apparent that everybody knows was the dominant emotion of those
providing documentation. They of the ever present they say and they know
are the bane of good standards. If they know, why are you doing a standard?
A good standard survives because people know how to use it. People know
how to use a standard when it is so transparent, so obvious, and so easy that
it become invisible. And a standard becomes invisible only when the doc-
umentation describing how to deploy it is clear, unambiguous, and correct.
These three elements must be present for a standard to be useful, allowing
communication and interaction between two separate and distinct entities

xvii
xviii Foreword

to occur without obvious effort. As you read this book, look for the evidence
of these three characteristics and notice how they are seamlessly woven into
John’s text. Clarity and unambiguity without correctness provide a tech-
nical nightmare. Correctness and clarity with ambiguity create maybe bits,
and correctness and unambiguity without clarity provide a muddle through
scenario.
And this is the rest of the story that John couldn’t (or wouldn’t) bring him-
self to state. This book provides a clear, concise, unambiguous, and tech-
nically valid presentation of Samba to make it useful to a user to someone
who wants to use the standard to increase communication and the capability
for communication between two or more entities whether person-machine,
machine-machine, or person-person. The intent of this book is not to con-
vince anyone of any agenda political, technical, or social. The intent is to
provide documentation for users who need to know about Samba, how to
use it, and how to get on with their primary responsibilities. While there
is pride on John’s part because of the tremendous success of the Samba
documentation, he writes for the person who needs a tool to accomplish a
particular job, and who has selected Samba to be that tool.
The book is a monument to John’s perseverance and dedication to Samba
and in my opinion to the goal of standardization. By writing this book, John
has provided the users of Samba those that want to deploy it to make things
better a clear, easy, and ultimately valuable resource. Additionally, he has
increased the understanding and utility of a highly useful standard, and for
this, as much as for the documentation, he is owed a debt of gratitude by
those of us who rely on standards to make our lives more manageable.
Carl Cargill, Senior Director
Corporate Standardization, The Office of the CTO
Sun Microsystems
CONTENTS

Contents

ATTRIBUTION v

PREFACE xv

FOREWORD xvii

LIST OF FIGURES xlv

LIST OF TABLES xlviii

PREFACE AND INTRODUCTION li

Part I General Installation liii

PREPARING SAMBA FOR CONFIGURATION 1

Chapter 1 HOW TO INSTALL AND TEST SAMBA 2

1.1 Obtaining and Installing Samba 2
1.2 Configuring Samba (smb.conf) 2
1.2.1 Configuration File Syntax 2
1.2.2 Starting Samba 3
1.2.3 Example Configuration 4
1.2.3.1 Test Your Config File with testparm 5
1.2.4 SWAT 6
1.3 List Shares Available on the Server 7
1.4 Connect with a UNIX Client 7
1.5 Connect from a Remote SMB Client 8
1.5.1 What If Things Don’t Work? 8
1.5.2 Still Stuck? 9
1.6 Common Errors 9
1.6.1 Large Number of smbd Processes 9
1.6.2 Error Message: open oplock ipc 10
1.6.3 “The network name cannot be found” 10

xix
xx Contents

Chapter 2 FAST START: CURE FOR IMPATIENCE 11

2.1 Features and Benefits 12
2.2 Description of Example Sites 12
2.3 Worked Examples 13
2.3.1 Standalone Server 13
2.3.1.1 Anonymous Read-Only Document Server 13
2.3.1.2 Anonymous Read-Write Document Server 16
2.3.1.3 Anonymous Print Server 17
2.3.1.4 Secure Read-Write File and Print Server 19
2.3.2 Domain Member Server 23
2.3.2.1 Example Configuration 24
2.3.3 Domain Controller 27
2.3.3.1 Example: Engineering Office 28
2.3.3.2 A Big Organization 30

Part II Server Configuration Basics 37

FIRST STEPS IN SERVER CONFIGURATION 39

Chapter 3 SERVER TYPES AND SECURITY MODES 40

3.1 Features and Benefits 40
3.2 Server Types 41
3.3 Samba Security Modes 42
3.3.1 User Level Security 43
3.3.1.1 Example Configuration 44
3.3.2 Share-Level Security 44
3.3.2.1 Example Configuration 45
3.3.3 Domain Security Mode (User-Level Security) 45
3.3.3.1 Example Configuration 46
3.3.4 ADS Security Mode (User-Level Security) 48
3.3.4.1 Example Configuration 48
3.3.5 Server Security (User Level Security) 48
3.3.5.1 Example Configuration 50
3.4 Password Checking 51
3.5 Common Errors 52
3.5.1 What Makes Samba a Server? 52
3.5.2 What Makes Samba a Domain Controller? 53
3.5.3 What Makes Samba a Domain Member? 53
3.5.4 Constantly Losing Connections to Password Server 53
Contents xxi

Chapter 4 DOMAIN CONTROL 54

4.1 Features and Benefits 56
4.2 Single Sign-On and Domain Security 58
4.3 Basics of Domain Control 61
4.3.1 Domain Controller Types 61
4.3.2 Preparing for Domain Control 64
4.4 Domain Control: Example Configuration 67
4.5 Samba ADS Domain Control 70
4.6 Domain and Network Logon Configuration 70
4.6.1 Domain Network Logon Service 70
4.6.1.1 Example Configuration 70
4.6.1.2 The Special Case of MS Windows XP Home
Edition 70
4.6.1.3 The Special Case of Windows 9x/Me 71
4.6.2 Security Mode and Master Browsers 74
4.7 Common Errors 75
4.7.1 “$” Cannot Be Included in Machine Name 75
4.7.2 Joining Domain Fails Because of Existing Machine Ac-
count 76
4.7.3 The System Cannot Log You On (C000019B) 77
4.7.4 The Machine Trust Account Is Not Accessible 77
4.7.5 Account Disabled 78
4.7.6 Domain Controller Unavailable 78
4.7.7 Cannot Log onto Domain Member Workstation After
Joining Domain 78

Chapter 5 BACKUP DOMAIN CONTROL 80

5.1 Features and Benefits 80
5.2 Essential Background Information 81
5.2.1 MS Windows NT4-style Domain Control 82
5.2.1.1 Example PDC Configuration 84
5.2.2 LDAP Configuration Notes 85
5.2.3 Active Directory Domain Control 86
5.2.4 What Qualifies a Domain Controller on the Network? 87
5.2.5 How Does a Workstation find its Domain Controller? 87
5.2.5.1 NetBIOS Over TCP/IP Enabled 87
5.2.5.2 NetBIOS Over TCP/IP Disabled 88
5.3 Backup Domain Controller Configuration 88
5.3.1 Example Configuration 90
5.4 Common Errors 91
xxii Contents

5.4.1 Machine Accounts Keep Expiring 92

5.4.2 Can Samba Be a Backup Domain Controller to an
NT4 PDC? 92
5.4.3 How Do I Replicate the smbpasswd File? 92
5.4.4 Can I Do This All with LDAP? 93

Chapter 6 DOMAIN MEMBERSHIP 94

6.1 Features and Benefits 94
6.2 MS Windows Workstation/Server Machine Trust Accounts 95
6.2.1 Manual Creation of Machine Trust Accounts 97
6.2.2 Managing Domain Machine Accounts using NT4 Server
Manager 98
6.2.3 On-the-Fly Creation of Machine Trust Accounts 99
6.2.4 Making an MS Windows Workstation or Server a Do-
main Member 100
6.2.4.1 Windows 200x/XP Professional Client 100
6.2.4.2 Windows NT4 Client 100
6.2.4.3 Samba Client 101
6.3 Domain Member Server 101
6.3.1 Joining an NT4-type Domain with Samba-3 102
6.3.2 Why Is This Better Than security = server? 104
6.4 Samba ADS Domain Membership 105
6.4.1 Configure smb.conf 105
6.4.2 Configure /etc/krb5.conf 106
6.4.3 Create the Computer Account 109
6.4.3.1 Possible Errors 110
6.4.4 Testing Server Setup 110
6.4.5 Testing with smbclient 111
6.4.6 Notes 111
6.5 Sharing User ID Mappings between Samba Domain Members 111
6.6 Common Errors 112
6.6.1 Cannot Add Machine Back to Domain 112
6.6.2 Adding Machine to Domain Fails 113
6.6.3 I Can’t Join a Windows 2003 PDC 113

Chapter 7 STANDALONE SERVERS 114

7.1 Features and Benefits 114
7.2 Background 115
7.3 Example Configuration 115
7.3.1 Reference Documentation Server 115
Contents xxiii

7.3.2 Central Print Serving 117

7.4 Common Errors 119

Chapter 8 MS WINDOWS NETWORK CONFIGURATION

GUIDE 120
8.1 Features and Benefits 120
8.2 Technical Details 120
8.2.1 TCP/IP Configuration 121
8.2.1.1 MS Windows XP Professional 121
8.2.1.2 MS Windows 2000 123
8.2.1.3 MS Windows Me 125
8.2.2 Joining a Domain: Windows 2000/XP Professional 128
8.2.3 Domain Logon Configuration: Windows 9x/Me 130
8.3 Common Errors 132

Part III Advanced Configuration 139

VALUABLE NUTS AND BOLTS INFORMATION 141

Chapter 9 NETWORK BROWSING 142

9.1 Features and Benefits 142
9.2 What Is Browsing? 143
9.3 Discussion 145
9.3.1 NetBIOS over TCP/IP 145
9.3.2 TCP/IP without NetBIOS 147
9.3.3 DNS and Active Directory 148
9.4 How Browsing Functions 151
9.4.1 Configuring Workgroup Browsing 152
9.4.2 Domain Browsing Configuration 154
9.4.3 Forcing Samba to Be the Master 155
9.4.4 Making Samba the Domain Master 156
9.4.5 Note about Broadcast Addresses 157
9.4.6 Multiple Interfaces 157
9.4.7 Use of the Remote Announce Parameter 158
9.4.8 Use of the Remote Browse Sync Parameter 158
9.5 WINS: The Windows Internetworking Name Server 159
9.5.1 WINS Server Configuration 160
9.5.2 WINS Replication 161
9.5.3 Static WINS Entries 162
xxiv Contents

9.6 Helpful Hints 163

9.6.1 Windows Networking Protocols 163
9.6.2 Name Resolution Order 164
9.7 Technical Overview of Browsing 165
9.7.1 Browsing Support in Samba 165
9.7.2 Problem Resolution 166
9.7.3 Cross-Subnet Browsing 167
9.7.3.1 Behavior of Cross-Subnet Browsing 168
9.8 Common Errors 172
9.8.1 How Can One Flush the Samba NetBIOS Name Cache
without Restarting Samba? 172
9.8.2 Server Resources Cannot Be Listed 172
9.8.3 I Get an ”Unable to browse the network” Error 173
9.8.4 Browsing of Shares and Directories is Very Slow 173

Chapter 10 ACCOUNT INFORMATION DATABASES 175

10.1 Features and Benefits 176
10.1.1 Backward Compatibility Account Storage Systems 176
10.1.2 New Account Storage Systems 177
10.2 Technical Information 178
10.2.1 Important Notes About Security 179
10.2.1.1 Advantages of Encrypted Passwords 182
10.2.1.2 Advantages of Non-Encrypted Passwords 182
10.2.2 Mapping User Identifiers between MS Windows and
UNIX 183
10.2.3 Mapping Common UIDs/GIDs on Distributed Machines183
10.2.4 Comments Regarding LDAP 184
10.2.4.1 Caution Regarding LDAP and Samba 185
10.2.5 LDAP Directories and Windows Computer Accounts 186
10.3 Account Management Tools 187
10.3.1 The smbpasswd Command 187
10.3.2 The pdbedit Command 189
10.4 Password Backends 190
10.4.1 Plaintext 190
10.4.2 smbpasswd: Encrypted Password Database 191
10.4.3 tdbsam 191
10.4.4 ldapsam 192
10.4.4.1 Supported LDAP Servers 193
10.4.4.2 Schema and Relationship to the RFC 2307
posixAccount 193
Contents xxv

10.4.4.3 OpenLDAP Configuration 195

10.4.4.4 Initialize the LDAP Database 196
10.4.4.5 Configuring Samba 198
10.4.4.6 Accounts and Groups Management 200
10.4.4.7 Security and sambaSamAccount 200
10.4.4.8 LDAP Special Attributes for sambaSamAc-
counts 201
10.4.4.9 Example LDIF Entries for a sambaSamAc-
count 202
10.4.4.10 Password Synchronization 203
10.4.5 MySQL 203
10.4.5.1 Creating the Database 203
10.4.5.2 Configuring 204
10.4.5.3 Using Plaintext Passwords or Encrypted Pass-
word 205
10.4.5.4 Getting Non-Column Data from the Table 205
10.4.6 XML 205
10.5 Common Errors 205
10.5.1 Users Cannot Logon 205
10.5.2 Users Being Added to the Wrong Backend Database 206
10.5.3 Configuration of auth methods 206

Chapter 11 GROUP MAPPING: MS WINDOWS AND UNIX212

11.1 Features and Benefits 213
11.2 Discussion 215
11.2.1 Warning: User Private Group Problems 216
11.2.2 Nested Groups: Adding Windows Domain Groups to
Windows Local Groups 217
11.2.3 Important Administrative Information 219
11.2.3.1 Applicable Only to Versions Earlier than 3.0.11219
11.2.4 Default Users, Groups, and Relative Identifiers 220
11.2.5 Example Configuration 221
11.3 Configuration Scripts 222
11.3.1 Sample smb.conf Add Group Script 222
11.3.2 Script to Configure Group Mapping 223
11.4 Common Errors 224
11.4.1 Adding Groups Fails 224
11.4.2 Adding Domain Users to the Power Users Group 224

Chapter 12 REMOTE AND LOCAL MANAGEMENT: THE

xxvi Contents

NET COMMAND 226

12.1 Overview 227
12.2 Administrative Tasks and Methods 227
12.3 UNIX and Windows Group Management 228
12.3.1 Adding, Renaming, or Deletion of Group Accounts 228
12.3.1.1 Adding or Creating a New Group 229
12.3.1.2 Mapping Windows Groups to UNIX Groups 231
12.3.1.3 Deleting a Group Account 232
12.3.1.4 Rename Group Accounts 233
12.3.2 Manipulating Group Memberships 233
12.3.3 Nested Group Support 236
12.3.3.1 Managing Nest Groups on Workstations from
the Samba Server 237
12.4 UNIX and Windows User Management 239
12.4.1 Adding User Accounts 239
12.4.2 Deletion of User Accounts 240
12.4.3 Managing User Accounts 240
12.4.4 User Mapping 241
12.5 Administering User Rights and Privileges 241
12.6 Managing Trust Relationships 245
12.6.1 Machine Trust Accounts 245
12.6.2 Interdomain Trusts 248
12.7 Managing Security Identifiers (SIDS) 250
12.8 Share Management 252
12.8.1 Creating, Editing, and Removing Shares 252
12.8.2 Creating and Changing Share ACLs 253
12.8.3 Share, Directory, and File Migration 254
12.8.3.1 Share Migration 255
12.8.3.2 File and Directory Migration 256
12.8.3.3 Simultaneous Share and File Migration 258
12.8.4 Printer Migration 258
12.9 Controlling Open Files 260
12.10 Session and Connection Management 261
12.11 Printers and ADS 261
12.12 Manipulating the Samba Cache 262
12.13 Other Miscellaneous Operations 262

Chapter 13 IDENTITY MAPPING (IDMAP) 264

13.1 Samba Server Deployment Types and IDMAP 265
13.1.1 Standalone Samba Server 265
Contents xxvii

13.1.2 Domain Member Server or Domain Member Client 265

13.1.3 Primary Domain Controller 269
13.1.4 Backup Domain Controller 269
13.2 Examples of IDMAP Backend Usage 270
13.2.1 Default Winbind TDB 270
13.2.1.1 NT4-Style Domains (Includes Samba Domains)270
13.2.1.2 ADS Domains 272
13.2.2 IDMAP RID with Winbind 273
13.2.3 IDMAP Storage in LDAP Using Winbind 275
13.2.4 IDMAP and NSS Using LDAP from ADS with RFC2307bis
Schema Extension 280
13.2.4.1 IDMAP, Active Directory, and MS Services
for UNIX 3.5 281
13.2.4.2 IDMAP, Active Directory and AD4UNIX 281

Chapter 14 USER RIGHTS AND PRIVILEGES 282

14.1 Rights Management Capabilities 283
14.1.1 Using the “net rpc rights” Utility 284
14.1.2 Description of Privileges 286
14.1.3 Privileges Suppored by Windows 2000 Domain Con-
trollers 287
14.2 The Administrator Domain SID 288
14.3 Common Errors 289
14.3.1 What Rights and Privileges Will Permit Windows Client
Administration? 289

Chapter 15 FILE, DIRECTORY, AND SHARE ACCESS CON-

TROLS 291
15.1 Features and Benefits 292
15.2 File System Access Controls 293
15.2.1 MS Windows NTFS Comparison with UNIX File Sys-
tems 293
15.2.2 Managing Directories 295
15.2.3 File and Directory Access Control 296
15.2.3.1 Protecting Directories and Files from Deletion298
15.3 Share Definition Access Controls 300
15.3.1 User- and Group-Based Controls 300
15.3.2 File and Directory Permissions-Based Controls 300
15.3.3 Miscellaneous Controls 300
15.4 Access Controls on Shares 301
xxviii Contents

15.4.1 Share Permissions Management 303

15.4.1.1 Windows NT4 Workstation/Server 303
15.4.1.2 Windows 200x/XP 303
15.5 MS Windows Access Control Lists and UNIX Interoperability 305
15.5.1 Managing UNIX Permissions Using NT Security Dialogs305
15.5.2 Viewing File Security on a Samba Share 305
15.5.3 Viewing File Ownership 306
15.5.4 Viewing File or Directory Permissions 306
15.5.4.1 File Permissions 307
15.5.4.2 Directory Permissions 307
15.5.5 Modifying File or Directory Permissions 308
15.5.6 Interaction with the Standard Samba “create mask”
Parameters 309
15.5.7 Interaction with the Standard Samba File Attribute
Mapping 310
15.5.8 Windows NT/200X ACLs and POSIX ACLs Limitations311
15.5.8.1 UNIX POSIX ACL Overview 312
15.5.8.2 Mapping of Windows File ACLs to UNIX
POSIX ACLs 313
15.5.8.3 Mapping of Windows Directory ACLs to UNIX
POSIX ACLs 313
15.6 Common Errors 313
15.6.1 Users Cannot Write to a Public Share 314
15.6.2 File Operations Done as root with force user Set 316
15.6.3 MS Word with Samba Changes Owner of File 316

Chapter 16 FILE AND RECORD LOCKING 320

16.1 Features and Benefits 320
16.2 Discussion 321
16.2.1 Opportunistic Locking Overview 322
16.2.1.1 Exclusively Accessed Shares 325
16.2.1.2 Multiple-Accessed Shares or Files 325
16.2.1.3 UNIX or NFS Client-Accessed Files 325
16.2.1.4 Slow and/or Unreliable Networks 326
16.2.1.5 Multiuser Databases 326
16.2.1.6 PDM Data Shares 326
16.2.1.7 Beware of Force User 327
16.2.1.8 Advanced Samba Oplocks Parameters 327
16.2.1.9 Mission-Critical, High-Availability 327
16.3 Samba Oplocks Control 328
Contents xxix

16.3.1 Example Configuration 329

16.3.1.1 Disabling Oplocks 329
16.3.1.2 Disabling Kernel Oplocks 330
16.4 MS Windows Oplocks and Caching Controls 332
16.4.1 Workstation Service Entries 335
16.4.2 Server Service Entries 335
16.5 Persistent Data Corruption 336
16.6 Common Errors 336
16.6.1 locking.tdb Error Messages 337
16.6.2 Problems Saving Files in MS Office on Windows XP 337
16.6.3 Long Delays Deleting Files over Network with XP SP1 338
16.7 Additional Reading 338

Chapter 17 SECURING SAMBA 339

17.1 Introduction 339
17.2 Features and Benefits 339
17.3 Technical Discussion of Protective Measures and Issues 340
17.3.1 Using Host-Based Protection 340
17.3.2 User-Based Protection 341
17.3.3 Using Interface Protection 341
17.3.4 Using a Firewall 342
17.3.5 Using IPC$ Share-Based Denials 342
17.3.6 NTLMv2 Security 343
17.4 Upgrading Samba 344
17.5 Common Errors 344
17.5.1 Smbclient Works on Localhost, but the Network Is Dead344
17.5.2 Why Can Users Access Other Users Home Directories? 344

Chapter 18 INTERDOMAIN TRUST RELATIONSHIPS 346

18.1 Features and Benefits 347
18.2 Trust Relationship Background 347
18.3 Native MS Windows NT4 Trusts Configuration 348
18.3.1 Creating an NT4 Domain Trust 348
18.3.2 Completing an NT4 Domain Trust 349
18.3.3 Interdomain Trust Facilities 349
18.4 Configuring Samba NT-Style Domain Trusts 350
18.4.1 Samba as the Trusted Domain 351
18.4.2 Samba as the Trusting Domain 352
18.5 NT4-Style Domain Trusts with Windows 2000 353
18.6 Common Errors 353
xxx Contents

18.6.1 Browsing of Trusted Domain Fails 353

18.6.2 Problems with LDAP ldapsam and Older Versions of
smbldap-tools 354

Chapter 19 HOSTING A MICROSOFT DISTRIBUTED FILE

SYSTEM TREE 356
19.1 Features and Benefits 356
19.2 Common Errors 357
19.2.1 MSDFS UNIX Path Is Case-Critical 358

Chapter 20 CLASSICAL PRINTING SUPPORT 359

20.1 Features and Benefits 359
20.2 Technical Introduction 360
20.2.1 Client to Samba Print Job Processing 361
20.2.2 Printing-Related Configuration Parameters 361
20.3 Simple Print Configuration 362
20.3.1 Verifying Configuration with testparm 363
20.3.2 Rapid Configuration Validation 364
20.4 Extended Printing Configuration 367
20.4.1 Detailed Explanation Settings 367
20.4.1.1 The [global] Section 368
20.4.1.2 The [printers] Section 371
20.4.1.3 Any [my printer name] Section 372
20.4.1.4 Print Commands 373
20.4.1.5 Default UNIX System Printing Commands 374
20.4.1.6 Custom Print Commands 375
20.5 Printing Developments Since Samba-2.2 376
20.5.1 Point’n’Print Client Drivers on Samba Servers 377
20.5.2 The Obsoleted [printer$] Section 378
20.5.3 Creating the [print$] Share 379
20.5.4 [print$] Section Parameters 379
20.5.5 The [print$] Share Directory 381
20.6 Installing Drivers into [print$] 383
20.6.1 Add Printer Wizard Driver Installation 383
20.6.2 Installing Print Drivers Using rpcclient 384
20.6.2.1 Identifying Driver Files 385
20.6.2.2 Obtaining Driver Files from Windows Client
[print$] Shares 387
20.6.2.3 Installing Driver Files into [print$] 388
20.6.2.4 smbclient to Confirm Driver Installation 389
Contents xxxi

20.6.2.5 Running rpcclient with adddriver 391

20.6.2.6 Checking adddriver Completion 392
20.6.2.7 Check Samba for Driver Recognition 393
20.6.2.8 Specific Driver Name Flexibility 394
20.6.2.9 Running rpcclient with setdriver 395
20.7 Client Driver Installation Procedure 396
20.7.1 First Client Driver Installation 396
20.7.2 Setting Device Modes on New Printers 397
20.7.3 Additional Client Driver Installation 399
20.7.4 Always Make First Client Connection as root or “printer
admin” 400
20.8 Other Gotchas 401
20.8.1 Setting Default Print Options for Client Drivers 401
20.8.2 Supporting Large Numbers of Printers 403
20.8.3 Adding New Printers with the Windows NT APW 405
20.8.4 Error Message: “Cannot connect under a different
Name” 407
20.8.5 Take Care When Assembling Driver Files 408
20.8.6 Samba and Printer Ports 411
20.8.7 Avoiding Common Client Driver Misconfiguration 412
20.9 The Imprints Toolset 412
20.9.1 What Is Imprints? 412
20.9.2 Creating Printer Driver Packages 413
20.9.3 The Imprints Server 413
20.9.4 The Installation Client 413
20.10 Adding Network Printers without User Interaction 414
20.11 The addprinter Command 416
20.12 Migration of Classical Printing to Samba 417
20.13 Publishing Printer Information in Active Directory or LDAP 418
20.14 Common Errors 418
20.14.1 I Give My Root Password but I Do Not Get Access 418
20.14.2 My Print Jobs Get Spooled into the Spooling Direc-
tory, but Then Get Lost 418

Chapter 21 CUPS PRINTING SUPPORT 419

21.1 Introduction 419
21.1.1 Features and Benefits 419
21.1.2 Overview 419
21.2 Basic CUPS Support Configuration 420
21.2.1 Linking smbd with libcups.so 420
xxxii Contents

21.2.2 Simple smb.conf Settings for CUPS 421

21.2.3 More Complex CUPS smb.conf Settings 422
21.3 Advanced Configuration 424
21.3.1 Central Spooling vs. “Peer-to-Peer” Printing 424
21.3.2 Raw Print Serving: Vendor Drivers on Windows Clients424
21.3.3 Installation of Windows Client Drivers 425
21.3.4 Explicitly Enable “raw” Printing for application/octet-
stream 426
21.3.5 Driver Upload Methods 427
21.4 Advanced Intelligent Printing with PostScript Driver Download428
21.4.1 GDI on Windows, PostScript on UNIX 428
21.4.2 Windows Drivers, GDI, and EMF 429
21.4.3 UNIX Printfile Conversion and GUI Basics 429
21.4.4 PostScript and Ghostscript 431
21.4.5 Ghostscript: The Software RIP for Non-PostScript
Printers 432
21.4.6 PostScript Printer Description (PPD) Specification 433
21.4.7 Using Windows-Formatted Vendor PPDs 434
21.4.8 CUPS Also Uses PPDs for Non-PostScript Printers 435
21.5 The CUPS Filtering Architecture 436
21.5.1 MIME Types and CUPS Filters 437
21.5.2 MIME Type Conversion Rules 438
21.5.3 Filtering Overview 439
21.5.3.1 Filter Requirements 439
21.5.4 Prefilters 440
21.5.5 pstops 440
21.5.6 pstoraster 441
21.5.7 imagetops and imagetoraster 443
21.5.8 rasterto [printers specific] 443
21.5.9 CUPS Backends 444
21.5.10 The Role of cupsomatic/foomatic 447
21.5.11 The Complete Picture 448
21.5.12 mime.convs 448
21.5.13 “Raw” Printing 449
21.5.14 application/octet-stream Printing 449
21.5.15 PostScript Printer Descriptions for Non-PostScript Print-
ers 451
21.5.16 cupsomatic/foomatic-rip Versus Native CUPS Printing 451
21.5.17 Examples for Filtering Chains 453
21.5.18 Sources of CUPS Drivers/PPDs 455
Contents xxxiii

21.5.19 Printing with Interface Scripts 456

21.6 Network Printing (Purely Windows) 457
21.6.1 From Windows Clients to an NT Print Server 457
21.6.2 Driver Execution on the Client 457
21.6.3 Driver Execution on the Server 458
21.7 Network Printing (Windows Clients and UNIX/Samba Print
Servers) 459
21.7.1 From Windows Clients to a CUPS/Samba Print Server 459
21.7.2 Samba Receiving Job-Files and Passing Them to CUPS460
21.8 Network PostScript RIP 461
21.8.1 PPDs for Non-PS Printers on UNIX 461
21.8.2 PPDs for Non-PS Printers on Windows 462
21.9 Windows Terminal Servers (WTS) as CUPS Clients 462
21.9.1 Printer Drivers Running in “Kernel Mode” Cause Many
Problems 462
21.9.2 Workarounds Impose Heavy Limitations 463
21.9.3 CUPS: A “Magical Stone”? 463
21.9.4 PostScript Drivers with No Major Problems, Even in
Kernel Mode 463
21.10 Configuring CUPS for Driver Download 464
21.10.1 cupsaddsmb: The Unknown Utility 464
21.10.2 Prepare Your smb.conf for cupsaddsmb 465
21.10.3 CUPS “PostScript Driver for Windows NT/200x/XP” 465
21.10.4 Recognizing Different Driver Files 467
21.10.5 Acquiring the Adobe Driver Files 468
21.10.6 ESP Print Pro PostScript Driver for Windows NT/200x/XP468
21.10.7 Caveats to Be Considered 469
21.10.8 Windows CUPS PostScript Driver Versus Adobe Driver472
21.10.9 Run cupsaddsmb (Quiet Mode) 473
21.10.10 Run cupsaddsmb with Verbose Output 473
21.10.11 Understanding cupsaddsmb 475
21.10.12 How to Recognize If cupsaddsmb Completed Success-
fully 476
21.10.13 cupsaddsmb with a Samba PDC 477
21.10.14 cupsaddsmb Flowchart 478
21.10.15 Installing the PostScript Driver on a Client 478
21.10.16 Avoiding Critical PostScript Driver Settings on the
Client 479
21.11 Installing PostScript Driver Files Manually Using rpcclient 480
21.11.1 A Check of the rpcclient man Page 481
xxxiv Contents

21.11.2 Understanding the rpcclient man Page 481

21.11.3 Producing an Example by Querying a Windows Box 482
21.11.4 Requirements for adddriver and setdriver to Succeed 483
21.11.5 Manual Driver Installation in 15 Steps 484
21.11.6 Troubleshooting Revisited 491
21.12 The Printing *.tdb Files 491
21.12.1 Trivial Database Files 492
21.12.2 Binary Format 492
21.12.3 Losing *.tdb Files 492
21.12.4 Using tdbbackup 493
21.13 CUPS Print Drivers from Linuxprinting.org 493
21.13.1 foomatic-rip and Foomatic Explained 494
21.13.1.1 690 “Perfect” Printers 495
21.13.1.2 How the Printing HOWTO Started It All 495
21.13.1.3 Foomatic’s Strange Name 496
21.13.1.4 cupsomatic, pdqomatic, lpdomatic, directomatic496
21.13.1.5 The Grand Unification Achieved 497
21.13.1.6 Driver Development Outside 498
21.13.1.7 Forums, Downloads, Tutorials, Howtos (Also
for Mac OS X and Commercial UNIX) 499
21.13.1.8 Foomatic Database-Generated PPDs 500
21.13.2 foomatic-rip and Foomatic PPD Download and Instal-
lation 501
21.14 Page Accounting with CUPS 504
21.14.1 Setting Up Quotas 504
21.14.2 Correct and Incorrect Accounting 505
21.14.3 Adobe and CUPS PostScript Drivers for Windows
Clients 505
21.14.4 The page log File Syntax 506
21.14.5 Possible Shortcomings 506
21.14.6 Future Developments 507
21.14.7 Other Accounting Tools 508
21.15 Additional Material 508
21.16 Autodeletion or Preservation of CUPS Spool Files 510
21.16.1 CUPS Configuration Settings Explained 510
21.16.2 Preconditions 510
21.16.3 Manual Configuration 511
21.17 Printing from CUPS to Windows-Attached Printers 511
21.18 More CUPS Filtering Chains 513
21.19 Common Errors 513
Contents xxxv

21.19.1 Windows 9x/Me Client Can’t Install Driver 513

21.19.2 “cupsaddsmb” Keeps Asking for Root Password in
Never-ending Loop 513
21.19.3 “cupsaddsmb” or “rpcclient addriver” Keeps Giving
WERR BAD PASSWORD 514
21.19.4 “cupsaddsmb” Errors 515
21.19.5 Client Can’t Connect to Samba Printer 515
21.19.6 New Account Reconnection from Windows 200x/XP
Troubles 515
21.19.7 Avoid Being Connected to the Samba Server as the
Wrong User 516
21.19.8 Upgrading to CUPS Drivers from Adobe Drivers 516
21.19.9 Can’t Use “cupsaddsmb” on Samba Server, Which Is
a PDC 516
21.19.10 Deleted Windows 200x Printer Driver Is Still Shown 516
21.19.11 Windows 200x/XP Local Security Policies 516
21.19.12 Administrator Cannot Install Printers for All Local
Users 517
21.19.13 Print Change, Notify Functions on NT Clients 517
21.19.14 Win XP-SP1 517
21.19.15 Print Options for All Users Can’t Be Set on Windows
200x/XP 517
21.19.16 Most Common Blunders in Driver Settings on Win-
dows Clients 518
21.19.17 cupsaddsmb Does Not Work with Newly Installed
Printer 519
21.19.18 Permissions on /var/spool/samba/ Get Reset After
Each Reboot 519
21.19.19 Print Queue Called “lp” Mishandles Print Jobs 519
21.19.20 Location of Adobe PostScript Driver Files for “cup-
saddsmb” 520
21.20 Overview of the CUPS Printing Processes 520

Chapter 22 STACKABLE VFS MODULES 523

22.1 Features and Benefits 523
22.2 Discussion 523
22.3 Included Modules 524
22.3.1 audit 524
22.3.2 extd audit 525
22.3.2.1 Configuration of Auditing 525
xxxvi Contents

22.3.3 fake perms 526

22.3.4 recycle 526
22.3.5 netatalk 527
22.3.6 shadow copy 527
22.3.6.1 Shadow Copy Setup 529
22.4 VFS Modules Available Elsewhere 532
22.4.1 DatabaseFS 532
22.4.2 vscan 533

Chapter 23 WINBIND: USE OF DOMAIN ACCOUNTS 534

23.1 Features and Benefits 534
23.2 Introduction 535
23.3 What Winbind Provides 536
23.3.1 Target Uses 537
23.3.2 Handling of Foreign SIDs 537
23.4 How Winbind Works 538
23.4.1 Microsoft Remote Procedure Calls 538
23.4.2 Microsoft Active Directory Services 539
23.4.3 Name Service Switch 539
23.4.4 Pluggable Authentication Modules 540
23.4.5 User and Group ID Allocation 541
23.4.6 Result Caching 541
23.5 Installation and Configuration 542
23.5.1 Introduction 542
23.5.2 Requirements 542
23.5.3 Testing Things Out 543
23.5.3.1 Configure nsswitch.conf and the Winbind Li-
braries on Linux and Solaris 543
23.5.3.2 NSS Winbind on AIX 544
23.5.3.3 Configure smb.conf 545
23.5.3.4 Join the Samba Server to the PDC Domain 546
23.5.3.5 Starting and Testing the winbindd Daemon 546
23.5.3.6 Fix the init.d Startup Scripts 548
23.5.3.7 Configure Winbind and PAM 552
23.6 Conclusion 556
23.7 Common Errors 556
23.7.1 NSCD Problem Warning 557
23.7.2 Winbind Is Not Resolving Users and Groups 557

Chapter 24 ADVANCED NETWORK MANAGEMENT 559

Contents xxxvii

24.1 Features and Benefits 559

24.2 Remote Server Administration 559
24.3 Remote Desktop Management 560
24.3.1 Remote Management from NoMachine.Com 560
24.4 Network Logon Script Magic 562
24.4.1 Adding Printers without User Intervention 565
24.4.2 Limiting Logon Connections 565

Chapter 25 SYSTEM AND ACCOUNT POLICIES 567

25.1 Features and Benefits 567
25.2 Creating and Managing System Policies 568
25.2.1 Windows 9x/ME Policies 569
25.2.2 Windows NT4-Style Policy Files 569
25.2.2.1 Registry Spoiling 570
25.2.3 MS Windows 200x/XP Professional Policies 570
25.2.3.1 Administration of Windows 200x/XP Policies 571
25.3 Managing Account/User Policies 572
25.4 Management Tools 574
25.4.1 Samba Editreg Toolset 574
25.4.2 Windows NT4/200x 574
25.4.3 Samba PDC 574
25.5 System Startup and Logon Processing Overview 574
25.6 Common Errors 576
25.6.1 Policy Does Not Work 576

Chapter 26 DESKTOP PROFILE MANAGEMENT 577

26.1 Features and Benefits 577
26.2 Roaming Profiles 577
26.2.1 Samba Configuration for Profile Handling 578
26.2.1.1 NT4/200x User Profiles 578
26.2.1.2 Windows 9x/Me User Profiles 579
26.2.1.3 Mixed Windows 9x/Me and Windows NT4/200x
User Profiles 579
26.2.1.4 Disabling Roaming Profile Support 580
26.2.2 Windows Client Profile Configuration Information 581
26.2.2.1 Windows 9x/Me Profile Setup 581
26.2.2.2 Windows NT4 Workstation 584
26.2.2.3 Windows 2000/XP Professional 584
26.2.3 User Profile Hive Cleanup Service 586
xxxviii Contents

26.2.4 Sharing Profiles between Windows 9x/Me and NT4/200x/XP

Workstations 587
26.2.5 Profile Migration from Windows NT4/200x Server to
Samba 587
26.2.5.1 Windows NT4 Profile Management Tools 587
26.2.5.2 Side Bar Notes 588
26.2.5.3 moveuser.exe 588
26.2.5.4 Get SID 589
26.3 Mandatory Profiles 589
26.4 Creating and Managing Group Profiles 590
26.5 Default Profile for Windows Users 590
26.5.1 MS Windows 9x/Me 591
26.5.1.1 User Profile Handling with Windows 9x/Me 591
26.5.2 MS Windows NT4 Workstation 591
26.5.3 MS Windows 200x/XP 594
26.6 Common Errors 597
26.6.1 Configuring Roaming Profiles for a Few Users or Groups597
26.6.2 Cannot Use Roaming Profiles 598
26.6.3 Changing the Default Profile 600

Chapter 27 PAM-BASED DISTRIBUTED AUTHENTICATION601

27.1 Features and Benefits 601
27.2 Technical Discussion 603
27.2.1 PAM Configuration Syntax 603
27.2.1.1 Anatomy of /etc/pam.d Entries 604
27.2.2 Example System Configurations 609
27.2.2.1 PAM: Original Login Config 610
27.2.2.2 PAM: Login Using pam smbpass 610
27.2.3 smb.conf PAM Configuration 612
27.2.4 Remote CIFS Authentication Using winbindd.so 613
27.2.5 Password Synchronization Using pam smbpass.so 614
27.2.5.1 Password Synchronization Configuration 614
27.2.5.2 Password Migration Configuration 615
27.2.5.3 Mature Password Configuration 616
27.2.5.4 Kerberos Password Integration Configuration 616
27.3 Common Errors 617
27.3.1 pam winbind Problem 617
27.3.2 Winbind Is Not Resolving Users and Groups 618

Chapter 28 INTEGRATING MS WINDOWS NETWORKS WITH

Contents xxxix

SAMBA 620
28.1 Features and Benefits 620
28.2 Background Information 621
28.3 Name Resolution in a Pure UNIX/Linux World 621
28.3.1 /etc/hosts 622
28.3.2 /etc/resolv.conf 623
28.3.3 /etc/host.conf 623
28.3.4 /etc/nsswitch.conf 624
28.4 Name Resolution as Used within MS Windows Networking 625
28.4.1 The NetBIOS Name Cache 627
28.4.2 The LMHOSTS File 627
28.4.3 HOSTS File 629
28.4.4 DNS Lookup 629
28.4.5 WINS Lookup 630
28.5 Common Errors 630
28.5.1 Pinging Works Only One Way 631
28.5.2 Very Slow Network Connections 631
28.5.3 Samba Server Name-Change Problem 631

Chapter 29 UNICODE/CHARSETS 633

29.1 Features and Benefits 633
29.2 What Are Charsets and Unicode? 633
29.3 Samba and Charsets 634
29.4 Conversion from Old Names 635
29.5 Japanese Charsets 635
29.5.1 Basic Parameter Setting 636
29.5.2 Individual Implementations 639
29.5.3 Migration from Samba-2.2 Series 640
29.6 Common Errors 641
29.6.1 CP850.so Can’t Be Found 641

Chapter 30 BACKUP TECHNIQUES 642

30.1 Features and Benefits 642
30.2 Discussion of Backup Solutions 642
30.2.1 BackupPC 643
30.2.2 Rsync 643
30.2.3 Amanda 644
30.2.4 BOBS: Browseable Online Backup System 644

Chapter 31 HIGH AVAILABILITY 645

xl Contents

31.1 Features and Benefits 645

31.2 Technical Discussion 646
31.2.1 The Ultimate Goal 646
31.2.2 Why Is This So Hard? 646
31.2.2.1 The Front-End Challenge 647
31.2.2.2 Demultiplexing SMB Requests 647
31.2.2.3 The Distributed File System Challenge 648
31.2.2.4 Restrictive Constraints on Distributed File
Systems 648
31.2.2.5 Server Pool Communications 649
31.2.2.6 Server Pool Communications Demands 649
31.2.2.7 Required Modifications to Samba 649
31.2.3 A Simple Solution 650
31.2.4 High-Availability Server Products 650
31.2.5 MS-DFS: The Poor Man’s Cluster 651
31.2.6 Conclusions 651

Chapter 32 HANDLING LARGE DIRECTORIES 652

Part IV Migration and Updating 653

Chapter 33 UPGRADING FROM SAMBA-2.X TO SAMBA-

3.0.20 655
33.1 Quick Migration Guide 655
33.2 New Features in Samba-3 656
33.3 Configuration Parameter Changes 657
33.3.1 Removed Parameters 657
33.3.2 New Parameters 658
33.3.3 Modified Parameters (Changes in Behavior) 660
33.4 New Functionality 661
33.4.1 Databases 661
33.4.2 Changes in Behavior 662
33.4.3 Passdb Backends and Authentication 662
33.4.4 LDAP 663
33.4.4.1 New Schema 663
33.4.4.2 New Suffix for Searching 664
33.4.4.3 IdMap LDAP Support 665

Chapter 34 MIGRATION FROM NT4 PDC TO SAMBA-3

Contents xli

PDC 666
34.1 Planning and Getting Started 666
34.1.1 Objectives 666
34.1.1.1 Domain Layout 668
34.1.1.2 Server Share and Directory Layout 669
34.1.1.3 Logon Scripts 669
34.1.1.4 Profile Migration/Creation 670
34.1.1.5 User and Group Accounts 670
34.1.2 Steps in Migration Process 670
34.2 Migration Options 671
34.2.1 Planning for Success 672
34.2.2 Samba-3 Implementation Choices 672

Chapter 35 SWAT: THE SAMBA WEB ADMINISTRATION

TOOL 676
35.1 Features and Benefits 676
35.2 Guidelines and Technical Tips 677
35.2.1 Validate SWAT Installation 677
35.2.1.1 Locating the SWAT File 678
35.2.1.2 Locating the SWAT Support Files 678
35.2.2 Enabling SWAT for Use 680
35.2.3 Securing SWAT through SSL 682
35.2.4 Enabling SWAT Internationalization Support 682
35.3 Overview and Quick Tour 683
35.3.1 The SWAT Home Page 683
35.3.2 Global Settings 684
35.3.3 Share Settings 685
35.3.4 Printers Settings 685
35.3.5 The SWAT Wizard 685
35.3.6 The Status Page 686
35.3.7 The View Page 686
35.3.8 The Password Change Page 686

Part V Troubleshooting 687

Chapter 36 THE SAMBA CHECKLIST 689

36.1 Introduction 689
36.2 Assumptions 689
36.3 The Tests 690
xlii Contents

Chapter 37 ANALYZING AND SOLVING SAMBA PROB-

LEMS 698
37.1 Diagnostics Tools 698
37.1.1 Debugging with Samba Itself 698
37.1.2 Tcpdump 699
37.1.3 Ethereal 699
37.1.4 The Windows Network Monitor 699
37.1.4.1 Installing Network Monitor on an NT Work-
station 700
37.1.4.2 Installing Network Monitor on Windows 9x/Me702
37.2 Useful URLs 702
37.3 Getting Mailing List Help 702
37.4 How to Get Off the Mailing Lists 704

Chapter 38 REPORTING BUGS 705

38.1 Introduction 705
38.2 General Information 705
38.3 Debug Levels 706
38.3.1 Debugging-Specific Operations 707
38.4 Internal Errors 707
38.5 Attaching to a Running Process 708
38.6 Patches 709

Part VI Reference Section 709

Chapter 39 HOW TO COMPILE SAMBA 711

39.1 Access Samba Source Code via Subversion 711
39.1.1 Introduction 711
39.1.2 Subversion Access to samba.org 711
39.1.2.1 Access via SVNweb 712
39.1.2.2 Access via Subversion 712
39.2 Accessing the Samba Sources via rsync and ftp 713
39.3 Verifying Samba’s PGP Signature 713
39.4 Building the Binaries 714
39.4.1 Compiling Samba with Active Directory Support 715
39.4.1.1 Installing the Required Packages for Debian 716
39.4.1.2 Installing the Required Packages for Red Hat
Linux 716
39.4.1.3 SuSE Linux Package Requirements 716
Contents xliii

39.5 Starting the smbd nmbd and winbindd 717

39.5.1 Starting from inetd.conf 717
39.5.2 Alternative: Starting smbd as a Daemon 719
39.5.2.1 Starting Samba for Red Hat Linux 719
39.5.2.2 Starting Samba for Novell SUSE Linux 720

Chapter 40 PORTABILITY 722

40.1 HPUX 722
40.2 SCO UNIX 723
40.3 DNIX 723
40.4 Red Hat Linux 725
40.5 AIX: Sequential Read Ahead 725
40.6 Solaris 725
40.6.1 Locking Improvements 725
40.6.2 Winbind on Solaris 9 726

Chapter 41 SAMBA AND OTHER CIFS CLIENTS 727

41.1 Macintosh Clients 727
41.2 OS2 Client 728
41.2.1 Configuring OS/2 Warp Connect or OS/2 Warp 4 728
41.2.2 Configuring Other Versions of OS/2 728
41.2.3 Printer Driver Download for OS/2 Clients 729
41.3 Windows for Workgroups 729
41.3.1 Latest TCP/IP Stack from Microsoft 729
41.3.2 Delete .pwl Files After Password Change 730
41.3.3 Configuring Windows for Workgroups Password Han-
dling 730
41.3.4 Password Case Sensitivity 730
41.3.5 Use TCP/IP as Default Protocol 731
41.3.6 Speed Improvement 731
41.4 Windows 95/98 731
41.4.1 Speed Improvement 732
41.5 Windows 2000 Service Pack 2 732
41.6 Windows NT 3.1 733

Chapter 42 SAMBA PERFORMANCE TUNING 734

42.1 Comparisons 734
42.2 Socket Options 734
42.3 Read Size 735
42.4 Max Xmit 736
xliv Contents

42.5 Log Level 736

42.6 Read Raw 736
42.7 Write Raw 736
42.8 Slow Logins 737
42.9 Client Tuning 737
42.10 Samba Performance Problem Due to Changing Linux Kernel 737
42.11 Corrupt tdb Files 738
42.12 Samba Performance is Very Slow 738

Chapter A GNU GENERAL PUBLIC LICENSE 739

A.1 Preamble 739
A.2 TERMS AND CONDITIONS FOR COPYING, DISTRIBU-
TION AND MODIFICATION 740
A.2.1 Section 0 740
A.2.2 Section 1 741
A.2.3 Section 2 741
A.2.4 Section 3 742
A.2.5 Section 4 743
A.2.6 Section 5 743
A.2.7 Section 6 744
A.2.8 Section 7 744
A.2.9 Section 8 745
A.2.10 Section 9 745
A.2.11 Section 10 745
A.2.12 NO WARRANTY Section 11 746
A.2.13 Section 12 746
A.3 How to Apply These Terms to Your New Programs 746

GLOSSARY 749

SUBJECT INDEX 753

Index 786
List of Figures

4 Domain Control
4.1 An Example Domain. 55

8 MS Windows Network Configuration Guide

8.1 Network Bridge Configuration. 122
8.2 Internet Protocol (TCP/IP) Properties. 123
8.3 Advanced Network Settings 124
8.4 DNS Configuration. 125
8.5 WINS Configuration 126
8.6 Local Area Connection Properties. 127
8.7 Internet Protocol (TCP/IP) Properties. 128
8.8 Advanced Network Settings. 129
8.9 DNS Configuration. 130
8.10 WINS Configuration. 131
8.11 The Windows Me Network Configuration Panel. 132
8.12 IP Address. 133
8.13 DNS Configuration. 134
8.14 WINS Configuration. 134
8.15 The General Panel. 135
8.16 The Computer Name Panel. 136
8.17 The Computer Name Changes Panel. 136
8.18 The Computer Name Changes Panel — Domain MIDEARTH. 137
8.19 Computer Name Changes — Username and PasswordPanel. 137
8.20 The Network Panel. 138
8.21 Client for Microsoft Networks Properties Panel. 138
8.22 Identification Panel. 139
8.23 Access Control Panel. 139

9 Network Browsing
9.1 Cross-Subnet Browsing Example. 169

xlv
xlvi LIST OF FIGURES

10 Account Information Databases

10.1 IDMAP: Resolution of SIDs to UIDs. 179
10.2 IDMAP: Resolution of UIDs to SIDs. 180

11 Group Mapping: MS Windows and UNIX

11.1 IDMAP: Group SID-to-GID Resolution. 213
11.2 IDMAP: GID Resolution to Matching SID. 214
11.3 IDMAP Storing Group Mappings. 214

15 File, Directory, and Share Access Controls

15.1 Overview of UNIX permissions field. 297

18 Interdomain Trust Relationships

18.1 Trusts overview. 349

21 CUPS Printing Support

21.1 Windows Printing to a Local Printer. 430
21.2 Printing to a PostScript Printer. 432
21.3 Ghostscript as a RIP for Non-PostScript Printers. 432
21.4 Prefiltering in CUPS to Form PostScript. 441
21.5 Adding Device-Specific Print Options. 441
21.6 PostScript to Intermediate Raster Format. 442
21.7 CUPS-Raster Production Using Ghostscript. 443
21.8 Image Format to CUPS-Raster Format Conversion. 444
21.9 Raster to Printer-Specific Formats. 445
21.10 cupsomatic/foomatic Processing Versus Native CUPS. 453
21.11 PDF to Socket Chain. 454
21.12 PDF to USB Chain. 455
21.13 Print Driver Execution on the Client. 458
21.14 Print Driver Execution on the Server. 458
21.15 Printing via CUPS/Samba Server. 460
21.16 cupsaddsmb Flowchart. 478
21.17 Filtering Chain 1. 514
21.18 Filtering Chain with cupsomatic 521
21.19 CUPS Printing Overview. 522

23 Winbind: Use of Domain Accounts

LIST OF FIGURES xlvii

23.1 Winbind Idmap 536

37 Analyzing and Solving Samba Problems

37.1 Starting a Capture. 700
37.2 Main Ethereal Data Window. 701
List of Tables

5 Backup Domain Control

5.1 Domain Backend Account Distribution Options 82

6 Domain Membership
6.1 Assumptions 102

9 Network Browsing
9.1 Browse Subnet Example 1 170
9.2 Browse Subnet Example 2 170
9.3 Browse Subnet Example 3 171
9.4 Browse Subnet Example 4 171

10 Account Information Databases

10.1 Attributes in the sambaSamAccount ObjectClass (LDAP),
Part A 208
10.2 Attributes in the sambaSamAccount ObjectClass (LDAP),
Part B 209
10.3 Possible ldap passwd sync Values 209
10.4 Basic smb.conf Options for MySQL passdb Backend 209
10.5 MySQL field names for MySQL passdb backend 210

11 Group Mapping: MS Windows and UNIX

11.1 Well-Known User Default RIDs 221

14 User Rights and Privileges

14.1 Current Privilege Capabilities 284

15 File, Directory, and Share Access Controls

15.1 Managing Directories with UNIX and Windows 296
15.2 User- and Group-Based Controls 301

xlviii
LIST OF TABLES xlix

15.3 File and Directory Permission-Based Controls 302

15.4 Other Controls 318
15.5 How Windows File ACLs Map to UNIX POSIX File ACLs 319

20 Classical Printing Support

20.1 Default Printing Settings 374

21 CUPS Printing Support

21.1 PPDs Shipped with CUPS 452

22 Stackable VFS modules

22.1 Extended Auditing Log Information 525

26 Desktop Profile Management

26.1 User Shell Folder Registry Keys Default Values 594
26.2 Defaults of Profile Settings Registry Keys 594
26.3 Defaults of Default User Profile Paths Registry Keys 596

27 PAM-Based Distributed Authentication

27.1 Options recognized by pam smbpass 615

28 Integrating MS Windows Networks with Samba

28.1 Unique NetBIOS Names 625
28.2 Group Names 625

29 Unicode/Charsets
29.1 Japanese Character Sets in Samba-2.2 and Samba-3 641

33 Upgrading from Samba-2.x to Samba-3.0.20

33.1 TDB File Descriptions 661

34 Migration from NT4 PDC to Samba-3 PDC

34.1 The Three Major Site Types 672
34.2 Nature of the Conversion Choices 673
l LIST OF TABLES

38 Reporting Bugs
38.1 Debuggable Functions 707
PREFACE AND
INTRODUCTION

“A man’s gift makes room for him before great men. Gifts are like hooks
that can catch hold of the mind taking it beyond the reach of forces that
otherwise might constrain it.” — Anon.
This is a book about Samba. It is a tool, a derived work of the labors of
many and of the diligence and goodwill of more than a few. This book
contains material that has been contributed in a persistent belief that each
of us can add value to our neighbors as well as to those who will follow us.
This book is designed to meet the needs of the Microsoft network adminis-
trator. UNIX administrators will benefit from this book also, though they
may complain that it is hard to find the information they think they need.
So if you are a Microsoft certified specialist, this book should meet your
needs rather well. If you are a UNIX or Linux administrator, there is no
need to feel badly — you should have no difficulty finding answers to your
current concerns also.

What Is Samba?

Samba is a big, complex project. The Samba project is ambitious and excit-
ing. The team behind Samba is a group of some thirty individuals who are
spread the world over and come from an interesting range of backgrounds.
This team includes scientists, engineers, programmers, business people, and
students.
Team members were drawn into active participation through the desire to
help deliver an exciting level of transparent interoperability between Mi-
crosoft Windows and the non-Microsoft information technology world.
The slogan that unites the efforts behind the Samba project says: Samba,
Opening Windows to a Wider World! The goal behind the project is one of
removing barriers to interoperability.

li
lii Preface and Introduction

Samba provides file and print services for Microsoft Windows clients. These
services may be hosted off any TCP/IP-enabled platform. The original
deployment platforms were UNIX and Linux, though today it is in common
use across a broad variety of systems.

The Samba project includes not only an impressive feature set in file and
print serving capabilities, but has been extended to include client function-
ality, utilities to ease migration to Samba, tools to aid interoperability with
Microsoft Windows, and administration tools.

The real people behind Samba are users like you. You have inspired the
developers (the Samba Team) to do more than any of them imagined could
or should be done. User feedback drives Samba development. Samba-3
in particular incorporates a huge amount of work done as a result of user
requests, suggestions and direct code contributions.

Why This Book?

There is admittedly a large number of Samba books on the market today and
each book has its place. Despite the apparent plethora of books, Samba as
a project continues to receive much criticism for failing to provide sufficient
documentation. Samba is also criticized for being too complex and too
difficult to configure. In many ways this is evidence of the success of Samba
as there would be no complaints if it was not successful.

The Samba Team members work predominantly with UNIX and Linux, so it
is hardly surprising that existing Samba documentation should reflect that
orientation. The original HOWTO text documents were intended to provide
some tips, a few golden nuggets, and if they helped anyone then that was just
wonderful. But the HOWTO documents lacked structure and context. They
were isolated snapshots of information that were written to pass information
on to someone else who might benefit. They reflected a need to transmit
more information that could be conveniently put into manual pages.

The original HOWTO documents were written by different authors. Most

HOWTO documents are the result of feedback and contributions from nu-
merous authors. In this book we took care to preserve as much original
content as possible. As you read this book you will note that chapters were
written by multiple authors, each of whom has his own style. This demon-
strates the nature of the Open Source software development process.
Preface and Introduction liii

Out of the original HOWTO documents sprang a collection of unofficial

HOWTO documents that are spread over the Internet. It is sincerely in-
tended that this work will not replace the valuable unofficial HOWTO work
that continues to flourish. If you are involved in unofficial HOWTO produc-
tion then please continue your work!

Those of you who have dedicated your labors to the production of unoffi-
cial HOWTOs, to Web page information regarding Samba, or to answering
questions on the mailing lists or elsewhere, may be aware that this is a la-
bor of love. We would like to know about your contribution and willingly
receive the precious pearls of wisdom you have collected. Please email your
contribution to John H. Terpstra ([email protected])115 . As a service to other
users we will gladly adopt material that is technically accurate.

Existing Samba books are largely addressed to the UNIX administrator.

From the perspective of this target group the existing books serve an ade-
quate purpose, with one exception — now that Samba-3 is out they need to
be updated!

This book, the Official Samba-3 HOWTO and Reference Guide, includes the
Samba-HOWTO-Collection.pdf that ships with Samba. These documents
have been written with a new design intent and purpose.

Over the past two years many Microsoft network administrators have adopted
Samba and have become interested in its deployment. Their information
needs are very different from that of the UNIX administrator. This book
has been arranged and the information presented from the perspective of
someone with previous Microsoft Windows network administrative training
and experience.

Book Structure and Layout

This book is presented in six parts:

General Installation Designed to help you get Samba-3 running quickly.

The Fast Start chapter is a direct response to requests from Microsoft
network administrators for some sample configurations that just work.

115
<mailto:[email protected]>
liv Preface and Introduction

Server Configuration Basics The purpose of this section is to aid the

transition from existing Microsoft Windows network knowledge to
Samba terminology and norms. The chapters in this part each cover
the installation of one type of Samba server.

Advanced Configuration The mechanics of network browsing have long

been the Achilles heel of all Microsoft Windows users. Samba-3 in-
troduces new user and machine account management facilities, a new
way to map UNIX groups and Windows groups, Interdomain trusts,
new loadable file system drivers (VFS), and more. New with this
document is expanded printing documentation, as well as a wealth of
information regarding desktop and user policy handling, use of desk-
top profiles, and techniques for enhanced network integration. This
section makes up the core of the book. Read and enjoy.

Migration and Updating A much requested addition to the book is in-

formation on how to migrate from Microsoft Windows NT4 to Samba-
3, as well as an overview of what the issues are when moving from
Samba-2.x to Samba-3.

Troubleshooting This short section should help you when all else fails.

Appendix Here you will find a collection of things that are either too
peripheral for most users, or are a little left of field to be included in
the main body of information.
Welcome to Samba-3 and the first published document to help you and
your users to enjoy a whole new world of interoperability between Microsoft
Windows and the rest of the world.
 Part I

General Installation
PREPARING SAMBA FOR
CONFIGURATION

This section of the Samba-HOWTO-Collection contains general info on how

to install Samba and how to configure the parts of Samba you will most
likely need. PLEASE read this.

1
Chapter 1

HOW TO INSTALL AND

TEST SAMBA

1.1 Obtaining and Installing Samba

Binary packages of Samba are included in almost any Linux or UNIX distri-
bution. There are also some packages available at the Samba home page1 .
Refer to the manual of your operating system for details on installing pack-
ages for your specific operating system.
If you need to compile Samba from source, check Chapter 39, “How to
Compile Samba”.

1.2 Configuring Samba (smb.conf)

Samba’s configuration is stored in the smb.conf file, which usually resides

in /etc/samba/smb.conf or /usr/local/samba/lib/smb.conf. You can
either edit this file yourself or do it using one of the many graphical tools
that are available, such as the Web-based interface SWAT, that is included
with Samba.

1.2.1 Configuration File Syntax

The smb.conf file uses the same syntax as the various old .ini files in
Windows 3.1: Each file consists of various sections, which are started by
putting the section name between brackets ([]) on a new line. Each contains
1
<http://samba.org/>

2
Section 1.2. Configuring Samba (smb.conf) 3

zero or more key/value pairs separated by an equality sign (=). The file is
just a plaintext file, so you can open and edit it with your favorite editing
tool.
Each section in the smb.conf file represents either a share or a meta-service
on the Samba server. The section [global] is special, since it contains
settings that apply to the whole Samba server. Samba supports a number
of meta-services, each of which serves its own purpose. For example, the
[homes] share is a meta-service that causes Samba to provide a personal
home share for each user. The [printers] share is a meta-service that
establishes print queue support and that specifies the location of the inter-
mediate spool directory into which print jobs are received from Windows
clients prior to being dispatched to the UNIX/Linux print spooler.
Each section of the smb.conf file that specifies a share, or a meta-service, is
called a stanza. The global stanza specifies settings that affect all the other
stanzas in the smb.conf file. Configuration parameters are documented in
the smb.conf man page. Some parameters can be used only in the global
stanza, some only in share or meta-service stanzas, and some can be used
globally or just within a share or meta-service stanza.
Example 1.2.1 contains a very minimal smb.conf.

Example 1.2.1. A minimal smb.conf

 
[ global ]
workgroup = WKG
n e t b i o s name = MYNAME
[ share1 ]
path = /tmp
[ share2 ]
path = / m y s h a r e d f o l d e r
comment = Some random f i l e s
 

1.2.2 Starting Samba

Samba essentially consists of two or three daemons. A daemon is a UNIX

application that runs in the background and provides services. An example
of a service is the Apache Web server for which the daemon is called httpd.
4 How to Install and Test SAMBA Chapter 1

In the case of Samba there are three daemons, two of which are needed as a
minimum.

The Samba server is made up of the following daemons:

nmbd This daemon handles all name registration and resolution requests.
It is the primary vehicle involved in network browsing. It handles all
UDP-based protocols. The nmbd daemon should be the first com-
mand started as part of the Samba startup process.

smbd This daemon handles all TCP/IP-based connection services for file-
and print-based operations. It also manages local authentication. It
should be started immediately following the startup of nmbd.

winbindd This daemon should be started when Samba is a member of a

Windows NT4 or ADS domain. It is also needed when Samba has
trust relationships with another domain. The winbindd daemon will
check the smb.conf file for the presence of the idmap uid and idmap
gid parameters. If they are not found, winbindd will bail out and
refuse to start.

When Samba has been packaged by an operating system vendor, the startup
process is typically a custom feature of its integration into the platform
as a whole. Please refer to your operating system platform administration
manuals for specific information pertaining to correct management of Samba
startup.

1.2.3 Example Configuration

There are sample configuration files in the examples subdirectory in the

source code distribution tarball pacakge. It is suggested you read them
carefully so you can see how the options go together in practice. See the
man page for all the options. It might be worthwhile to start out with the
smb.conf.default configuration file and adapt it to your needs. It contains
plenty of comments.

The simplest useful configuration file would contain something like that
shown in Example 1.2.2.
Section 1.2. Configuring Samba (smb.conf) 5

Example 1.2.2. Another simple smb.conf File

 
[ global ]
workgroup = MIDEARTH
[ homes ]
g u e s t ok = no
r e a d o n l y = no
 

This will allow connections by anyone with an account on the server, using
either their login name or homes as the service name. (Note: The workgroup
that Samba should appear in must also be set. The default workgroup name
is WORKGROUP.)
Make sure you put the smb.conf file in the correct place. Note, the correct
location of this file depends on how the binary files were built. You can
discover the correct location by executing from the directory that contains
the smbd command file:

root# smbd -b | grep smb.conf

For more information about security settings for the [homes] share, please
refer to Chapter 17, “Securing Samba”.

1.2.3.1 Test Your Config File with testparm

It’s important to validate the contents of the smb.conf file using the test-
parm program. If testparm runs correctly, it will list the loaded services. If
not, it will give an error message. Make sure it runs correctly and that the
services look reasonable before proceeding. Enter the command:

root# testparm /etc/samba/smb.conf

Testparm will parse your configuration file and report any unknown param-
eters or incorrect syntax. It also performs a check for common misconfigu-
rations and will issue a warning if one is found.
Always run testparm again whenever the smb.conf file is changed!
6 How to Install and Test SAMBA Chapter 1

The smb.conf file is constantly checked by the Samba daemons smbd and
every instance of itself that it spawns, nmbd and winbindd. It is good
practice to keep this file as small as possible. Many administrators prefer
to document Samba configuration settings and thus the need to keep this
file small goes against good documentation wisdom. One solution that may
be adopted is to do all documentation and configuration in a file that has
another name, such as smb.conf.master. The testparm utility can be used
to generate a fully optimized smb.conf file from this master configuration
and documtenation file as shown here:

root# testparm -s smb.conf.master > smb.conf

This administrative method makes it possible to maitain detailed configura-

tion change records while at the same time keeping the working smb.conf
file size to the minimum necessary.

1.2.4 SWAT

SWAT is a Web-based interface that can be used to facilitate the configu-

ration of Samba. SWAT might not be available in the Samba package that
shipped with your platform, but in a separate package. If it is necesaary to
built SWAT please read the SWAT man page regarding compilation, instal-
lation, and configuration of SWAT from the source code.

To launch SWAT, just run your favorite Web browser and point it to <http:
//localhost:901/>. Replace localhost with the name of the computer
on which Samba is running if that is a different computer than your browser.

SWAT can be used from a browser on any IP-connected machine, but be

aware that connecting from a remote machine leaves your connection open
to password sniffing because passwords will be sent over the wire in the
clear.

More information about SWAT can be found in Chapter 35, “SWAT: The
Samba Web Administration Tool”.
Section 1.3. List Shares Available on the Server 7

1.3 List Shares Available on the Server

To list shares that are available from the configured Samba server, execute
the following command:

$ smbclient -L yourhostname

You should see a list of shares available on your server. If you do not, then
something is incorrectly configured. This method can also be used to see
what shares are available on other SMB servers, such as Windows 2000.

If you choose user-level security, you may find that Samba requests a pass-
word before it will list the shares. See the smbclient man page for details.
You can force it to list the shares without a password by adding the option
-N to the command line.

1.4 Connect with a UNIX Client

Enter the following command:

$ smbclient //yourhostname/aservice

Typically yourhostname is the name of the host on which smbd has been
installed. The aservice is any service that has been defined in the smb.
conf file. Try your username if you just have a [homes] section in the smb.
conf file.

Example: If the UNIX host is called bambi and a valid login name is fred,
you would type:

$ smbclient //bambi/fred
8 How to Install and Test SAMBA Chapter 1

1.5 Connect from a Remote SMB Client

Now that Samba is working correctly locally, you can try to access it from
other clients. Within a few minutes, the Samba host should be listed in the
Network Neighborhood on all Windows clients of its subnet. Try browsing
the server from another client or ”mounting” it.
Mounting disks from a DOS, Windows, or OS/2 client can be done by run-
ning a command such as:

C:\> net use m: \\servername\service

Where the drive letter m: is any available drive letter. It is important to

double-check that the service (share) name that you used does actually exist.
Try printing, for example,

C:\> net use lpt1: \\servername\spoolservice

The spoolservice is the name of the printer (actually the print queue) on
the target server. This will permit all print jobs that are captured by the
lpt1: port on the Windows client to be sent to the printer that owns the
spoolservice that has been specified.
C:\> print filename

1.5.1 What If Things Don’t Work?

You might want to read Chapter 36, “The Samba Checklist”. If you are
still stuck, refer to Chapter 37, “Analyzing and Solving Samba Problems”.
Samba has been successfully installed at thousands of sites worldwide. It is
unlikely that your particular problem is unique, so it might be productive
to perform an Internet search to see if someone else has encountered your
problem and has found a way to overcome it.
If you are new to Samba, and particularly if you are new to Windows net-
working, or to UNIX/Linux, the book “Samba-3 by Example” will help you
to create a validated network environment. Simply choose from the first
Section 1.6. Common Errors 9

five chapters the network design that most closely matches site needs, then
follow the simple step-by-step procedure to deploy it. Later, when you have
a working network you may well want to refer back to this book for further
insight into opportunities for improvement.

1.5.2 Still Stuck?

The best advice under the stress of abject frustration is to cool down! That
may be challenging of itself, but while you are angry or annoyed your ability
to seek out a solution is somewhat undermined. A cool head clears the way
to finding the answer you are looking for. Just remember, every problem
has a solution — there is a good chance that someone else has found it
even though you can’t right now. That will change with time, patience and
learning.

Now that you have cooled down a bit, please refer to Chapter 36, “The
Samba Checklist” for a process that can be followed to identify the cause of
your problem.

1.6 Common Errors

The following questions and issues are raised repeatedly on the Samba mail-
ing list.

1.6.1 Large Number of smbd Processes

Samba consists of three core programs: nmbd, smbd, and winbindd. nmbd
is the name server message daemon, smbd is the server message daemon,
and winbindd is the daemon that handles communication with domain con-
trollers.

If Samba is not running as a WINS server, then there will be one single
instance of nmbd running on your system. If it is running as a WINS server,
then there will be two instances — one to handle the WINS requests.

smbd handles all connection requests. It spawns a new process for each
client connection made. That is why you may see so many of them, one per
client connection.
10 How to Install and Test SAMBA Chapter 1

winbindd will run as one or two daemons, depending on whether or not it

is being run in split mode (in which case there will be two instances).

1.6.2 Error Message: open oplock ipc

An error message is observed in the log files when smbd is started: “open oplock ipc:
Failed to get local UDP socket for address 100007f. Error was Cannot assign
requested.”
Your loopback device isn’t working correctly. Make sure it is configured
correctly. The loopback device is an internal (virtual) network device with
the IP address 127.0.0.1. Read your OS documentation for details on how
to configure the loopback on your system.

1.6.3 “The network name cannot be found”

This error can be caused by one of these misconfigurations:

• You specified a nonexisting path for the share in smb.conf.
• The user you are trying to access the share with does not have sufficient
permissions to access the path for the share. Both read (r) and access
(x) should be possible.
• The share you are trying to access does not exist.
Chapter 2

FAST START: CURE FOR

IMPATIENCE

When we first asked for suggestions for inclusion in the Samba HOWTO
documentation, someone wrote asking for example configurations — and lots
of them. That is remarkably difficult to do without losing a lot of value that
can be derived from presenting many extracts from working systems. That
is what the rest of this document does. It does so with extensive descriptions
of the configuration possibilities within the context of the chapter that covers
it. We hope that this chapter is the medicine that has been requested.

The information in this chapter is very sparse compared with the book
“Samba-3 by Example” that was written after the original version of this
book was nearly complete. “Samba-3 by Example” was the result of feed-
back from reviewers during the final copy editing of the first edition. It was
interesting to see that reader feedback mirrored that given by the original
reviewers. In any case, a month and a half was spent in doing basic research
to better understand what new as well as experienced network administra-
tors would best benefit from. The book “Samba-3 by Example” is the result
of that research. What is presented in the few pages of this book is covered
far more comprehensively in the second edition of “Samba-3 by Example”.
The second edition of both books will be released at the same time.

So in summary, the book “The Official Samba-3 HOWTO & Reference

Guide” is intended as the equivalent of an auto mechanic’s repair guide.
The book “Samba-3 by Example” is the equivalent of the driver’s guide that
explains how to drive the car. If you want complete network configuration
examples, go to “Samba-3 by Example”.

11
12 Fast Start: Cure for Impatience Chapter 2

2.1 Features and Benefits

Samba needs very little configuration to create a basic working system. In

this chapter we progress from the simple to the complex, for each providing
all steps and configuration file changes needed to make each work. Please
note that a comprehensively configured system will likely employ additional
smart features. These additional features are covered in the remainder of
this document.
The examples used here have been obtained from a number of people who
made requests for example configurations. All identities have been obscured
to protect the guilty, and any resemblance to unreal nonexistent sites is
deliberate.

2.2 Description of Example Sites

In the first set of configuration examples we consider the case of exceptionally

simple system requirements. There is a real temptation to make something
that should require little effort much too complex.
Section 2.3.1.1 documents the type of server that might be sufficient to
serve CD-ROM images, or reference document files for network client use.
This configuration is also discussed in Chapter 7, “Standalone Servers”,
Section 7.3.1. The purpose for this configuration is to provide a shared
volume that is read-only that anyone, even guests, can access.
The second example shows a minimal configuration for a print server that
anyone can print to as long as they have the correct printer drivers installed
on their computer. This is a mirror of the system described in Chapter 7,
“Standalone Servers”, Section 7.3.2.
The next example is of a secure office file and print server that will be
accessible only to users who have an account on the system. This server is
meant to closely resemble a workgroup file and print server, but has to be
more secure than an anonymous access machine. This type of system will
typically suit the needs of a small office. The server provides no network
logon facilities, offers no domain control; instead it is just a network-attached
storage (NAS) device and a print server.
The later example consider more complex systems that will either integrate
into existing MS Windows networks or replace them entirely. These cover
Section 2.3. Worked Examples 13

domain member servers as well as Samba domain control (PDC/BDC) and

finally describes in detail a large distributed network with branch offices in
remote locations.

2.3 Worked Examples

The configuration examples are designed to cover everything necessary to

get Samba running. They do not cover basic operating system platform
configuration, which is clearly beyond the scope of this text.
It is also assumed that Samba has been correctly installed, either by way
of installation of the packages that are provided by the operating system
vendor or through other means.

2.3.1 Standalone Server

A standalone server implies no more than the fact that it is not a domain
controller and it does not participate in domain control. It can be a simple,
workgroup-like server, or it can be a complex server that is a member of a
domain security context.
As the examples are developed, every attempt is made to progress the system
toward greater capability, just as one might expect would happen in a real
business office as that office grows in size and its needs change.

2.3.1.1 Anonymous Read-Only Document Server

The purpose of this type of server is to make available to any user any doc-
uments or files that are placed on the shared resource. The shared resource
could be a CD-ROM drive, a CD-ROM image, or a file storage area.
• The file system share point will be /export.
• All files will be owned by a user called Jack Baumbach. Jack’s login
name will be jackb. His password will be m0r3pa1n — of course,
that’s just the example we are using; do not use this in a production
environment because all readers of this document will know it.
Installation Procedure: Read-Only Server
1. Add user to system (with creation of the user’s home directory):
14 Fast Start: Cure for Impatience Chapter 2

Example 2.3.1. Anonymous Read-Only Server Configuration

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = HOBBIT
sec urity = share
[ data ]
comment = Data
path = / e x p o r t
r e a d o n l y = Yes
g u e s t ok = Yes
 

root# useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb

2. Create directory, and set permissions and ownership:

root# mkdir /export

root# chmod u+rwx,g+rx,o+rx /export
root# chown jackb.users /export

3. Copy the files that should be shared to the /export directory.

4. Install the Samba configuration file (/etc/samba/smb.conf) as shown
in Example 2.3.1.
5. Test the configuration file by executing the following command:

root# testparm

Alternately, where you are operating from a master configuration file

called smb.conf.master, the following sequence of commands might
prove more appropriate:

root# cd /etc/samba
Section 2.3. Worked Examples 15

root# testparm -s smb.conf.master > smb.conf

root# testparm

Note any error messages that might be produced. Proceed only if

error-free output has been obtained. An example of typical output
that should be generated from the above configuration file is shown
here:

Load smb config files from /etc/samba/smb.conf

Processing section "[data]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
[Press enter]

# Global parameters
[global]
workgroup = MIDEARTH
netbios name = HOBBIT
security = share

[data]
comment = Data
path = /export
read only = Yes
guest only = Yes

6. Start Samba using the method applicable to your operating system

platform. The method that should be used is platform dependant. Re-
fer to Section 39.5 for further information regarding starting of Samba.

7. Configure your MS Windows client for workgroup MIDEARTH, set the

machine name to ROBBINS, reboot, wait a few (2 - 5) minutes, then
open Windows Explorer and visit the Network Neighborhood. The
machine HOBBIT should be visible. When you click this machine
icon, it should open up to reveal the data share. After you click the
share, it should open up to reveal the files previously placed in the /
export directory.
16 Fast Start: Cure for Impatience Chapter 2

The information above (following # Global parameters) provides the com-

plete contents of the /etc/samba/smb.conf file.

2.3.1.2 Anonymous Read-Write Document Server

We should view this configuration as a progression from the previous exam-

ple. The difference is that shared access is now forced to the user identity of
jackb and to the primary group jackb belongs to. One other refinement we
can make is to add the user jackb to the smbpasswd file. To do this, execute:

root# smbpasswd -a jackb

New SMB password: m0r3pa1n
Retype new SMB password: m0r3pa1n
Added user jackb.

Addition of this user to the smbpasswd file allows all files to be displayed
in the Explorer Properties boxes as belonging to jackb instead of to User
Unknown.

The complete, modified smb.conf file is as shown in Example 2.3.2.

Example 2.3.2. Modified Anonymous Read-Write smb.conf

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = HOBBIT
s e c u r i t y = SHARE
[ data ]
comment = Data
path = / e x p o r t
f o r c e user = jackb
f o r c e group = u s e r s
r e a d o n l y = No
g u e s t ok = Yes
 
Section 2.3. Worked Examples 17

2.3.1.3 Anonymous Print Server

An anonymous print server serves two purposes:

• It allows printing to all printers from a single location.
• It reduces network traffic congestion due to many users trying to access
a limited number of printers.
In the simplest of anonymous print servers, it is common to require the
installation of the correct printer drivers on the Windows workstation. In
this case the print server will be designed to just pass print jobs through to
the spooler, and the spooler should be configured to do raw pass-through
to the printer. In other words, the print spooler should not filter or process
the data stream being passed to the printer.
In this configuration, it is undesirable to present the Add Printer Wizard,
and we do not want to have automatic driver download, so we disable it in
the following configuration. Example 2.3.3 is the resulting smb.conf file.

Example 2.3.3. Anonymous Print Server smb.conf

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = LUTHIEN
se curity = share
p r i n t c a p name = cups
d i s a b l e s p o o l s s = Yes
show add p r i n t e r w i z a r d = No
p r i n t i n g = cups
[ printers ]
comment = A l l P r i n t e r s
path = / var / s p o o l /samba
g u e s t ok = Yes
p r i n t a b l e = Yes
u s e c l i e n t d r i v e r = Yes
b r o w s e a b l e = No
 

The above configuration is not ideal. It uses no smart features, and it

deliberately presents a less than elegant solution. But it is basic, and it
18 Fast Start: Cure for Impatience Chapter 2

does print. Samba makes use of the direct printing application program
interface that is provided by CUPS. When Samba has been compiled and
linked with the CUPS libraries the default printing system will be CUPS.
By specifying that the printcap name is CUPS, Samba will use the CUPS
library API to communicate directly with CUPS for all printer functions.
It is possible to force the use of external printing commands by setting the
value of the printing to either SYSV or BSD, and thus the value of the
parameter printcap name must be set to something other than CUPS. In
such case, it could be set to the name of any file that contains a list of
printers that should be made available to Windows clients.

Note

Windows users will need to install a local printer and then

change the print to device after installation of the drivers.
The print to device can then be set to the network printer
on this machine.

Make sure that the directory /var/spool/samba is capable of being used as

intended. The following steps must be taken to achieve this:
• The directory must be owned by the superuser (root) user and group:

root# chown root.root /var/spool/samba

• Directory permissions should be set for public read-write with the

sticky bit set as shown:

root# chmod a+twrx /var/spool/samba

The purpose of setting the sticky bit is to prevent who does not own
the temporary print file from being able to take control of it with the
potential for devious misuse.
Section 2.3. Worked Examples 19

Note

On CUPS-enabled systems there is a facility to pass raw

data directly to the printer without intermediate process-
ing via CUPS print filters. Where use of this mode of
operation is desired, it is necessary to configure a raw
printing device. It is also necessary to enable the raw
mime handler in the /etc/mime.conv and /etc/mime.
types files. Refer to Section 21.3.4.

2.3.1.4 Secure Read-Write File and Print Server

We progress now from simple systems to a server that is slightly more com-
plex.
Our new server will require a public data storage area in which only au-
thenticated users (i.e., those with a local account) can store files, as well
as a home directory. There will be one printer that should be available for
everyone to use.
In this hypothetical environment (no espionage was conducted to obtain this
data), the site is demanding a simple environment that is secure enough but
not too difficult to use.
Site users will be Jack Baumbach, Mary Orville, and Amed Sehkah. Each
will have a password (not shown in further examples). Mary will be the
printer administrator and will own all files in the public share.
This configuration will be based on user-level security that is the default, and
for which the default is to store Microsoft Windows-compatible encrypted
passwords in a file called /etc/samba/smbpasswd. The default smb.conf
entry that makes this happen is passdb backend = smbpasswd, guest. Since
this is the default, it is not necessary to enter it into the configuration file.
Note that the guest backend is added to the list of active passdb backends
no matter whether it specified directly in Samba configuration file or not.
Installing the Secure Office Server
1. Add all users to the operating system:
20 Fast Start: Cure for Impatience Chapter 2

Example 2.3.4. Secure Office Server smb.conf

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = OLORIN
p r i n t c a p name = cups
d i s a b l e s p o o l s s = Yes
show add p r i n t e r w i z a r d = No
p r i n t i n g = cups
[ homes ]
comment = Home D i r e c t o r i e s
v a l i d u s e r s = %S
r e a d o n l y = No
b r o w s e a b l e = No
[ public ]
comment = Data
path = / e x p o r t
f o r c e u s e r = maryo
f o r c e group = u s e r s
g u e s t ok = Yes
r e a d o n l y = No
[ printers ]
comment = A l l P r i n t e r s
path = / var / s p o o l /samba
p r i n t e r admin = r o o t , maryo
c r e a t e mask = 0600
g u e s t ok = Yes
p r i n t a b l e = Yes
u s e c l i e n t d r i v e r = Yes
b r o w s e a b l e = No
 

root# useradd -c "Jack Baumbach" -m -g users -p m0r3pa1n jackb

root# useradd -c "Mary Orville" -m -g users -p secret maryo
root# useradd -c "Amed Sehkah" -m -g users -p secret ameds

2. Configure the Samba smb.conf file as shown in Example 2.3.4.

Section 2.3. Worked Examples 21

3. Initialize the Microsoft Windows password database with the new

users:

root# smbpasswd -a root

New SMB password: bigsecret
Reenter smb password: bigsecret
Added user root.

root# smbpasswd -a jackb

New SMB password: m0r3pa1n
Retype new SMB password: m0r3pa1n
Added user jackb.

root# smbpasswd -a maryo

New SMB password: secret
Reenter smb password: secret
Added user maryo.

root# smbpasswd -a ameds

New SMB password: mysecret
Reenter smb password: mysecret
Added user ameds.

4. Install printer using the CUPS Web interface. Make certain that all
printers that will be shared with Microsoft Windows clients are in-
stalled as raw printing devices.
5. Start Samba using the operating system administrative interface. Al-
ternately, this can be done manually by executing:

root# nmbd; smbd;

Both applications automatically execute as daemons. Those who are

paranoid about maintaining control can add the -D flag to coerce them
to start up in daemon mode.
6. Configure the /export directory:
22 Fast Start: Cure for Impatience Chapter 2

root# mkdir /export

root# chown maryo.users /export
root# chmod u=rwx,g=rwx,o-rwx /export

7. Check that Samba is running correctly:

root# smbclient -L localhost -U%

Domain=[MIDEARTH] OS=[UNIX] Server=[Samba-3.0.20]

Sharename Type Comment

--------- ---- -------
public Disk Data
IPC$ IPC IPC Service (Samba-3.0.20)
ADMIN$ IPC IPC Service (Samba-3.0.20)
hplj4 Printer hplj4

Server Comment
--------- -------
OLORIN Samba-3.0.20

Workgroup Master
--------- -------
MIDEARTH OLORIN

The following error message indicates that Samba was not running:

root# smbclient -L olorin -U%

Error connecting to 192.168.1.40 (Connection refused)
Connection to olorin failed

8. Connect to OLORIN as maryo:

root# smbclient //olorin/maryo -Umaryo%secret

OS=[UNIX] Server=[Samba-3.0.20]
smb: \> dir
. D 0 Sat Jun 21 10:58:16 2003
.. D 0 Sat Jun 21 10:54:32 2003
Section 2.3. Worked Examples 23

Documents D 0 Fri Apr 25 13:23:58 2003

DOCWORK D 0 Sat Jun 14 15:40:34 2003
OpenOffice.org D 0 Fri Apr 25 13:55:16 2003
.bashrc H 1286 Fri Apr 25 13:23:58 2003
.netscape6 DH 0 Fri Apr 25 13:55:13 2003
.mozilla DH 0 Wed Mar 5 11:50:50 2003
.kermrc H 164 Fri Apr 25 13:23:58 2003
.acrobat DH 0 Fri Apr 25 15:41:02 2003

55817 blocks of size 524288. 34725 blocks available

smb: \> q

By now you should be getting the hang of configuration basics. Clearly, it is

time to explore slightly more complex examples. For the remainder of this
chapter we abbreviate instructions, since there are previous examples.

2.3.2 Domain Member Server

In this instance we consider the simplest server configuration we can get

away with to make an accounting department happy. Let’s be warned, the
users are accountants and they do have some nasty demands. There is a
budget for only one server for this department.
The network is managed by an internal Information Services Group (ISG),
to which we belong. Internal politics are typical of a medium-sized organi-
zation; Human Resources is of the opinion that they run the ISG because
they are always adding and disabling users. Also, departmental managers
have to fight tooth and nail to gain basic network resources access for their
staff. Accounting is different, though, they get exactly what they want. So
this should set the scene.
We use the users from the last example. The accounting department has a
general printer that all departmental users may use. There is also a check
printer that may be used only by the person who has authority to print
checks. The chief financial officer (CFO) wants that printer to be completely
restricted and for it to be located in the private storage area in her office.
It therefore must be a network printer.
The accounting department uses an accounting application called SpytFull
that must be run from a central application server. The software is licensed
24 Fast Start: Cure for Impatience Chapter 2

to run only off one server, there are no workstation components, and it is
run off a mapped share. The data store is in a UNIX-based SQL backend.
The UNIX gurus look after that, so this is not our problem.

The accounting department manager (maryo) wants a general filing system

as well as a separate file storage area for form letters (nastygrams). The form
letter area should be read-only to all accounting staff except the manager.
The general filing system has to have a structured layout with a general
area for all staff to store general documents as well as a separate file area
for each member of her team that is private to that person, but she wants
full access to all areas. Users must have a private home share for personal
work-related files and for materials not related to departmental operations.

2.3.2.1 Example Configuration

The server valinor will be a member server of the company domain. Ac-
counting will have only a local server. User accounts will be on the domain
controllers, as will desktop profiles and all network policy files.

Example 2.3.5. Member server smb.conf (globals)

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = VALINOR
s e c u r i t y = DOMAIN
p r i n t c a p name = cups
d i s a b l e s p o o l s s = Yes
show add p r i n t e r w i z a r d = No
idmap u i d = 15000 −20000
idmap g i d = 15000 −20000
winbind u s e d e f a u l t domain = Yes
p r i n t i n g = cups
 

1. Do not add users to the UNIX/Linux server; all of this will run off the
central domain.

2. Configure smb.conf according to Example 2.3.5 and Example 2.3.6.

Section 2.3. Worked Examples 25

Example 2.3.6. Member server smb.conf (shares and services)

 
[ homes ]
comment = Home D i r e c t o r i e s
v a l i d u s e r s = %S
r e a d o n l y = No
b r o w s e a b l e = No
[ spytfull ]
comment = Accounting A p p l i c a t i o n Only
path = / e x p o r t / s p y t f u l l
v a l i d u s e r s = @Accounts
admin u s e r s = maryo
r e a d o n l y = Yes
[ public ]
comment = Data
path = / e x p o r t / p u b l i c
r e a d o n l y = No
[ printers ]
comment = A l l P r i n t e r s
path = / var / s p o o l /samba
p r i n t e r admin = r o o t , maryo
c r e a t e mask = 0600
g u e s t ok = Yes
p r i n t a b l e = Yes
u s e c l i e n t d r i v e r = Yes
b r o w s e a b l e = No
 

3. Join the domain. Note: Do not start Samba until this step has been
completed!

root# net rpc join -Uroot%’bigsecret’

Joined domain MIDEARTH.

4. Make absolutely certain that you disable (shut down) the nscd daemon
on any system on which winbind is configured to run.

5. Start Samba following the normal method for your operating system
26 Fast Start: Cure for Impatience Chapter 2

platform. If you wish to do this manually, execute as root:

root# nmbd; smbd; winbindd;

6. Configure the name service switch (NSS) control file on your system
to resolve user and group names via winbind. Edit the following lines
in /etc/nsswitch.conf:

passwd: files winbind

group: files winbind
hosts: files dns winbind

7. Set the password for wbinfo to use:

root# wbinfo --set-auth-user=root%’bigsecret’

8. Validate that domain user and group credentials can be correctly re-
solved by executing:

root# wbinfo -u
MIDEARTH\maryo
MIDEARTH\jackb
MIDEARTH\ameds
...
MIDEARTH\root

root# wbinfo -g
MIDEARTH\Domain Users
MIDEARTH\Domain Admins
MIDEARTH\Domain Guests
...
MIDEARTH\Accounts

9. Check that winbind is working. The following demonstrates correct

username resolution via the getent system utility:
Section 2.3. Worked Examples 27

root# getent passwd maryo

maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false

10. A final test that we have this under control might be reassuring:

root# touch /export/a_file

root# chown maryo /export/a_file
root# ls -al /export/a_file
...
-rw-r--r-- 1 maryo users 11234 Jun 21 15:32 a_file
...

root# rm /export/a_file

11. Configuration is now mostly complete, so this is an opportune time to

configure the directory structure for this site:

root# mkdir -p /export/{spytfull,public}

root# chmod ug=rwxS,o=x /export/{spytfull,public}
root# chown maryo.Accounts /export/{spytfull,public}

2.3.3 Domain Controller

For the remainder of this chapter the focus is on the configuration of do-
main control. The examples that follow are for two implementation strate-
gies. Remember, our objective is to create a simple but working solution.
The remainder of this book should help to highlight opportunity for greater
functionality and the complexity that goes with it.
A domain controller configuration can be achieved with a simple configura-
tion using the new tdbsam password backend. This type of configuration
is good for small offices, but has limited scalability (cannot be replicated),
and performance can be expected to fall as the size and complexity of the
domain increases.
The use of tdbsam is best limited to sites that do not need more than
28 Fast Start: Cure for Impatience Chapter 2

a Primary Domain Controller (PDC). As the size of a domain grows the

need for additional domain controllers becomes apparent. Do not attempt
to under-resource a Microsoft Windows network environment; domain con-
trollers provide essential authentication services. The following are symp-
toms of an under-resourced domain control environment:
• Domain logons intermittently fail.
• File access on a domain member server intermittently fails, giving a
permission denied error message.
A more scalable domain control authentication backend option might use
Microsoft Active Directory or an LDAP-based backend. Samba-3 provides
for both options as a domain member server. As a PDC, Samba-3 is not
able to provide an exact alternative to the functionality that is available with
Active Directory. Samba-3 can provide a scalable LDAP-based PDC/BDC
solution.
The tdbsam authentication backend provides no facility to replicate the
contents of the database, except by external means (i.e., there is no self-
contained protocol in Samba-3 for Security Account Manager database [SAM]
replication).

Note

If you need more than one domain controller, do not use

a tdbsam authentication backend.

2.3.3.1 Example: Engineering Office

The engineering office network server we present here is designed to demon-

strate use of the new tdbsam password backend. The tdbsam facility is new
to Samba-3. It is designed to provide many user and machine account con-
trols that are possible with Microsoft Windows NT4. It is safe to use this
in smaller networks.
1. A working PDC configuration using the tdbsam password backend can
be found in Example 2.3.7 together with Example 2.3.8:
Section 2.3. Worked Examples 29

2. Create UNIX group accounts as needed using a suitable operating

system tool:

root# groupadd ntadmins

root# groupadd designers
root# groupadd engineers
root# groupadd qateam

3. Create user accounts on the system using the appropriate tool provided
with the operating system. Make sure all user home directories are
created also. Add users to groups as required for access control on files,
directories, printers, and as required for use in the Samba environment.
4. Assign each of the UNIX groups to NT groups by executing this shell
script (You could name the script initGroups.sh):

#!/bin/bash
#### Keep this as a shell script for future re-use

# First assign well known groups

net groupmap modify ntgroup="Domain Admins" unixgroup=ntadmins
net groupmap modify ntgroup="Domain Users" unixgroup=users
net groupmap modify ntgroup="Domain Guests" unixgroup=nobody

# Now for our added Domain Groups

net groupmap add ntgroup="Designers" unixgroup=designers type=d
net groupmap add ntgroup="Engineers" unixgroup=engineers type=d
net groupmap add ntgroup="QA Team" unixgroup=qateam type=d

5. Create the scripts directory for use in the [NETLOGON] share:

root# mkdir -p /var/lib/samba/netlogon/scripts

Place the logon scripts that will be used (batch or cmd scripts) in this
directory.
The above configuration provides a functional PDC system to which must
be added file shares and printers as required.
30 Fast Start: Cure for Impatience Chapter 2

2.3.3.2 A Big Organization

In this section we finally get to review in brief a Samba-3 configuration that

uses a Lightweight Directory Access (LDAP)-based authentication backend.
The main reasons for this choice are to provide the ability to host primary
and Backup Domain Control (BDC), as well as to enable a higher degree of
scalability to meet the needs of a very distributed environment.

The Primary Domain Controller This is an example of a minimal configura-

tion to run a Samba-3 PDC using an LDAP authentication backend. It is
assumed that the operating system has been correctly configured.
The Idealx scripts (or equivalent) are needed to manage LDAP-based POSIX
and/or SambaSamAccounts. The Idealx scripts may be downloaded from
the Idealx1 Web site. They may also be obtained from the Samba tarball.
Linux distributions tend to install the Idealx scripts in the /usr/share/doc/
packages/sambaXXXXXX/examples/LDAP/smbldap-tools directory. Idealx
scripts version smbldap-tools-0.9.1 are known to work well.
1. Obtain from the Samba sources ~/examples/LDAP/samba.schema and
copy it to the /etc/openldap/schema/ directory.
2. Set up the LDAP server. This example is suitable for OpenLDAP
2.1.x. The /etc/openldap/slapd.conf file. Example slapd.conf file

# Note commented out lines have been removed

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

database bdb
suffix "dc=quenya,dc=org"
rootdn "cn=Manager,dc=quenya,dc=org"
rootpw {SSHA}06qDkonA8hk6W6SSnRzWj0/pBcU3m0/P
1
<http://www.idealx.org>
Section 2.3. Worked Examples 31

# The password for the above is ’nastyon3’

directory /var/lib/ldap

index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub

3. Create the following file initdb.ldif:

# Organization for SambaXP Demo

dn: dc=quenya,dc=org
objectclass: dcObject
objectclass: organization
dc: quenya
o: SambaXP Demo
description: The SambaXP Demo LDAP Tree

# Organizational Role for Directory Management

dn: cn=Manager,dc=quenya,dc=org
objectclass: organizationalRole
cn: Manager
description: Directory Manager

# Setting up the container for users

dn: ou=People, dc=quenya, dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
32 Fast Start: Cure for Impatience Chapter 2

# Set up an admin handle for People OU

dn: cn=admin, ou=People, dc=quenya, dc=org
cn: admin
objectclass: top
objectclass: organizationalRole
objectclass: simpleSecurityObject
userPassword: {SSHA}0jBHgQ1vp4EDX2rEMMfIudvRMJoGwjVb
# The password for above is ’mordonL8’

4. Load the initial data above into the LDAP database:

root# slapadd -v -l initdb.ldif

5. Start the LDAP server using the appropriate tool or method for the
operating system platform on which it is installed.
6. Install the Idealx script files in the /usr/local/sbin directory, then
configure the smbldap conf.pm file to match your system configura-
tion.
7. The smb.conf file that drives this backend can be found in example
Example 2.3.9. Add additional stanzas as required.
8. Add the LDAP password to the secrets.tdb file so Samba can update
the LDAP database:

root# smbpasswd -w mordonL8

9. Add users and groups as required. Users and groups added using
Samba tools will automatically be added to both the LDAP backend
and the operating system as required.

Backup Domain Controller Example 2.3.10 shows the example configuration

for the BDC. Note that the smb.conf file does not specify the smbldap-tools
scripts — they are not needed on a BDC. Add additional stanzas for shares
and printers as required.
1. Decide if the BDC should have its own LDAP server or not. If the
BDC is to be the LDAP server, change the following smb.conf as
Section 2.3. Worked Examples 33

indicated. The default configuration in Example 2.3.10 uses a central

LDAP server.
2. Configure the NETLOGON and PROFILES directory as for the PDC
in Example 2.3.10.
34 Fast Start: Cure for Impatience Chapter 2

Example 2.3.7. Engineering Office smb.conf (globals)

 
[ global ]
workgroup = MIDEARTH
n e t b i o s name = FRODO
passdb backend = tdbsam
p r i n t c a p name = cups
add u s e r s c r i p t = / u s r / s b i n / us e radd −m %u
d e l e t e u s e r s c r i p t = / u s r / s b i n / u s e r d e l −r % ←-
u
add group s c r i p t = / u s r / s b i n / groupadd %g
d e l e t e group s c r i p t = / u s r / s b i n / g r o u p d e l %g
add u s e r t o group s c r i p t = / u s r / s b i n / ←-
groupmod −A %u %g
d e l e t e u s e r from group s c r i p t = / u s r / s b i n / ←-
groupmod −R %u %g
add machine s c r i p t = / u s r / s b i n / us e radd −s / ←-
b i n / f a l s e −d / var / l i b / nobody %u
# Note : The f o l l o w i n g s p e c i f i e s t h e d e f a u l t l o g o n ←-
script .
# Per u s e r l o g o n s c r i p t s can be s p e c i f i e d i n t h e ←-
user account using p d b e d i t
l o g o n s c r i p t = s c r i p t s \ l o g o n . bat
# This s e t s t h e d e f a u l t p r o f i l e p a t h . S e t p e r u s e r ←-
paths with pdbedit
l o g o n path = \\%L\ P r o f i l e s \%U
l o g o n d r i v e = H:
l o g o n home = \\%L\%U
domain l o g o n s = Yes
o s l e v e l = 35
p r e f e r r e d master = Yes
domain master = Yes
idmap u i d = 15000 −20000
idmap g i d = 15000 −20000
p r i n t i n g = cups
 
Section 2.3. Worked Examples 35

Example 2.3.8. Engineering Office smb.conf (shares and services)

 
[ homes ]
comment = Home D i r e c t o r i e s
v a l i d u s e r s = %S
r e a d o n l y = No
b r o w s e a b l e = No
# P r i n t i n g auto−s h a r e ( makes p r i n t e r s a v a i l a b l e ←-
t h r u CUPS)
[ printers ]
comment = A l l P r i n t e r s
path = / var / s p o o l /samba
p r i n t e r admin = r o o t , maryo
c r e a t e mask = 0600
g u e s t ok = Yes
p r i n t a b l e = Yes
b r o w s e a b l e = No
[ print$ ]
comment = P r i n t e r D r i v e r s Share
path = / var / l i b /samba/ d r i v e r s
w r i t e l i s t = maryo , r o o t
p r i n t e r admin = maryo , r o o t
# Needed t o s u p p o r t domain l o g o n s
[ netlogon ]
comment = Network Logon S e r v i c e
path = / var / l i b /samba/ n e t l o g o n
admin u s e r s = r o o t , maryo
g u e s t ok = Yes
b r o w s e a b l e = No
# For p r o f i l e s t o work , c r e a t e a u s e r d i r e c t o r y ←-
under t h e p a t h
# shown . i . e . , mkdir −p / v a r / l i b /samba/ p r o f i l e s / ←-
maryo
[ Profiles ]
comment = Roaming P r o f i l e Share
path = / var / l i b /samba/ p r o f i l e s
r e a d o n l y = No
p r o f i l e a c l s = Yes
# Other r e s o u r c e ( s h a r e / p r i n t e r ) d e f i n i t i o n s would ←-
f o l l o w below .
 
36 Fast Start: Cure for Impatience Chapter 2

Example 2.3.9. LDAP backend smb.conf for PDC

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = FRODO
passdb backend = ldapsam : l d a p : / / l o c a l h o s t
username map = / e t c /samba/ smbusers
p r i n t c a p name = cups
add u s e r s c r i p t = / u s r / l o c a l / s b i n / smbldap− ←-
u s e r a dd −m ’%u ’
d e l e t e u s e r s c r i p t = / u s r / l o c a l / s b i n / ←-
smbldap−u s e r d e l %u
add group s c r i p t = / u s r / l o c a l / s b i n / smbldap− ←-
groupadd −p ’%g ’
d e l e t e group s c r i p t = / u s r / l o c a l / s b i n / ←-
smbldap−g r o u p d e l ’%g ’
add u s e r t o group s c r i p t = / u s r / l o c a l / s b i n / ←-
smbldap−groupmod −m ’%u ’ ’%g ’
d e l e t e u s e r from group s c r i p t = / u s r / l o c a l / ←-
s b i n / smbldap−groupmod −x ’%u ’ ’%g ’
s e t primary group s c r i p t = / u s r / l o c a l / s b i n / ←-
smbldap−usermod −g ’%g ’ ’%u ’
add machine s c r i p t = / u s r / l o c a l / s b i n / ←-
smbldap−us e radd −w ’%u ’
l o g o n s c r i p t = s c r i p t s \ l o g o n . bat
l o g o n path = \\%L\ P r o f i l e s \%U
l o g o n d r i v e = H:
l o g o n home = \\%L\%U
domain l o g o n s = Yes
o s l e v e l = 35
p r e f e r r e d master = Yes
domain master = Yes
l d a p s u f f i x = dc=quenya , dc=o r g
l d a p machine s u f f i x = ou=People
l d a p u s e r s u f f i x = ou=People
l d a p group s u f f i x = ou=People
l d a p idmap s u f f i x = ou=People
l d a p admin dn = cn=Manager
l d a p s s l = no
l d a p passwd sync = Yes
idmap u i d = 15000 −20000
idmap g i d = 15000 −20000
p r i n t i n g = cups
 
Section 2.3. Worked Examples 37

Example 2.3.10. Remote LDAP BDC smb.conf

 
# Global parameters
[ global ]
workgroup = MIDEARTH
n e t b i o s name = GANDALF
passdb backend = ldapsam : l d a p : / / f r o d o . ←-
quenya . o r g
username map = / e t c /samba/ smbusers
p r i n t c a p name = cups
l o g o n s c r i p t = s c r i p t s \ l o g o n . bat
l o g o n path = \\%L\ P r o f i l e s \%U
l o g o n d r i v e = H:
l o g o n home = \\%L\%U
domain l o g o n s = Yes
o s l e v e l = 33
p r e f e r r e d master = Yes
domain master = No
l d a p s u f f i x = dc=quenya , dc=o r g
l d a p machine s u f f i x = ou=People
l d a p u s e r s u f f i x = ou=People
l d a p group s u f f i x = ou=People
l d a p idmap s u f f i x = ou=People
l d a p admin dn = cn=Manager
l d a p s s l = no
l d a p passwd sync = Yes
idmap u i d = 15000 −20000
idmap g i d = 15000 −20000
p r i n t i n g = cups
 
 Part II

Server Configuration Basics

FIRST STEPS IN SERVER
CONFIGURATION

Samba can operate in various modes within SMB networks. This HOWTO
section contains information on configuring Samba to function as the type
of server your network requires. Please read this section carefully.

39
Chapter 3

SERVER TYPES AND

SECURITY MODES

This chapter provides information regarding the types of server that Samba
may be configured to be. A Microsoft network administrator who wishes to
migrate to or use Samba will want to know the meaning, within a Samba
context, of terms familiar to the MS Windows administrator. This means
that it is essential also to define how critical security modes function before
we get into the details of how to configure the server itself.
The chapter provides an overview of the security modes of which Samba is
capable and how they relate to MS Windows servers and clients.
A question often asked is, “Why would I want to use Samba?” Most chapters
contain a section that highlights features and benefits. We hope that the
information provided will help to answer this question. Be warned though,
we want to be fair and reasonable, so not all features are positive toward
Samba. The benefit may be on the side of our competition.

3.1 Features and Benefits

Two men were walking down a dusty road, when one suddenly kicked up
a small red stone. It hurt his toe and lodged in his sandal. He took the
stone out and cursed it with a passion and fury befitting his anguish. The
other looked at the stone and said, “This is a garnet. I can turn that into a
precious gem and some day it will make a princess very happy!”
The moral of this tale: Two men, two very different perspectives regarding
the same stone. Like it or not, Samba is like that stone. Treat it the right

40
Section 3.2. Server Types 41

way and it can bring great pleasure, but if you are forced to use it and have
no time for its secrets, then it can be a source of discomfort.
Samba started out as a project that sought to provide interoperability for
MS Windows 3.x clients with a UNIX server. It has grown up a lot since
its humble beginnings and now provides features and functionality fit for
large-scale deployment. It also has some warts. In sections like this one, we
tell of both.
So, what are the benefits of the features mentioned in this chapter?
• Samba-3 can replace an MS Windows NT4 domain controller.
• Samba-3 offers excellent interoperability with MS Windows NT4-style
domains as well as natively with Microsoft Active Directory domains.
• Samba-3 permits full NT4-style interdomain trusts.
• Samba has security modes that permit more flexible authentication
than is possible with MS Windows NT4 domain controllers.
• Samba-3 permits use of multiple concurrent account database back-
ends. (Encrypted passwords that are stored in the account database
are in formats that is unique to Windows networking).
• The account database backends can be distributed and replicated using
multiple methods. This gives Samba-3 greater flexibility than MS
Windows NT4 and in many cases a significantly higher utility than
Active Directory domains with MS Windows 200x.

3.2 Server Types

Administrators of Microsoft networks often refer to three different type of

servers:
• Domain Controller
– Primary Domain Controller (PDC)
– Backup Domain Controller (BDC)
– ADS Domain Controller
• Domain Member Server
– Active Directory Domain Server
42 Server Types and Security Modes Chapter 3

– NT4 Style Domain Domain Server

• Standalone Server
The chapters covering domain control (Chapter 4, “Domain Control”), backup
domain control (Chapter 5, “Backup Domain Control”), and domain mem-
bership (Chapter 6, “Domain Membership”) provide pertinent informa-
tion regarding Samba configuration for each of these server roles. You are
strongly encouraged to become intimately familiar with these chapters be-
cause they lay the foundation for deployment of Samba domain security.
A Standalone server has is autonomous in respect of the source of its ac-
count backend. Refer to Chapter 7, “Standalone Servers” to gain a wider
appreciation of what is mean by a server being configured as a standalone
server.

3.3 Samba Security Modes

In this section the function and purpose of Samba’s security modes are de-
scribed. An accurate understanding of how Samba implements each security
mode as well as how to configure MS Windows clients for each mode will
significantly reduce user complaints and administrator heartache.
Microsoft Windows networking uses a protocol that was originally called the
Server Message Block (SMB) protocol. Since some time around 1996 the
protocol has been better known as the Common Internet Filesystem (CIFS)
protocol.
In the SMB/CIFS networking world, there are only two types of security:
user-level and share level. We refer to these collectively as security levels. In
implementing these two security levels, Samba provides flexibilities that are
not available with MS Windows NT4/200x servers. In fact, Samba imple-
ments share-level security only one way, but has four ways of implementing
user-level security. Collectively, we call the Samba implementations of the
security levels security modes. They are known as share, user, domain, ADS,
and server modes. They are documented in this chapter.
An SMB server informs the client, at the time of a session setup, the security
level the server is running. There are two options: share-level and user-level.
Which of these two the client receives affects the way the client then tries
to authenticate itself. It does not directly affect (to any great extent) the
way the Samba server does security. This may sound strange, but it fits
Section 3.3. Samba Security Modes 43

in with the client/server approach of SMB. In SMB everything is initiated

and controlled by the client, and the server can only tell the client what is
available and whether an action is allowed.

The term client refers to all agents whether it is a Windows workstation,

a Windows server, another Samba server, or any vanilla SMB or CIFS client
application (e.g., smbclient) that make use of services provided by an SM-
B/CIFS server.

3.3.1 User Level Security

We describe user-level security first because its simpler. In user-level se-

curity, the client sends a session setup request directly following protocol
negotiation. This request provides a username and password. The server
can either accept or reject that username/password combination. At this
stage the server has no idea what share the client will eventually try to
connect to, so it can’t base the accept/reject on anything other than:

1. the username/password.

2. the name of the client machine.

If the server accepts the username/password credentials, the client expects to

be able to mount shares (using a tree connection) without further specifying a
password. It expects that all access rights will be as the username/password
credentials set that was specified in the initial session setup.

It is also possible for a client to send multiple session setup requests. When
the server responds, it gives the client a uid to use as an authentication tag
for that username/password. The client can maintain multiple authentica-
tion contexts in this way (WinDD is an example of an application that does
this).

Windows networking user account names are case-insensitive, meaning that

upper-case and lower-case characters in the account name are considered
equivalent. They are said to be case-preserving, but not case significant.
Windows and LanManager systems previous to Windows NT version 3.10
have case-insensitive passwords that were not necessarilty case-preserving.
All Windows NT family systems treat passwords are case-preserving and
case-sensitive.
44 Server Types and Security Modes Chapter 3

3.3.1.1 Example Configuration

The smb.conf parameter that sets user-level security is:

 
security = user
 

This is the default setting since Samba-2.2.x.

3.3.2 Share-Level Security

In share-level security, the client authenticates itself separately for each

share. It sends a password along with each tree connection request (share
mount), but it does not explicitly send a username with this operation. The
client expects a password to be associated with each share, independent of
the user. This means that Samba has to work out what username the client
probably wants to use, the SMB server is not explicitly sent the username.
Some commercial SMB servers such as NT actually associate passwords di-
rectly with shares in share-level security, but Samba always uses the UNIX
authentication scheme where it is a username/password pair that is authen-
ticated, not a share/password pair.
To understand the MS Windows networking parallels, think in terms of MS
Windows 9x/Me where you can create a shared folder that provides read-
only or full access, with or without a password.
Many clients send a session setup request even if the server is in share-level
security. They normally send a valid username but no password. Samba
records this username in a list of possible usernames. When the client then
issues a tree connection request, it also adds to this list the name of the share
they try to connect to (useful for home directories) and any users listed in
the user parameter in the smb.conf file. The password is then checked in
turn against these possible usernames. If a match is found, then the client
is authenticated as that user.
Where the list of possible user names is not provided, Samba checks makes a
UNIX system call to find the user account that has a password that matches
the one provided from the standard account database. On a system that
has no name service switch (NSS) facility such lookups will be from the /
etc/passwd database. On NSS enabled systems the lookup will go to the
libraries that have been specified in the nsswitch.conf file. The entries in
that file in which the libraries are specified are:
Section 3.3. Samba Security Modes 45

passwd: files nis ldap

shadow: files nis ldap
group: files nis ldap

In the example shown here (not likely to be used in practice) the lookup will
check /etc/passwd and /etc/group, if not found it will check NIS, then
LDAP.

3.3.2.1 Example Configuration

The smb.conf parameter that sets share-level security is:

 
sec urity = share
 

3.3.3 Domain Security Mode (User-Level Security)

Domain security provides a mechanism for storing all user and group ac-
counts in a central, shared, account repository. The centralized account
repository is shared between domain (security) controllers. Servers that
act as domain controllers provide authentication and validation services to
all machines that participate in the security context for the domain. A pri-
mary domain controller (PDC) is a server that is responsible for maintaining
the integrity of the security account database. Backup domain controllers
(BDCs) provide only domain logon and authentication services. Usually,
BDCs will answer network logon requests more responsively than will a
PDC.
When Samba is operating in security = domain mode, the Samba server
has a domain security trust account (a machine account) and causes all
authentication requests to be passed through to the domain controllers. In
other words, this configuration makes the Samba server a domain member
server, even when it is in fact acting as a domain controller. All machines
that participate in domain security must have a machine account in the
security database.
Within the domain security environment the underlying security architec-
ture uses User-level security. Even machines that are domain members must
authenticate on startup. The machine account consists of an account entry
46 Server Types and Security Modes Chapter 3

in the accounts database, the name of which is the NetBIOS name of the
machine and of which the password is randomly generated and known to
both the domain controllers and the member machine. If the machine ac-
count can not be validated during startup, users will not be able to log onto
the domain using this machine because it can not be trusted. The machine
account is referred to as a machine trust account.

There are three possible domain member configurations:

1. Primary domain controller (PDC) - of which there is one per domain.

2. Backup domain controller (BDC) - of which there can be any number

per domain.

3. Domain member server (DMS) - of which there can be any number

per domain.

We will discuss each of these in separate chapters. For now, we are most
interested in basic DMS configuration.

3.3.3.1 Example Configuration

Samba as a Domain Member Server

This method involves addition of the following parameters in the smb.conf

file:
 
s e c u r i t y = domain
workgroup = MIDEARTH
 

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

1. On the MS Windows NT domain controller, using the Server Manager,

add a machine account for the Samba server.

2. On the UNIX/Linux system execute:

root# net rpc join -U administrator%password

Section 3.3. Samba Security Modes 47

Note

Samba-2.2.4 and later Samba 2.2.x series releases can

autojoin a Windows NT4-style domain just by executing:

root# smbpasswd -j DOMAIN_NAME -r PDC_NAME \

-U Administrator%password

Samba-3 can do the same by executing:

root# net rpc join -U Administrator%password

It is not necessary with Samba-3 to specify the DO-

MAIN NAME or the PDC NAME, as it figures this out from
the smb.conf file settings.

Use of this mode of authentication requires there to be a standard UNIX

account for each user in order to assign a UID once the account has been au-
thenticated by the Windows domain controller. This account can be blocked
to prevent logons by clients other than MS Windows through means such as
setting an invalid shell in the /etc/passwd entry. The best way to allocate
an invalid shell to a user account is to set the shell to the file /bin/false.

Domain controllers can be located anywhere that is convenient. The best

advice is to have a BDC on every physical network segment, and if the PDC
is on a remote network segment the use of WINS (see Chapter 9, “Network
Browsing” for more information) is almost essential.

An alternative to assigning UIDs to Windows users on a Samba member

server is presented in Chapter 23, “Winbind: Use of Domain Accounts”,
Chapter 23, “Winbind: Use of Domain Accounts”.

For more information regarding domain membership, Chapter 6, “Domain

Membership”.
48 Server Types and Security Modes Chapter 3

3.3.4 ADS Security Mode (User-Level Security)

Both Samba-2.2, and Samba-3 can join an Active Directory domain using
NT4 style RPC based security. This is possible if the domain is run in native
mode. Active Directory in native mode perfectly allows NT4-style domain
members. This is contrary to popular belief.
If you are using Active Directory, starting with Samba-3 you can join as a
native AD member. Why would you want to do that? Your security policy
might prohibit the use of NT-compatible authentication protocols. All your
machines are running Windows 2000 and above and all use Kerberos. In this
case Samba, as an NT4-style domain, would still require NT-compatible au-
thentication data. Samba in AD-member mode can accept Kerberos tickets.
Sites that use Microsoft Windows active directory services (ADS) should be
aware of the significance of the terms: native mode and mixed mode ADS
operation. The term realm is used to describe a Kerberos-based security
architecture (such as is used by Microsoft ADS).

3.3.4.1 Example Configuration

 
realm = your . k e r b e r o s .REALM
s e c u r i t y = ADS
 

The following parameter may be required:

 
password s e r v e r = your . k e r b e r o s . s e r v e r
 

Please refer to Chapter 6, “Domain Membership”, and Section 6.4 for more
information regarding this configuration option.

3.3.5 Server Security (User Level Security)

Server security mode is left over from the time when Samba was not capable
of acting as a domain member server. It is highly recommended not to use
this feature. Server security mode has many drawbacks that include:
• Potential account lockout on MS Windows NT4/200x password servers.
• Lack of assurance that the password server is the one specified.
Section 3.3. Samba Security Modes 49

• Does not work with Winbind, which is particularly needed when stor-
ing profiles remotely.

• This mode may open connections to the password server and keep
them open for extended periods.

• Security on the Samba server breaks badly when the remote password
server suddenly shuts down.

• With this mode there is NO security account in the domain that the
password server belongs to for the Samba server.

In server security mode the Samba server reports to the client that it is
in user-level security. The client then does a session setup as described
earlier. The Samba server takes the username/password that the client
sends and attempts to log into the password server by sending exactly the
same username/password that it got from the client. If that server is in
user-level security and accepts the password, then Samba accepts the client’s
connection. This parameter allows the Samba server to use another SMB
server as the password server.

You should also note that at the start of all this, when the server tells
the client what security level it is in, it also tells the client if it supports
encryption. If it does, it supplies the client with a random cryptkey. The
client will then send all passwords in encrypted form. Samba supports this
type of encryption by default.

The parameter security = server means that Samba reports to clients that it
is running in user mode but actually passes off all authentication requests to
another user mode server. This requires an additional parameter password
server that points to the real authentication server. The real authentication
server can be another Samba server, or it can be a Windows NT server, the
latter being natively capable of encrypted password support.
50 Server Types and Security Modes Chapter 3

Note

When Samba is running in server security mode, it is es-

sential that the parameter password server is set to the
precise NetBIOS machine name of the target authentica-
tion server. Samba cannot determine this from NetBIOS
name lookups because the choice of the target authenti-
cation server is arbitrary and cannot be determined from a
domain name. In essence, a Samba server that is in server
security mode is operating in what used to be known as
workgroup mode.

3.3.5.1 Example Configuration

Using MS Windows NT as an Authentication Server

This method involves the additions of the following parameters in the smb.
conf file:
 
e n c r y p t passwords = Yes
security = server
password s e r v e r = ” NetBIOS name of a DC ”
 

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

The downside of this mode of configuration is that for security reasons

Samba will send the password server a bogus username and a bogus pass-
word, and if the remote server fails to reject the bogus username and pass-
word pair, then an alternative mode of identification or validation is used.
Where a site uses password lockout, after a certain number of failed authen-
tication attempts, this will result in user lockouts.

Use of this mode of authentication requires a standard UNIX account for

the user. This account can be blocked to prevent logons by non-SMB/CIFS
clients.
Section 3.4. Password Checking 51

3.4 Password Checking

MS Windows clients may use encrypted passwords as part of a challenge/re-

sponse authentication model (a.k.a. NTLMv1 and NTLMv2) or alone, or
clear-text strings for simple password-based authentication. It should be re-
alized that with the SMB protocol, the password is passed over the network
either in plaintext or encrypted, but not both in the same authentication
request.
When encrypted passwords are used, a password that has been entered by
the user is encrypted in two ways:
• An MD4 hash of the unicode of the password string. This is known as
the NT hash.
• The password is converted to uppercase, and then padded or truncated
to 14 bytes. This string is then appended with 5 bytes of NULL
characters and split to form two 56-bit DES keys to encrypt a ”magic”
8-byte value. The resulting 16 bytes form the LanMan hash.
MS Windows 95 pre-service pack 1 and MS Windows NT versions 3.x and
version 4.0 pre-service pack 3 will use either mode of password authenti-
cation. All versions of MS Windows that follow these versions no longer
support plain-text passwords by default.
MS Windows clients have a habit of dropping network mappings that have
been idle for 10 minutes or longer. When the user attempts to use the
mapped drive connection that has been dropped, the client re-establishes
the connection using a cached copy of the password.
When Microsoft changed the default password mode, support was dropped
for caching of the plaintext password. This means that when the registry
parameter is changed to re-enable use of plaintext passwords, it appears to
work, but when a dropped service connection mapping attempts to reval-
idate, this will fail if the remote authentication server does not support
encrypted passwords. It is definitely not a good idea to re-enable plaintext
password support in such clients.
The following parameters can be used to work around the issue of Windows
9x/Me clients uppercasing usernames and passwords before transmitting
them to the SMB server when using clear-text authentication:
 
password l e v e l
52 Server Types and Security Modes Chapter 3

username l e v e l
 

By default Samba will convert to lowercase the username before attempting

to lookup the user in the database of local system accounts. Because UNIX
usernames conventionally only contain lowercase characters, the username-
level parameter is rarely needed.
However, passwords on UNIX systems often make use of mixed-case char-
acters. This means that in order for a user on a Windows 9x/Me client
to connect to a Samba server using clear-text authentication, the password
level must be set to the maximum number of uppercase letters that could
appear in a password. Note that if the Server OS uses the traditional DES
version of crypt(), a password level of 8 will result in case-insensitive pass-
words as seen from Windows users. This will also result in longer login times
because Samba has to compute the permutations of the password string and
try them one by one until a match is located (or all combinations fail).
The best option to adopt is to enable support for encrypted passwords wher-
ever Samba is used. Most attempts to apply the registry change to re-enable
plaintext passwords will eventually lead to user complaints and unhappiness.

3.5 Common Errors

We all make mistakes. It is okay to make mistakes, as long as they are made
in the right places and at the right time. A mistake that causes lost pro-
ductivity is seldom tolerated; however, a mistake made in a developmental
test lab is expected.
Here we look at common mistakes and misapprehensions that have been the
subject of discussions on the Samba mailing lists. Many of these are avoid-
able by doing your homework before attempting a Samba implementation.
Some are the result of a misunderstanding of the English language, which
has many phrases that are potentially vague and may be highly confusing
to those for whom English is not their native tongue.

3.5.1 What Makes Samba a Server?

To some, the nature of the Samba security mode is obvious, but entirely
wrong all the same. It is assumed that security = server means that Samba
Section 3.5. Common Errors 53

will act as a server. Not so! This setting means that Samba will try to use
another SMB server as its source for user authentication alone.
Samba is a server regardless of which security mode is chosen. When Samba
is used outside of a domain security context, it is best to leave the security
mode at the default setting. By default Samba-3 uses User-mode security.

3.5.2 What Makes Samba a Domain Controller?

The smb.conf parameter security = domain does not really make Samba
behave as a domain controller. This setting means we want Samba to be a
domain member. See Chapter 4, “Domain Control” for more information.

3.5.3 What Makes Samba a Domain Member?

Guess! So many others do. But whatever you do, do not think that security
= user makes Samba act as a domain member. Read the manufacturer’s
manual before the warranty expires. See Chapter 6, “Domain Membership”,
for more information.

3.5.4 Constantly Losing Connections to Password Server

“Why does server validate() simply give up rather than re-establish its con-
nection to the password server? Though I am not fluent in the SMB protocol,
perhaps the cluster server process passes along to its client workstation the
session key it receives from the password server, which means the password
hashes submitted by the client would not work on a subsequent connection
whose session key would be different. So server validate() must give up.”
Indeed. That’s why security = server is at best a nasty hack. Please use
security = domain; security = server mode is also known as pass-through
authentication.
Chapter 4

DOMAIN CONTROL

There are many who approach MS Windows networking with incredible

misconceptions. That’s okay, because it gives the rest of us plenty of oppor-
tunity to be of assistance. Those who really want help are well advised to
become familiar with information that is already available.
You are advised not to tackle this section without having first understood
and mastered some basics. MS Windows networking is not particularly
forgiving of misconfiguration. Users of MS Windows networking are likely
to complain of persistent niggles that may be caused by a broken network
configuration. To a great many people, however, MS Windows networking
starts with a domain controller that in some magical way is expected to
solve all network operational ills.
Figure 4.1 shows a typical MS Windows domain security network environ-
ment. Workstations A, B, and C are representative of many physical MS
Windows network clients.
From the Samba mailing list we can readily identify many common network-
ing issues. If you are not clear on the following subjects, then it will do much
good to read the sections of this HOWTO that deal with it. These are the
most common causes of MS Windows networking problems:
• Basic TCP/IP configuration.
• NetBIOS name resolution.
• Authentication configuration.
• User and group configuration.
• Basic file and directory permission control in UNIX/Linux.

54
 55

DOMAIN

Workstation A

Primary
Domain
Controller

Workstation B

Workstation C

Backup Domain
Backup Domain Controller 2
Controller 1

Figure 4.1. An Example Domain.

• Understanding how MS Windows clients interoperate in a network

environment.

Do not be put off; on the surface of it MS Windows networking seems so

simple that anyone can do it. In fact, it is not a good idea to set up an
MS Windows network with inadequate training and preparation. But let’s
get our first indelible principle out of the way: It is perfectly okay to make
mistakes! In the right place and at the right time, mistakes are the essence
of learning. It is very much not okay to make mistakes that cause loss of
productivity and impose an avoidable financial burden on an organization.

Where is the right place to make mistakes? Only out of harms way. If you
are going to make mistakes, then please do it on a test network, away from
users, and in such a way as to not inflict pain on others. Do your learning
on a test network.
56 Domain Control Chapter 4

4.1 Features and Benefits

What is the key benefit of Microsoft Domain Security?

In a word, single sign-on, or SSO for short. To many, this is the Holy
Grail of MS Windows NT and beyond networking. SSO allows users in
a well-designed network to log onto any workstation that is a member of
the domain that contains their user account (or in a domain that has an
appropriate trust relationship with the domain they are visiting) and they
will be able to log onto the network and access resources (shares, files, and
printers) as if they are sitting at their home (personal) workstation. This is
a feature of the domain security protocols.
The benefits of domain security are available to those sites that deploy a
Samba PDC. A domain provides a unique network security identifier (SID).
Domain user and group security identifiers are comprised of the network
SID plus a relative identifier (RID) that is unique to the account. User and
group SIDs (the network SID plus the RID) can be used to create access
control lists (ACLs) attached to network resources to provide organizational
access control. UNIX systems recognize only local security identifiers.

Note

Network clients of an MS Windows domain security en-

vironment must be domain members to be able to gain
access to the advanced features provided. Domain mem-
bership involves more than just setting the workgroup
name to the domain name. It requires the creation of a
domain trust account for the workstation (called a ma-
chine account). Refer to Chapter 6, “Domain Member-
ship” for more information.

The following functionalities are new to the Samba-3 release:

• Samba-3 supports the use of a choice of backends that may be used
in which user, group and machine accounts may be stored. Multi-
ple passwd backends can be used in combination, either as additive
backend data sets, or as fail-over data sets.
Section 4.1. Features and Benefits 57

An LDAP passdb backend confers the benefit that the account backend
can be distributed and replicated, which is of great value because it
confers scalability and provides a high degree of reliability.
• Windows NT4 domain trusts. Samba-3 supports workstation and
server (machine) trust accounts. It also supports Windows NT4 style
interdomain trust accounts, which further assists in network scalability
and interoperability.
• Operation without NetBIOS over TCP/IP, rather using the raw SMB
over TCP/IP. Note, this is feasible only when operating as a Microsoft
active directory domain member server. When acting as a Samba
domain controller the use of NetBIOS is necessary to provide network
browsing support.
• Samba-3 provides NetBIOS name services (WINS), NetBIOS over TCP/IP
(TCP port 139) session services, SMB over TCP/IP (TCP port 445)
session services, and Microsoft compatible ONC DCE RPC services
(TCP port 135) services.
• Management of users and groups via the User Manager for Domains.
This can be done on any MS Windows client using the Nexus.exe
toolkit for Windows 9x/Me, or using the SRVTOOLS.EXE package for
MS Windows NT4/200x/XP platforms. These packages are available
from Microsoft’s Web site.
• Implements full Unicode support. This simplifies cross-locale inter-
nationalization support. It also opens up the use of protocols that
Samba-2.2.x had but could not use due to the need to fully support
Unicode.
The following functionalities are not provided by Samba-3:
• SAM replication with Windows NT4 domain controllers (i.e., a Samba
PDC and a Windows NT BDC, or vice versa). This means Samba
cannot operate as a BDC when the PDC is Microsoft-based Windows
NT PDC. Samba-3 can not participate in replication of account data
to Windows PDCs and BDCs.
• Acting as a Windows 2000 active directory domain controller (i.e.,
Kerberos and Active Directory). In point of fact, Samba-3 does have
some Active Directory domain control ability that is at this time purely
experimental. Active directory domain control is one of the features
that is being developed in Samba-4, the next generation Samba release.
58 Domain Control Chapter 4

At this time there are no plans to enable active directory domain

control support during the Samba-3 series life-cycle.

• The Windows 200x/XP Microsoft Management Console (MMC) can-

not be used to manage a Samba-3 server. For this you can use only
the MS Windows NT4 Domain Server Manager and the MS Windows
NT4 Domain User Manager. Both are part of the SVRTOOLS.EXE
package mentioned later.

Windows 9x/Me/XP Home clients are not true members of a domain for rea-
sons outlined in this chapter. The protocol for support of Windows 9x/Me-
style network (domain) logons is completely different from NT4/Windows
200x-type domain logons and has been officially supported for some time.
These clients use the old LanMan network logon facilities that are supported
in Samba since approximately the Samba-1.9.15 series.

Samba-3 implements group mapping between Windows NT groups and UNIX

groups (this is really quite complicated to explain in a short space). This
is discussed more fully in Chapter 11, “Group Mapping: MS Windows and
UNIX”.

Samba-3, like an MS Windows NT4 PDC or a Windows 200x Active Di-

rectory, needs to store user and Machine Trust Account information in a
suitable backend data-store. Refer to Section 6.2. With Samba-3 there can
be multiple backends for this. A complete discussion of account database
backends can be found in Chapter 10, “Account Information Databases”.

4.2 Single Sign-On and Domain Security

When network administrators are asked to describe the benefits of Windows

NT4 and active directory networking the most often mentioned feature is
that of single sign-on (SSO). Many companies have implemented SSO solu-
tions. The mode of implementation of a single sign-on solution is an impor-
tant factor in the practice of networking in general, and is critical in respect
of Windows networking. A company may have a wide variety of information
systems, each of which requires a form of user authentication and validation,
thus it is not uncommon that users may need to remember more than ten
login IDs and passwords. This problem is compounded when the password
for each system must be changed at regular intervals, and particularly so
where password uniqueness and history limits are applied.
Section 4.2. Single Sign-On and Domain Security 59

There is a broadly held perception that SSO is the answer to the problem
of users having to deal with too many information system access credentials
(username/password pairs). Many elaborate schemes have been devised to
make it possible to deliver a user-friendly SSO solution. The trouble is that
if this implementation is not done correctly, the site may end up paying
dearly by way of complexity and management overheads. Simply put, many
SSO solutions are an administrative nightmare.

SSO implementations utilize centralization of all user account information.

Depending on environmental complexity and the age of the systems over
which a SSO solution is implemented, it may not be possible to change the
solution architecture so as to accomodate a new identity management and
user authentication system. Many SSO solutions involving legacy systems
consist of a new super-structure that handles authentication on behalf of
the user. The software that gets layered over the old system may simply
implement a proxy authentication system. This means that the addition
of SSO increases over-all information systems complexity. Ideally, the im-
plementation of SSO should reduce complexity and reduce administative
overheads.

The initial goal of many network administrators is often to create and use
a centralized identity management system. It is often assumed that such a
centralized system will use a single authentication infrastructure that can
be used by all information systems. The Microsoft Windows NT4 secu-
rity domain architecture and the Micrsoft active directory service are often
put forward as the ideal foundation for such a system. It is conceptually
simple to install an external authentication agent on each of the disparate
infromation systems that can then use the Microsoft (NT4 domain or ads
service) for user authentication and access control. The wonderful dream of
a single centralized authentication service is commonly broken when reali-
ties are realized. The problem with legacy systems is often the inability to
externalize the authentication and access control system it uses because its
implementation will be excessively invasive from a re-engineering perspec-
tive, or because application software has built-in dependencies on particular
elements of the way user authentication and access control were designed
and built.

Over the past decade an industry has been developed around the various
methods that have been built to get around the key limitations of legacy
information technology systems. One approach that is often used involves
the use of a meta-directory. The meta-directory stores user credentials for
60 Domain Control Chapter 4

all disparate information systems in the format that is particular to each

system. An elaborate set of management procedures is coupled with a rigidly
enforced work-flow protocol for managing user rights and privileges within
the maze of systems that are provisioned by the new infrastructure makes
possible user access to all systems using a single set of user credentials.
The Organization for the Advancement of Structured Information Standards
(OASIS) has developed the Security Assertion Markup Language (SAML),
a structured method for communication of authentication information. The
over-all umbrella name for the technologies and methods that deploy SAML
is called Federated Identity Management (FIM). FIM depends on each sys-
tem in the complex maze of disparate information systems to authenticate
their respective users and vouch for secure access to the services each pro-
vides.
SAML documents can be wrapped in a Simple Object Access Protocol
(SOAP) message for the computer-to-computer communications needed for
Web services. Or they may be passed between Web servers of federated or-
ganizations that share live services. The Liberty Alliance, an industry group
formed to promote federated-identity standards, has adopted SAML 1.1 as
part of its application framework. Microsoft and IBM have proposed an al-
ternative specification called WS-Security. Some believe that the competing
technologies and methods may converge when the SAML 2.0 standard is
introduced. A few Web access-management products support SAML today,
but implemention of the technology mostly requires customization to inte-
grate applications and develop user interfaces. In a nust-shell, that is why
FIM is a big and growing industry.
Ignoring the bigger picture, which is beyond the scope of this book, the
migration of all user and group management to a centralized system is a
step in the right direction. It is essential for interoperability reasons to
locate the identity management system data in a directory such as Microsoft
Active Directory Service (ADS), or any proprietary or open source system
that provides a standard protocol for information access (such as LDAP) and
that can be coupled with a flexible array of authentication mechanisms (such
as kerberos) that use the protocols that are defined by the various general
security service application programming interface (GSSAPI) services.
A growing number of companies provide authentication agents for disparate
legacy platforms to permit the use of LDAP systems. Thus the use of
OpenLDAP, the dominant open source software implementation of the light
weight directory access protocol standard. This fact, means that by provid-
Section 4.3. Basics of Domain Control 61

ing support in Samba for the use of LDAP and Microsoft ADS make Samba a
highly scalable and forward reaching organizational networking technology.
Microsoft ADS provides purely proprietary services that, with limitation,
can be extended to provide a centralized authentication infrastructure. Samba
plus LDAP provides a similar opportunity for extension of a centralized au-
thentication architecture, but it is the fact that the Samba Team are pro-
active in introducing the extension of authentication services, using LDAP
or otherwise, to applications such as SQUID (the open source proxy server)
through tools such as the ntlm auth utility, that does much to create sus-
tainable choice and competition in the FIM market place.
Primary domain control, if it is to be scalable to meet the needs of large sites,
must therefore be capable of using LDAP. The rapid adoption of OpenLDAP,
and Samba configurations that use it, is ample proof that the era of the
directoy has started. Samba-3 does not demand the use of LDAP, but the
demand for a mechanism by which user and group identity information can
be distributed makes it an an unavoidable option.
At this time, the use of Samba based BDCs, necessitates the use of LDAP.
The most commonly used LDAP implementation used by Samba sites is
OpenLDAP. It is possible to use any standards compliant LDAP server.
Those known to work includes those manufactured by: IBM, CA, Novell
(e-Directory), and others.

4.3 Basics of Domain Control

Over the years, public perceptions of what domain control really is has
taken on an almost mystical nature. Before we branch into a brief overview
of domain control, there are three basic types of domain controllers.

4.3.1 Domain Controller Types

• NT4 style Primary Domain Controller

• NT4 style Backup Domain Controller
• ADS Domain Controller
The Primary Domain Controller or PDC plays an important role in MS
Windows NT4. In Windows 200x domain control architecture, this role
62 Domain Control Chapter 4

is held by domain controllers. Folklore dictates that because of its role

in the MS Windows network, the domain controller should be the most
powerful and most capable machine in the network. As strange as it may
seem to say this here, good overall network performance dictates that the
entire infrastructure needs to be balanced. It is advisable to invest more in
standalone (domain member) servers than in the domain controllers.
In the case of MS Windows NT4-style domains, it is the PDC that initi-
ates a new domain control database. This forms a part of the Windows
registry called the Security Account Manager (SAM). It plays a key part in
NT4-type domain user authentication and in synchronization of the domain
authentication database with BDCs.
With MS Windows 200x Server-based Active Directory domains, one domain
controller initiates a potential hierarchy of domain controllers, each with its
own area of delegated control. The master domain controller has the ability
to override any downstream controller, but a downline controller has control
only over its downline. With Samba-3, this functionality can be implemented
using an LDAP-based user and machine account backend.
New to Samba-3 is the ability to use a backend database that holds the same
type of data as the NT4-style SAM database (one of the registry files)1
The Backup Domain Controller or BDC plays a key role in servicing network
authentication requests. The BDC is biased to answer logon requests in
preference to the PDC. On a network segment that has a BDC and a PDC,
the BDC will most likely service network logon requests. The PDC will
answer network logon requests when the BDC is too busy (high load). When
a user logs onto a Windows domain member client the workstation will query
the network to locate the nearest network logon server. Where a WINS
server is used, this is done via a query to the WINS server. If a netlogon
server can not be found from the WINS query, or in the absence of a WINS
server, the workstation will perform a NetBIOS name lookup via a mailslot
broadcast over the UDP broadcast protocol. This means that the netlogon
server that the windows client will use is influenced by a number of variables,
thus there is no simple determinant of whether a PDC or a BDC will serve
a particular logon authentication request.
A Windows NT4 BDC can be promoted to a PDC. If the PDC is online at
the time that a BDC is promoted to PDC, the previous PDC is automatically
demoted to a BDC. With Samba-3, this is not an automatic operation; the
1
See also Chapter 10, “Account Information Databases”. .
Section 4.3. Basics of Domain Control 63

PDC and BDC must be manually configured, and other appropriate changes
also need to be made.
With MS Windows NT4, a decision is made at installation to determine
what type of machine the server will be. It is possible to promote a BDC
to a PDC, and vice versa. The only method Microsoft provide to convert a
Windows NT4 domain controller to a domain member server or a standalone
server is to reinstall it. The install time choices offered are:
• Primary Domain Controller — the one that seeds the domain SAM.
• Backup Domain Controller — one that obtains a copy of the domain
SAM.
• Domain Member Server — one that has no copy of the domain SAM;
rather it obtains authentication from a domain controller for all access
controls.
• Standalone Server — one that plays no part in SAM synchronization,
has its own authentication database, and plays no role in domain se-
curity.

Note

Algin Technology LLC provide a commercial tool that

makes it possible to promote a Windows NT4 standalone
server to a PDC or a BDC, and also permits this process
to be reversed. Refer the the Algina web site for further
information.

a
<http://utools.com/UPromote.asp>

Samba-3 servers can readily be converted to and from domain controller

roles through simple changes to the smb.conf file. Samba-3 is capable of
acting fully as a native member of a Windows 200x server Active Directory
domain.
For the sake of providing a complete picture, MS Windows 2000 domain
control configuration is done after the server has been installed. Please refer
to Microsoft documentation for the procedures that should be followed to
64 Domain Control Chapter 4

convert a domain member server to or from a domain control, and to install

or remove active directory service support.
New to Samba-3 is the ability to function fully as an MS Windows NT4-style
domain controller, excluding the SAM replication components. However,
please be aware that Samba-3 also supports the MS Windows 200x domain
control protocols.
At this time any appearance that Samba-3 is capable of acting as a domain
controller in native ADS mode is limited and experimental in nature. This
functionality should not be used until the Samba Team offers formal support
for it. At such a time, the documentation will be revised to duly reflect all
configuration and management requirements. Samba can act as a NT4-style
domain controller in a Windows 2000/XP environment. However, there are
certain compromises:
• No machine policy files.
• No Group Policy Objects.
• No synchronously executed Active Directory logon scripts.
• Can’t use Active Directory management tools to manage users and
machines.
• Registry changes tattoo the main registry, while with Active Directory
they do not leave permanent changes in effect.
• Without Active Directory you cannot perform the function of export-
ing specific applications to specific users or groups.

4.3.2 Preparing for Domain Control

There are two ways that MS Windows machines may interact with each
other, with other servers, and with domain controllers: either as standalone
systems, more commonly called workgroup members, or as full participants
in a security system, more commonly called domain members.
It should be noted that workgroup membership involves no special configu-
ration other than the machine being configured so the network configuration
has a commonly used name for its workgroup entry. It is not uncommon for
the name WORKGROUP to be used for this. With this mode of configura-
tion, there are no Machine Trust Accounts, and any concept of membership
Section 4.3. Basics of Domain Control 65

as such is limited to the fact that all machines appear in the network neigh-
borhood to be logically grouped together. Again, just to be clear: workgroup
mode does not involve security machine accounts.
Domain member machines have a machine trust account in the domain
accounts database. A special procedure must be followed on each machine
to effect domain membership. This procedure, which can be done only
by the local machine Administrator account, creates the domain machine
account (if it does not exist), and then initializes that account. When the
client first logs onto the domain, a machine trust account password change
will be automatically triggered.

Note

When Samba is configured as a domain controller, se-

cure network operation demands that all MS Windows
NT4/200x/XP Professional clients should be configured
as domain members. If a machine is not made a member
of the domain, then it will operate like a workgroup (stan-
dalone) machine. Please refer to Chapter 6, “Domain
Membership”, for information regarding domain mem-
bership.

The following are necessary for configuring Samba-3 as an MS Windows

NT4-style PDC for MS Windows NT4/200x/XP clients:
• Configuration of basic TCP/IP and MS Windows networking.
• Correct designation of the server role (security = user).
• Consistent configuration of name resolution.2
• Domain logons for Windows NT4/200x/XP Professional clients.
• Configuration of roaming profiles or explicit configuration to force local
profile usage.
• Configuration of network/system policies.
2
See Chapter 9, “Network Browsing”, and Chapter 28, “Integrating MS Windows
Networks with Samba”.
66 Domain Control Chapter 4

• Adding and managing domain user accounts.

• Configuring MS Windows NT4/2000 Professional and Windows XP
Professional client machines to become domain members.
The following provisions are required to serve MS Windows 9x/Me clients:
• Configuration of basic TCP/IP and MS Windows networking.
• Correct designation of the server role (security = user).
• Network logon configuration (since Windows 9x/Me/XP Home are
not technically domain members, they do not really participate in the
security aspects of Domain logons as such).
• Roaming profile configuration.
• Configuration of system policy handling.
• Installation of the network driver “Client for MS Windows Networks”
and configuration to log onto the domain.
• Placing Windows 9x/Me clients in user-level security — if it is desired
to allow all client-share access to be controlled according to domain
user/group identities.
• Adding and managing domain user accounts.

Note

Roaming profiles and system/network policies are ad-

vanced network administration topics that are covered in
Chapter 26, “Desktop Profile Management” and Chap-
ter 25, “System and Account Policies” of this document.
However, these are not necessarily specific to a Samba
PDC as much as they are related to Windows NT net-
working concepts.

A domain controller is an SMB/CIFS server that:

• Registers and advertises itself as a domain controller (through Net-
BIOS broadcasts as well as by way of name registrations either by
Section 4.4. Domain Control: Example Configuration 67

Mailslot Broadcasts over UDP broadcast, to a WINS server over UDP

unicast, or via DNS and Active Directory).
• Provides the NETLOGON service. (This is actually a collection of
services that runs over multiple protocols. These include the LanMan
logon service, the Netlogon service, the Local Security Account service,
and variations of them.)
• Provides a share called NETLOGON.
It is rather easy to configure Samba to provide these. Each Samba domain
controller must provide the NETLOGON service that Samba calls the do-
main logons functionality (after the name of the parameter in the smb.conf
file). Additionally, one server in a Samba-3 domain must advertise itself
as the domain master browser.3 This causes the PDC to claim a domain-
specific NetBIOS name that identifies it as a DMB for its given domain or
workgroup. Local master browsers (LMBs) in the same domain or work-
group on broadcast-isolated subnets then ask for a complete copy of the
browse list for the whole wide-area network. Browser clients then contact
their LMB, and will receive the domain-wide browse list instead of just the
list for their broadcast-isolated subnet.

4.4 Domain Control: Example Configuration

The first step in creating a working Samba PDC is to understand the pa-
rameters necessary in smb.conf. An example smb.conf for acting as a PDC
can be found in Example 4.4.1.
The basic options shown in Example 4.4.1 are explained as follows:

passdb backend This contains all the user and group account information.
Acceptable values for a PDC are: smbpasswd, tdbsam, and ldapsam.
The “guest” entry provides default accounts and is included by default;
there is no need to add it explicitly.
Where use of BDCs is intended, the only logical choice is to use LDAP
so the passdb backend can be distributed. The tdbsam and smbpasswd
files cannot effectively be distributed and therefore should not be used.

3
See Chapter 9, “Network Browsing”.
68 Domain Control Chapter 4

Example 4.4.1. smb.conf for being a PDC

 
[ global ]
n e t b i o s name
workgroup
passdb backend = tdbsam
o s l e v e l = 33
p r e f e r r e d master = auto
domain master = y e s
l o c a l master = y e s
security = user
domain l o g o n s = y e s
l o g o n path = \\%N\ p r o f i l e s \%U
l o g o n d r i v e = H:
l o g o n home = \\ homeserver\%U\ w i n p r o f i l e
l o g o n s c r i p t = l o g o n . cmd
[ netlogon ]
path = / var / l i b /samba/ n e t l o g o n
read only = yes
write l i s t
[ profiles ]
path = / var / l i b /samba/ p r o f i l e s
r e a d o n l y = no
c r e a t e mask = 0600
d i r e c t o r y mask = 0700
 

Domain Control Parameters The parameters os level, preferred master,

domain master, security, encrypt passwords, and domain logons play
a central role in assuring domain control and network logon support.
The os level must be set at or above a value of 32. A domain con-
troller must be the DMB, must be set in user mode security, must
support Microsoft-compatible encrypted passwords, and must provide
the network logon service (domain logons). Encrypted passwords must
be enabled. For more details on how to do this, refer to Chapter 10,
“Account Information Databases”.

Environment Parameters The parameters logon path, logon home, logon

Section 4.4. Domain Control: Example Configuration 69

drive, and logon script are environment support settings that help to
facilitate client logon operations and that help to provide automated
control facilities to ease network management overheads. Please refer
to the man page information for these parameters.

NETLOGON Share The NETLOGON share plays a central role in do-

main logon and domain membership support. This share is provided
on all Microsoft domain controllers. It is used to provide logon scripts,
to store group policy files (NTConfig.POL), as well as to locate other
common tools that may be needed for logon processing. This is an
essential share on a domain controller.

PROFILE Share This share is used to store user desktop profiles. Each
user must have a directory at the root of this share. This directory
must be write-enabled for the user and must be globally read-enabled.
Samba-3 has a VFS module called “fake permissions” that may be
installed on this share. This will allow a Samba administrator to make
the directory read-only to everyone. Of course this is useful only after
the profile has been properly created.

Note

The above parameters make for a full set of functionality

that may define the server’s mode of operation. The
following smb.conf parameters are the essentials alone:
 
n e t b i o s name = BELERIAND
w o r k g r o u p = MIDEARTH
domain l o g o n s = Yes
domain m a s t e r = Yes
s e c u r i t y = User
 

The additional parameters shown in the longer listing in

this section just make for a more complete explanation.
70 Domain Control Chapter 4

4.5 Samba ADS Domain Control

Samba-3 is not, and cannot act as, an Active Directory server. It cannot
truly function as an Active Directory PDC. The protocols for some of the
functionality of Active Directory domain controllers has been partially im-
plemented on an experimental only basis. Please do not expect Samba-3
to support these protocols. Do not depend on any such functionality either
now or in the future. The Samba Team may remove these experimental
features or may change their behavior. This is mentioned for the benefit of
those who have discovered secret capabilities in Samba-3 and who have asked
when this functionality will be completed. The answer is maybe someday
or maybe never!
To be sure, Samba-3 is designed to provide most of the functionality that
Microsoft Windows NT4-style domain controllers have. Samba-3 does not
have all the capabilities of Windows NT4, but it does have a number of fea-
tures that Windows NT4 domain controllers do not have. In short, Samba-3
is not NT4 and it is not Windows Server 200x: it is not an Active Directory
server. We hope this is plain and simple enough for all to understand.

4.6 Domain and Network Logon Configuration

The subject of network or domain logons is discussed here because it forms

an integral part of the essential functionality that is provided by a domain
controller.

4.6.1 Domain Network Logon Service

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

4.6.1.1 Example Configuration

4.6.1.2 The Special Case of MS Windows XP Home Edition

To be completely clear: If you want MS Windows XP Home Edition to

integrate with your MS Windows NT4 or Active Directory domain security,
Section 4.6. Domain and Network Logon Configuration 71

Example 4.6.1. smb.conf for being a PDC

 
[ global ]
domain l o g o n s = Yes
domain master = ( Yes on PDC, No on BDCs)
[ netlogon ]
comment = Network Logon S e r v i c e
path = / var / l i b /samba/ n e t l o g o n
g u e s t ok = Yes
b r o w s e a b l e = No
 

understand it cannot be done. The only option is to purchase the upgrade

from MS Windows XP Home Edition to MS Windows XP Professional.

Note

MS Windows XP Home Edition does not have the ability

to join any type of domain security facility. Unlike MS
Windows 9x/Me, MS Windows XP Home Edition also
completely lacks the ability to log onto a network.

Now that this has been said, please do not ask the mailing list or email any
of the Samba Team members with your questions asking how to make this
work. It can’t be done. If it can be done, then to do so would violate your
software license agreement with Microsoft, and we recommend that you do
not do that.

4.6.1.3 The Special Case of Windows 9x/Me

A domain and a workgroup are exactly the same in terms of network brows-
ing. The difference is that a distributable authentication database is asso-
ciated with a domain, for secure login access to a network. Also, different
access rights can be granted to users if they successfully authenticate against
a domain logon server. Samba-3 does this now in the same way as MS Win-
dows NT/200x.
72 Domain Control Chapter 4

The SMB client logging on to a domain has an expectation that every other
server in the domain should accept the same authentication information.
Network browsing functionality of domains and workgroups is identical and
is explained in this documentation under the browsing discussions. It should
be noted that browsing is totally orthogonal to logon support.
Issues related to the single-logon network model are discussed in this section.
Samba supports domain logons, network logon scripts, and user profiles for
MS Windows for Workgroups and MS Windows 9x/Me clients, which are
the focus of this section.
When an SMB client in a domain wishes to log on, it broadcasts requests for
a logon server. The first one to reply gets the job and validates its password
using whatever mechanism the Samba administrator has installed. It is
possible (but ill advised) to create a domain where the user database is
not shared between servers; that is, they are effectively workgroup servers
advertising themselves as participating in a domain. This demonstrates how
authentication is quite different from but closely involved with domains.
Using these features, you can make your clients verify their logon via the
Samba server, make clients run a batch file when they log on to the network
and download their preferences, desktop, and start menu.
MS Windows XP Home edition is not able to join a domain and does not
permit the use of domain logons.
Before launching into the configuration instructions, it is worthwhile to look
at how a Windows 9x/Me client performs a logon:
1. The client broadcasts (to the IP broadcast address of the subnet it
is in) a NetLogon request. This is sent to the NetBIOS name DO-
MAIN<1C> at the NetBIOS layer. The client chooses the first re-
sponse it receives, which contains the NetBIOS name of the logon
server to use in the format of \\SERVER. The 1C name is the name
type that is registered by domain controllers (SMB/CIFS servers that
provide the netlogon service).
2. The client connects to that server, logs on (does an SMBsessetupX)
and then connects to the IPC$ share (using an SMBtconX).
3. The client does a NetWkstaUserLogon request, which retrieves the
name of the user’s logon script.
4. The client then connects to the NetLogon share and searches for said
Section 4.6. Domain and Network Logon Configuration 73

script. If it is found and can be read, it is retrieved and executed by

the client. After this, the client disconnects from the NetLogon share.

5. The client sends a NetUserGetInfo request to the server to retrieve

the user’s home share, which is used to search for profiles. Since the
response to the NetUserGetInfo request does not contain much more
than the user’s home share, profiles for Windows 9x clients must reside
in the user home directory.

6. The client connects to the user’s home share and searches for the user’s
profile. As it turns out, you can specify the user’s home share as a
share name and path. For example, \\server\fred\.winprofile. If
the profiles are found, they are implemented.

7. The client then disconnects from the user’s home share and reconnects
to the NetLogon share and looks for CONFIG.POL, the policies file. If
this is found, it is read and implemented.

The main difference between a PDC and a Windows 9x/Me logon server
configuration is:

• Password encryption is not required for a Windows 9x/Me logon server.

But note that beginning with MS Windows 98 the default setting is
that plaintext password support is disabled. It can be re-enabled with
the registry changes that are documented in Chapter 25, “System and
Account Policies”.

• Windows 9x/Me clients do not require and do not use Machine Trust
Accounts.

A Samba PDC will act as a Windows 9x/Me logon server; after all, it does
provide the network logon services that MS Windows 9x/Me expect to find.

Note

Use of plaintext passwords is strongly discouraged.

Where used they are easily detected using a sniffer tool
to examine network traffic.
74 Domain Control Chapter 4

4.6.2 Security Mode and Master Browsers

There are a few comments to make in order to tie up some loose ends. There
has been much debate over the issue of whether it is okay to configure Samba
as a domain controller that operates with security mode other than user-
mode. The only security mode that will not work due to technical reasons
is share-mode security. Domain and server mode security are really just a
variation on SMB user-level security.

Actually, this issue is also closely tied to the debate on whether Samba must
be the DMB for its workgroup when operating as a domain controller. In
a pure Microsoft Windows NT domain, the PDC wins the election to be
the DMB, and then registers the DOMAIN<1B> NetBIOS name. This is
not the name used by Windows clients to locate the domain controller, all
domain controllers register the DOMAIN<1C> name and Windows clients
locate a network logon server by seraching for the DOMAIN<1C> name. A
DMB is a Domain Master Browser — see Chapter 9, “Network Browsing”,
Section 9.4.1; Microsoft PDCs expect to win the election to become the
DMB, if it loses that election it will report a continuous and rapid sequence
of warning messages to its Windows event logger complaining that it has
lost the election to become a DMB. For this reason, in networks where a
Samba server is the PDC it is wise to configure the Samba domain controller
as the DMB.
Section 4.7. Common Errors 75

Note

SMB/CIFS servers that register the DOMAIN<1C>

name do so because they provide the network logon ser-
vice. Server that register the DOMAIN<1B> name are
DMBs — meaning that they are responsible for browse
list synchronization across all machines that have reg-
istered the DOMAIN<1D> name. The later are LMBs
that have the responsibility to listen to all NetBIOS name
registrations that occur locally to their own network seg-
ment. The network logon service (NETLOGON) is ger-
mane to domain control and has nothing to do with net-
work browsing and browse list management. The 1C and
1B/1D name services are orthogonal to each other.

Now back to the issue of configuring a Samba domain controller to use

a mode other than security = user. If a Samba host is configured to use
another SMB server or domain controller in order to validate user connection
requests, it is a fact that some other machine on the network (the password
server ) knows more about the user than the Samba host. About 99 percent
of the time, this other host is a domain controller. Now to operate in domain
mode security, the workgroup parameter must be set to the name of the
Windows NT domain (which already has a domain controller). If the domain
does not already have a domain controller, you do not yet have a domain.
Configuring a Samba box as a domain controller for a domain that already
by definition has a PDC is asking for trouble. Therefore, you should always
configure the Samba domain controller to be the DMB for its domain and
set security = user. This is the only officially supported mode of operation.

4.7 Common Errors

4.7.1 “$” Cannot Be Included in Machine Name

A machine account, typically stored in /etc/passwd, takes the form of the

machine name with a “$” appended. Some BSD systems will not create a
user with a “$” in the name. Recent versions of FreeBSD have removed this
limitation, but older releases are still in common use.
76 Domain Control Chapter 4

The problem is only in the program used to make the entry. Once made,
it works perfectly. Create a user without the “$”. Then use vipw to edit
the entry, adding the “$”. Or create the whole entry with vipw if you like;
make sure you use a unique user login ID.

Note

The machine account must have the exact name that the
workstation has.

Note

The UNIX tool vipw is a common tool for directly editing

the /etc/passwd file. The use of vipw will ensure that
shadow files (where used) will remain current with the
passwd file. This is important for security reasons.

4.7.2 Joining Domain Fails Because of Existing Machine Account

“I get told, ‘You already have a connection to the Domain....’ or ‘Cannot

join domain, the credentials supplied conflict with an existing set...’ when
creating a Machine Trust Account.”
This happens if you try to create a Machine Trust Account from the machine
itself and already have a connection (e.g., mapped drive) to a share (or IPC$)
on the Samba PDC. The following command will remove all network drive
connections:

C:\> net use * /d

This will break all network connections.

Further, if the machine is already a “member of a workgroup” that is the
Section 4.7. Common Errors 77

same name as the domain you are joining (bad idea), you will get this
message. Change the workgroup name to something else — it does not
matter what — reboot, and try again.

4.7.3 The System Cannot Log You On (C000019B)

“I joined the domain successfully but after upgrading to a newer version

of the Samba code I get the message, ‘The system cannot log you on
(C000019B). Please try again or consult your system administrator when
attempting to logon.’”

This occurs when the domain SID stored in the secrets.tdb database is
changed. The most common cause of a change in domain SID is when
the domain name and/or the server name (NetBIOS name) is changed. The
only way to correct the problem is to restore the original domain SID or
remove the domain client from the domain and rejoin. The domain SID
may be reset using either the net or rpcclient utilities.

To reset or change the domain SID you can use the net command as follows:

root# net getlocalsid ’OLDNAME’

root# net setlocalsid ’SID’

Workstation Machine Trust Accounts work only with the domain (or net-
work) SID. If this SID changes, domain members (workstations) will not be
able to log onto the domain. The original domain SID can be recovered from
the secrets.tdb file. The alternative is to visit each workstation to rejoin it
to the domain.

4.7.4 The Machine Trust Account Is Not Accessible

“When I try to join the domain I get the message, ”The machine account
for this computer either does not exist or is not accessible.” What’s wrong?”

This problem is caused by the PDC not having a suitable Machine Trust
Account. If you are using the add machine script method to create accounts,
then this would indicate that it has not worked. Ensure the domain admin
user system is working.
78 Domain Control Chapter 4

Alternately, if you are creating account entries manually, then they have not
been created correctly. Make sure that you have the entry correct for the Ma-
chine Trust Account in smbpasswd file on the Samba PDC. If you added the
account using an editor rather than using the smbpasswd utility, make sure
that the account name is the machine NetBIOS name with a “$” appended
to it (i.e., computer name$). There must be an entry in both the POSIX
UNIX system account backend as well as in the SambaSAMAccount back-
end. The default backend for Samba-3 (i.e., the parameter passdb backend
is not specified in the smb.conf file, or if specified is set to smbpasswd,
are respectively the /etc/passwd and /etc/samba/smbpasswd (or /usr/
local/samba/lib/private/smbpasswd if compiled using Samba Team de-
fault settings). The use of the /etc/passwd can be overridden by alternative
settings in the NSS /etc/nsswitch.conf file.
Some people have also reported that inconsistent subnet masks between the
Samba server and the NT client can cause this problem. Make sure that
these are consistent for both client and server.

4.7.5 Account Disabled

“When I attempt to log in to a Samba domain from a NT4/W200x work-

station, I get a message about my account being disabled.”
Enable the user accounts with smbpasswd -e username. This is normally
done as an account is created.

4.7.6 Domain Controller Unavailable

“Until a few minutes after Samba has started, clients get the error ‘Domain
Controller Unavailable’”
A domain controller has to announce its role on the network. This usually
takes a while. Be patient for up to 15 minutes, then try again.

4.7.7 Cannot Log onto Domain Member Workstation After Join-

ing Domain

After successfully joining the domain, user logons fail with one of two mes-
sages: one to the effect that the domain controller cannot be found; the other
claims that the account does not exist in the domain or that the password
Section 4.7. Common Errors 79

is incorrect. This may be due to incompatible settings between the Win-

dows client and the Samba-3 server for schannel (secure channel) settings or
smb signing settings. Check your Samba settings for client schannel, server
schannel, client signing, server signing by executing:

testparm -v | grep channel and looking for the value of these parameters.

Also use the MMC — Local Security Settings. This tool is available from the
Control Panel. The Policy settings are found in the Local Policies/Security
Options area and are prefixed by Secure Channel:..., and Digitally sign....
It is important that these be set consistently with the Samba-3 server set-
tings.
Chapter 5

BACKUP DOMAIN
CONTROL

Before you continue reading this section, please make sure that you are
comfortable with configuring a Samba domain controller as described in
Chapter 4, “Domain Control”.

5.1 Features and Benefits

This is one of the most difficult chapters to summarize. It does not matter
what we say here, for someone will still draw conclusions and/or approach
the Samba Team with expectations that are either not yet capable of being
delivered or that can be achieved far more effectively using a totally different
approach. In the event that you should have a persistent concern that is
not addressed in this book, please email John H. Terpstra1 clearly setting
out your requirements and/or question, and we will do our best to provide
a solution.
Samba-3 can act as a Backup Domain Controller (BDC) to another Samba
Primary Domain Controller (PDC). A Samba-3 PDC can operate with an
LDAP account backend. The LDAP backend can be either a common master
LDAP server or a slave server. The use of a slave LDAP server has the
benefit that when the master is down, clients may still be able to log onto
the network. This effectively gives Samba a high degree of scalability and is
an effective solution for large organizations. If you use an LDAP slave server
for a PDC, you will need to ensure the master’s continued availability — if
1
<mailto:[email protected]>

80
Section 5.2. Essential Background Information 81

the slave finds its master down at the wrong time, you will have stability
and operational problems.

While it is possible to run a Samba-3 BDC with a non-LDAP backend, that

backend must allow some form of ”two-way” propagation of changes from
the BDC to the master. At this time only LDAP delivers the capability to
propagate identity database changes from the BDC to the PDC. The BDC
can use a slave LDAP server, while it is preferable for the PDC to use as its
primary an LDAP master server.

The use of a non-LDAP backend SAM database is particularly problematic

because domain member servers and workstations periodically change the
Machine Trust Account password. The new password is then stored only lo-
cally. This means that in the absence of a centrally stored accounts database
(such as that provided with an LDAP-based solution) if Samba-3 is running
as a BDC, the BDC instance of the domain member trust account password
will not reach the PDC (master) copy of the SAM. If the PDC SAM is then
replicated to BDCs, this results in overwriting the SAM that contains the
updated (changed) trust account password with resulting breakage of the
domain trust.

Considering the number of comments and questions raised concerning how to

configure a BDC, let’s consider each possible option and look at the pros and
cons for each possible solution. Table 5.1 lists possible design configurations
for a PDC/BDC infrastructure.

5.2 Essential Background Information

A domain controller is a machine that is able to answer logon requests from

network workstations. Microsoft LanManager and IBM LanServer were two
early products that provided this capability. The technology has become
known as the LanMan Netlogon service.

When MS Windows NT3.10 was first released, it supported a new style

of Domain Control and with it a new form of the network logon service
that has extended functionality. This service became known as the NT
NetLogon Service. The nature of this service has changed with the evolution
of MS Windows NT and today provides a complex array of services that are
implemented over an intricate spectrum of technologies.
82 Backup Domain Control Chapter 5

Table 5.1. Domain Backend Account Distribution Options

PDC BDC Notes/Discussion
Backend Backend
Master Slave LDAP The optimal solution that provides high
LDAP Server Server integrity. The SAM will be replicated
to a common master LDAP server.
Single Single A workable solution without failover
Central Central ability. This is a usable solution, but
LDAP Server LDAP Server not optimal.
tdbsam tdbsam + Does not work with Samba-3.0; Samba
net rpc does not implement the server-side pro-
vampire tocols required.
tdbsam tdbsam Do not use this configuration. Does not
+ rsync work because the TDB files are live and
data may not have been flushed to disk.
Furthermore, this will cause domain
trust breakdown.
smbpasswd smbpasswd Do not use this configuration. Not an
file file elegant solution due to the delays in
synchronization and also suffers from
the issue of domain trust breakdown.

5.2.1 MS Windows NT4-style Domain Control

Whenever a user logs into a Windows NT4/200x/XP Professional worksta-

tion, the workstation connects to a domain controller (authentication server)
to validate that the username and password the user entered are valid. If
the information entered does not match account information that has been
stored in the domain control database (the SAM, or Security Account Man-
ager database), a set of error codes is returned to the workstation that has
made the authentication request.
When the username/password pair has been validated, the domain controller
(authentication server) will respond with full enumeration of the account
information that has been stored regarding that user in the user and machine
accounts database for that domain. This information contains a complete
network access profile for the user but excludes any information that is
particular to the user’s desktop profile, or for that matter it excludes all
desktop profiles for groups that the user may belong to. It does include
Section 5.2. Essential Background Information 83

password time limits, password uniqueness controls, network access time

limits, account validity information, machine names from which the user
may access the network, and much more. All this information was stored in
the SAM in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).
The account information (user and machine) on domain controllers is stored
in two files, one containing the security information and the other the SAM.
These are stored in files by the same name in the %SystemRoot%\System32\config
directory. This normally translates to the path C:\WinNT\System32\config.
These are the files that are involved in replication of the SAM database where
BDCs are present on the network.
There are two situations in which it is desirable to install BDCs:
• On the local network that the PDC is on, if there are many worksta-
tions and/or where the PDC is generally very busy. In this case the
BDCs will pick up network logon requests and help to add robustness
to network services.
• At each remote site, to reduce wide-area network traffic and to add
stability to remote network operations. The design of the network,
and the strategic placement of BDCs, together with an implementation
that localizes as much of network to client interchange as possible, will
help to minimize wide-area network bandwidth needs (and thus costs).
The interoperation of a PDC and its BDCs in a true Windows NT4 envi-
ronment is worth mentioning here. The PDC contains the master copy of
the SAM. In the event that an administrator makes a change to the user
account database while physically present on the local network that has the
PDC, the change will likely be made directly to the PDC instance of the
master copy of the SAM. In the event that this update may be performed
in a branch office, the change will likely be stored in a delta file on the lo-
cal BDC. The BDC will then send a trigger to the PDC to commence the
process of SAM synchronization. The PDC will then request the delta from
the BDC and apply it to the master SAM. The PDC will then contact all
the BDCs in the domain and trigger them to obtain the update and then
apply that to their own copy of the SAM.
Samba-3 cannot participate in true SAM replication and is therefore not
able to employ precisely the same protocols used by MS Windows NT4. A
Samba-3 BDC will not create SAM update delta files. It will not interoperate
with a PDC (NT4 or Samba) to synchronize the SAM from delta files that
are held by BDCs.
84 Backup Domain Control Chapter 5

Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and

Samba-3 cannot function correctly as a PDC to an MS Windows NT4 BDC.
Both Samba-3 and MS Windows NT4 can function as a BDC to its own
type of PDC.

The BDC is said to hold a read-only of the SAM from which it is able
to process network logon requests and authenticate users. The BDC can
continue to provide this service, particularly while, for example, the wide-
area network link to the PDC is down. A BDC plays a very important role
in both the maintenance of domain security as well as in network integrity.

In the event that the NT4 PDC should need to be taken out of service, or
if it dies, one of the NT4 BDCs can be promoted to a PDC. If this happens
while the original NT4 PDC is online, it is automatically demoted to an NT4
BDC. This is an important aspect of domain controller management. The
tool that is used to effect a promotion or a demotion is the Server Manager
for Domains. It should be noted that Samba-3 BDCs cannot be promoted in
this manner because reconfiguration of Samba requires changes to the smb.
conf file. It is easy enough to manuall change the smb.conf file and then
restart relevant Samba network services.

5.2.1.1 Example PDC Configuration

Beginning with Version 2.2, Samba officially supports domain logons for all
current Windows clients, including Windows NT4, 2003, and XP Profes-
sional. For Samba to be enabled as a PDC, some parameters in the [global]
section of the smb.conf have to be set. Refer to Example 5.2.1 for an ex-
ample of the minimum required settings.

Several other things like a [homes] and a [netlogon] share also need to be
set along with settings for the profile path, the user’s home drive, and so
on. This is not covered in this chapter; for more information please refer
to Chapter 4, “Domain Control”. Refer to Chapter 4, “Domain Control”
for specific recommendations for PDC configuration. Alternately, fully doc-
umented working example network configurations using OpenLDAP and
Samba as available in the book2 “Samba-3 by Example” that may be ob-
tained from local and on-line book stores.

2
<http://www.samba.org/samba/docs/Samba3-ByExample>
Section 5.2. Essential Background Information 85

Example 5.2.1. Minimal smb.conf for a PDC in Use with a BDC — LDAP
Server on PDC
 
workgroup = MIDEARTH
passdb backend = ldapsam : / / l o c a l h o s t : 3 8 9
domain master = y e s
domain l o g o n s = y e s
l d a p s u f f i x = dc=quenya , dc=o r g
l d a p u s e r s u f f i x = ou=U s e r s
l d a p group s u f f i x = ou=Groups
l d a p machine s u f f i x = ou=Computers
l d a p idmap s u f f i x = ou=Idmap
l d a p admin dn = cn=Manager , dc=quenya , dc=o r g
 

5.2.2 LDAP Configuration Notes

When configuring a master and a slave LDAP server, it is advisable to use

the master LDAP server for the PDC and slave LDAP servers for the BDCs.
It is not essential to use slave LDAP servers; however, many administrators
will want to do so in order to provide redundant services. Of course, one
or more BDCs may use any slave LDAP server. Then again, it is entirely
possible to use a single LDAP server for the entire network.

When configuring a master LDAP server that will have slave LDAP servers,
do not forget to configure this in the /etc/openldap/slapd.conf file. It
must be noted that the DN of a server certificate must use the CN attribute
to name the server, and the CN must carry the servers’ fully qualified domain
name. Additional alias names and wildcards may be present in the subjec-
tAltName certificate extension. More details on server certificate names are
in RFC2830.

It does not really fit within the scope of this document, but a working LDAP
installation is basic to LDAP-enabled Samba operation. When using an
OpenLDAP server with Transport Layer Security (TLS), the machine name
in /etc/ssl/certs/slapd.pem must be the same as in /etc/openldap/
sldap.conf. The Red Hat Linux startup script creates the slapd.pem file
with hostname “localhost.localdomain.” It is impossible to access this LDAP
server from a slave LDAP server (i.e., a Samba BDC) unless the certificate
is re-created with a correct hostname.
86 Backup Domain Control Chapter 5

Do not install a Samba PDC so that is uses an LDAP slave server. Joining
client machines to the domain will fail in this configuration because the
change to the machine account in the LDAP tree must take place on the
master LDAP server. This is not replicated rapidly enough to the slave
server that the PDC queries. It therefore gives an error message on the
client machine about not being able to set up account credentials. The
machine account is created on the LDAP server, but the password fields will
be empty. Unfortunately, some sites are unable to avoid such configurations,
and these sites should review the ldap replication sleep parameter, intended
to slow down Samba sufficiently for the replication to catch up. This is
a kludge, and one that the administrator must manually duplicate in any
scripts (such as the add machine script) that they use.
Possible PDC/BDC plus LDAP configurations include:
• PDC+BDC -> One Central LDAP Server.
• PDC -> LDAP master server, BDC -> LDAP slave server.
• PDC -> LDAP master, with secondary slave LDAP server.
BDC -> LDAP master, with secondary slave LDAP server.
• PDC -> LDAP master, with secondary slave LDAP server.
BDC -> LDAP slave server, with secondary master LDAP server.
In order to have a fallback configuration (secondary) LDAP server, you
would specify the secondary LDAP server in the smb.conf file as shown in
Example 5.2.2.

Example 5.2.2. Multiple LDAP Servers in smb.conf

 
passdb backend = ldapsam : ” l d a p : / / master . ←-
quenya . o r g l d a p : / / s l a v e . quenya . o r g ”
 

5.2.3 Active Directory Domain Control

As of the release of MS Windows 2000 and Active Directory, this information

is now stored in a directory that can be replicated and for which partial or
full administrative control can be delegated. Samba-3 is not able to be
a domain controller within an Active Directory tree, and it cannot be an
Section 5.2. Essential Background Information 87

Active Directory server. This means that Samba-3 also cannot act as a BDC
to an Active Directory domain controller.

5.2.4 What Qualifies a Domain Controller on the Network?

Every machine that is a domain controller for the domain MIDEARTH has
to register the NetBIOS group name MIDEARTH<1C> with the WINS
server and/or by broadcast on the local network. The PDC also registers
the unique NetBIOS name MIDEARTH<1B> with the WINS server. The
name type <1B> name is normally reserved for the Domain Master Browser
(DMB), a role that has nothing to do with anything related to authentica-
tion, but the Microsoft domain implementation requires the DMB to be on
the same machine as the PDC.

Where a WINS server is not used, broadcast name registrations alone must
suffice. Refer to Chapter 9, “Network Browsing”,Section 9.3 for more in-
formation regarding TCP/IP network protocols and how SMB/CIFS names
are handled.

5.2.5 How Does a Workstation find its Domain Controller?

There are two different mechanisms to locate a domain controller: one

method is used when NetBIOS over TCP/IP is enabled and the other when
it has been disabled in the TCP/IP network configuration.

Where NetBIOS over TCP/IP is disabled, all name resolution involves the
use of DNS, broadcast messaging over UDP, as well as Active Directory com-
munication technologies. In this type of environment all machines require
appropriate DNS entries. More information may be found in Section 9.3.3.

5.2.5.1 NetBIOS Over TCP/IP Enabled

An MS Windows NT4/200x/XP Professional workstation in the domain

MIDEARTH that wants a local user to be authenticated has to find the
domain controller for MIDEARTH. It does this by doing a NetBIOS name
query for the group name MIDEARTH<1C>. It assumes that each of the
machines it gets back from the queries is a domain controller and can answer
logon requests. To not open security holes, both the workstation and the
88 Backup Domain Control Chapter 5

selected domain controller authenticate each other. After that the worksta-
tion sends the user’s credentials (name and password) to the local domain
controller for validation.

5.2.5.2 NetBIOS Over TCP/IP Disabled

An MS Windows NT4/200x/XP Professional workstation in the realm quenya.

org that has a need to affect user logon authentication will locate the do-
main controller by re-querying DNS servers for the ldap. tcp.pdc. msdcs.
quenya.org record. More information regarding this subject may be found
in Section 9.3.3.

5.3 Backup Domain Controller Configuration

The creation of a BDC requires some steps to prepare the Samba server
before smbd is executed for the first time. These steps are as follows:
• The domain SID has to be the same on the PDC and the BDC. In
Samba versions pre-2.2.5, the domain SID was stored in the file pri-
vate/MACHINE.SID. For all versions of Samba released since 2.2.5 the
domain SID is stored in the file private/secrets.tdb. This file is
unique to each server and cannot be copied from a PDC to a BDC;
the BDC will generate a new SID at startup. It will overwrite the PDC
domain SID with the newly created BDC SID. There is a procedure
that will allow the BDC to aquire the domain SID. This is described
here.
To retrieve the domain SID from the PDC or an existing BDC and
store it in the secrets.tdb, execute:

root# net rpc getsid

• Specification of the ldap admin dn is obligatory. This also requires the

LDAP administration password to be set in the secrets.tdb using
the smbpasswd -w mysecret.
• The ldap suffix parameter and the ldap idmap suffix parameter must
be specified in the smb.conf file.
Section 5.3. Backup Domain Controller Configuration 89

• The UNIX user database has to be synchronized from the PDC to the
BDC. This means that both the /etc/passwd and /etc/group have
to be replicated from the PDC to the BDC. This can be done manually
whenever changes are made. Alternately, the PDC is set up as an NIS
master server and the BDC as an NIS slave server. To set up the BDC
as a mere NIS client would not be enough, as the BDC would not be
able to access its user database in case of a PDC failure. NIS is by no
means the only method to synchronize passwords. An LDAP solution
would also work.

• The Samba password database must be replicated from the PDC to the
BDC. Although it is possible to synchronize the smbpasswd file with
rsync and ssh, this method is broken and flawed, and is therefore
not recommended. A better solution is to set up slave LDAP servers
for each BDC and a master LDAP server for the PDC. The use of
rsync is inherently flawed by the fact that the data will be replicated
at timed intervals. There is no guarantee that the BDC will be oper-
ating at all times with correct and current machine and user account
information. This means that this method runs the risk of users being
inconvenienced by discontinuity of access to network services due to
inconsistent security data. It must be born in mind that Windows
workstations update (change) the machine trust account password at
regular intervals — administrators are not normally aware that this is
happening or when it takes place.

The use of LDAP for both the POSIX (UNIX user and group) accounts
and for the SambaSAMAccount data automatically ensures that all
account change information will be written to the shared directory.
This eliminates the need for any special action to synchronize account
information because LDAP will meet that requirement.

• The netlogon share has to be replicated from the PDC to the BDC.
This can be done manually whenever login scripts are changed, or it
can be done automatically using a cron job that will replicate the
directory structure in this share using a tool like rsync. The use of
rsync for replication of the netlogon data is not critical to network
security and is one that can be manually managed given that the
administrator will make all changes to the netlogon share as part of a
conscious move.
90 Backup Domain Control Chapter 5

5.3.1 Example Configuration

Finally, the BDC has to be capable of being found by the workstations.

This can be done by configuring the Samba smb.conf file [global] section as
shown in Example 5.3.1.

Example 5.3.1. Minimal Setup for Being a BDC

 
workgroup = MIDEARTH
passdb backend = ldapsam : l d a p : / / s l a v e −l d a p . ←-
quenya . o r g
domain master = no
domain l o g o n s = y e s
l d a p s u f f i x = dc=abmas , dc=b i z
l d a p u s e r s u f f i x = ou=U s e r s
l d a p group s u f f i x = ou=Groups
l d a p machine s u f f i x = ou=Computers
l d a p idmap s u f f i x = ou=Idmap
l d a p admin dn = cn=Manager , dc=quenya , dc=o r g
idmap backend = l d a p : l d a p : / / master−l d a p . ←-
quenya . o r g
idmap u i d = 10000 −20000
idmap g i d = 10000 −20000
 

Fully documented working example network configurations using OpenL-

DAP and Samba as available in the book3 “Samba-3 by Example” that may
be obtained from local and on-line book stores.
This configuration causes the BDC to register only the name MIDEARTH<1C>
with the WINS server. This is not a problem, as the name MIDEARTH<1C>
is a NetBIOS group name that is meant to be registered by more than one
machine. The parameter domain master = no forces the BDC not to reg-
ister MIDEARTH<1B>, which is a unique NetBIOS name that is reserved
for the PDC.
The idmap backend will redirect the winbindd utility to use the LDAP
database to store all mappings for Windows SIDs to UIDs and GIDs for
UNIX accounts in a repository that is shared. The BDC will however depend
on local resolution of UIDs and GIDs via NSS and the nss ldap utility.
3
<http://www.samba.org/samba/docs/Samba3-ByExample>
Section 5.4. Common Errors 91

Note

Samba-3 has introduced a new ID mapping facility. One

of the features of this facility is that it allows greater flex-
ibility in how user and group IDs are handled in respect
to NT domain user and group SIDs. One of the new fa-
cilities provides for explicitly ensuring that UNIX/Linux
UID and GID values will be consistent on the PDC, all
BDCs, and all domain member servers. The parameter
that controls this is called idmap backend. Please re-
fer to the man page for smb.conf for more information
regarding its behavior.

The use of the idmap backend = ldap:ldap://master.quenya.org option on

a BDC only makes sense where ldapsam is used on a PDC. The purpose of
an LDAP-based idmap backend is also to allow a domain member (without
its own passdb backend) to use winbindd to resolve Windows network users
and groups to common UID/GIDs. In other words, this option is generally
intended for use on BDCs and on domain member servers.

5.4 Common Errors

Domain control was a new area for Samba, but there are now many exam-
ples that we may refer to. Updated information will be published as they
become available and may be found in later Samba releases or from the
Samba Web site4 ; refer in particular to the WHATSNEW.txt in the Samba
release tarball. The book, “Samba-3 by Example” documents well tested
and proven configuration examples. You can obtain a copy of this book5 for
the Samba web site.

4
<http://samba.org>
5
<http://www.samba.org/samba/docs/Samba3-ByExample.pdf>
92 Backup Domain Control Chapter 5

5.4.1 Machine Accounts Keep Expiring

This problem will occur when the passdb (SAM) files are copied from a
central server but the local BDC is acting as a PDC. This results in the
application of Local Machine Trust Account password updates to the local
SAM. Such updates are not copied back to the central server. The newer
machine account password is then overwritten when the SAM is recopied
from the PDC. The result is that the domain member machine on startup
will find that its passwords do not match the one now in the database, and
since the startup security check will now fail, this machine will not allow
logon attempts to proceed and the account expiry error will be reported.

The solution is to use a more robust passdb backend, such as the ldapsam
backend, setting up a slave LDAP server for each BDC and a master LDAP
server for the PDC.

5.4.2 Can Samba Be a Backup Domain Controller to an NT4

PDC?

No. The native NT4 SAM replication protocols have not yet been fully
implemented.

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

5.4.3 How Do I Replicate the smbpasswd File?

Replication of the smbpasswd file is sensitive. It has to be done whenever

changes to the SAM are made. Every user’s password change is done in
the smbpasswd file and has to be replicated to the BDC. So replicating the
smbpasswd file very often is necessary.

As the smbpasswd file contains plaintext password equivalents, it must not

be sent unencrypted over the wire. The best way to set up smbpasswd
replication from the PDC to the BDC is to use the utility rsync. rsync can
use ssh as a transport. ssh itself can be set up to accept only rsync transfer
without requiring the user to type a password.
Section 5.4. Common Errors 93

As said a few times before, use of this method is broken and flawed. Machine
trust accounts will go out of sync, resulting in a broken domain. This method
is not recommended. Try using LDAP instead.

5.4.4 Can I Do This All with LDAP?

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

DOMAIN MEMBERSHIP

Domain membership is a subject of vital concern. Samba must be able

to participate as a member server in a Microsoft domain security context,
and Samba must be capable of providing domain machine member trust
accounts; otherwise it would not be able to offer a viable option for many
users.

This chapter covers background information pertaining to domain member-

ship, the Samba configuration for it, and MS Windows client procedures
for joining a domain. Why is this necessary? Because both are areas in
which there exists within the current MS Windows networking world, and
particularly in the UNIX/Linux networking and administration world, a
considerable level of misinformation, incorrect understanding, and lack of
knowledge. Hopefully this chapter will fill the voids.

6.1 Features and Benefits

MS Windows workstations and servers that want to participate in domain

security need to be made domain members. Participating in domain security
is often called single sign-on, or SSO for short. This chapter describes the
process that must be followed to make a workstation (or another server —
be it an MS Windows NT4/200x server) or a Samba server a member of an
MS Windows domain security context.

Samba-3 can join an MS Windows NT4-style domain as a native member

server, an MS Windows Active Directory domain as a native member server,
or a Samba domain control network. Domain membership has many advan-
tages:

94
Section 6.2. MS Windows Workstation/Server Machine Trust Accounts 95

• MS Windows workstation users get the benefit of SSO.

• Domain user access rights and file ownership/access controls can be set
from the single Domain Security Account Manager (SAM) database
(works with domain member servers as well as with MS Windows
workstations that are domain members).
• Only MS Windows NT4/200x/XP Professional workstations that are
domain members can use network logon facilities.
• Domain member workstations can be better controlled through the
use of policy files (NTConfig.POL) and desktop profiles.
• Through the use of logon scripts, users can be given transparent access
to network applications that run off application servers.
• Network administrators gain better application and user access man-
agement abilities because there is no need to maintain user accounts
on any network client or server other than the central domain database
(either NT4/Samba SAM-style domain, NT4 domain that is backend-
ed with an LDAP directory, or via an Active Directory infrastructure).

6.2 MS Windows Workstation/Server Machine Trust Ac-

counts

A Machine Trust Account is an account that is used to authenticate a client

machine (rather than a user) to the domain controller server. In Windows
terminology, this is known as a “computer account.” The purpose of the
machine trust account is to prevent a rogue user and domain controller from
colluding to gain access to a domain member workstation.
The password of a Machine Trust Account acts as the shared secret for
secure communication with the domain controller. This is a security feature
to prevent an unauthorized machine with the same NetBIOS name from
joining the domain, participating in domain security operations, and gaining
access to domain user/group accounts. Windows NT/200x/XP Professional
clients use machine trust accounts, but Windows 9x/Me/XP Home clients
do not. Hence, a Windows 9x/Me/XP Home client is never a true member
of a domain because it does not possess a Machine Trust Account, and, thus,
has no shared secret with the domain controller.
A Windows NT4 PDC stores each Machine Trust Account in the Windows
96 Domain Membership Chapter 6

Registry. The introduction of MS Windows 2000 saw the introduction of

Active Directory, the new repository for Machine Trust Accounts. A Samba
PDC, however, stores each Machine Trust Account in two parts, as follows:

• A domain security account (stored in the passdb backend ) that has

been configured in the smb.conf file. The precise nature of the account
information that is stored depends on the type of backend database
that has been chosen.

The older format of this data is the smbpasswd database that contains
the UNIX login ID, the UNIX user identifier (UID), and the LanMan
and NT-encrypted passwords. There is also some other information in
this file that we do not need to concern ourselves with here.

The two newer database types are called ldapsam and tdbsam. Both
store considerably more data than the older smbpasswd file did. The
extra information enables new user account controls to be implemented.

• A corresponding UNIX account, typically stored in /etc/passwd. Work

is in progress to allow a simplified mode of operation that does not re-
quire UNIX user accounts, but this has not been a feature of the early
releases of Samba-3, and is not currently planned for release either.

There are three ways to create Machine Trust Accounts:

• Manual creation from the UNIX/Linux command line. Here, both the
Samba and corresponding UNIX account are created by hand.

• Using the MS Windows NT4 Server Manager, either from an NT4

domain member server or using the Nexus toolkit available from the
Microsoft Web site. This tool can be run from any MS Windows
machine as long as the user is logged on as the administrator account.

• “On-the-fly” creation. The Samba Machine Trust Account is automat-

ically created by Samba at the time the client is joined to the domain.
(For security, this is the recommended method.) The corresponding
UNIX account may be created automatically or manually.

Neither MS Windows NT4/200x/XP Professional, nor Samba, provide any

method for enforcing the method of machine trust account creation. This is
a matter for the administrator’s choice.
Section 6.2. MS Windows Workstation/Server Machine Trust Accounts 97

6.2.1 Manual Creation of Machine Trust Accounts

The first step in manually creating a Machine Trust Account is to manually

create the corresponding UNIX account in /etc/passwd. This can be done
using vipw or another “adduser” command that is normally used to create
new UNIX accounts. The following is an example for a Linux-based Samba
server:

root# /usr/sbin/useradd -g machines -d /var/lib/nobody -c "machine nickname" \

-s /bin/false machine_name$

root# passwd -l machine_name$

In the example above there is an existing system group “machines” which

is used as the primary group for all machine accounts. In the following
examples the “machines” group numeric GID is 100.

On *BSD systems, this can be done using the chpass utility:

root# chpass -a \
’machine_name$:*:101:100::0:0:Windows machine_name:/dev/null:/sbin/nologin’

The /etc/passwd entry will list the machine name with a “$” appended,
and will not have a password, will have a null shell and no home directory.
For example, a machine named “doppy” would have an /etc/passwd entry
like this:

doppy$:x:505:100:machine_nickname:/dev/null:/bin/false

in which machine nickname can be any descriptive name for the client,
such as BasementComputer. machine name absolutely must be the NetBIOS
name of the client to be joined to the domain. The “$” must be appended
to the NetBIOS name of the client or Samba will not recognize this as a
Machine Trust Account.

Now that the corresponding UNIX account has been created, the next step is
to create the Samba account for the client containing the well-known initial
98 Domain Membership Chapter 6

Machine Trust Account password. This can be done using the smbpasswd
command as shown here:

root# smbpasswd -a -m machine_name

where machine name is the machine’s NetBIOS name. The RID of the new
machine account is generated from the UID of the corresponding UNIX
account.

Join the client to the domain immediately

Manually creating a Machine Trust Account using this

method is the equivalent of creating a Machine Trust
Account on a Windows NT PDC using the Server Man-
ager. From the time at which the account is created
to the time the client joins the domain and changes the
password, your domain is vulnerable to an intruder join-
ing your domain using a machine with the same NetBIOS
name. A PDC inherently trusts members of the domain
and will serve out a large degree of user information to
such clients. You have been warned!

6.2.2 Managing Domain Machine Accounts using NT4 Server

Manager

A working add machine script is essential for machine trust accounts to be

automatically created. This applies no matter whether you use automatic
account creation or the NT4 Domain Server Manager.
If the machine from which you are trying to manage the domain is an MS
Windows NT4 workstation or MS Windows 200x/XP Professional, the tool
of choice is the package called SRVTOOLS.EXE. When executed in the
target directory it will unpack SrvMgr.exe and UsrMgr.exe (both are
domain management tools for MS Windows NT4 workstation).
If your workstation is a Microsoft Windows 9x/Me family product, you
Section 6.2. MS Windows Workstation/Server Machine Trust Accounts 99

should download the Nexus.exe package from the Microsoft Web site.
When executed from the target directory, it will unpack the same tools
but for use on this platform.
Further information about these tools may be obtained from the following
locations:
Knowledge Base article 1736731
Knowledge Base article 1725402
Launch the srvmgr.exe (Server Manager for Domains) and follow these
steps: Server Manager Account Machine Account Management
1. From the menu select Computer.
2. Click Select Domain.
3. Click the name of the domain you wish to administer in the Select
Domain panel and then click OK.
4. Again from the menu select Computer.
5. Select Add to Domain.
6. In the dialog box, click the radio button to Add NT Workstation of
Server, then enter the machine name in the field provided, and click
the Add button.

6.2.3 On-the-Fly Creation of Machine Trust Accounts

The third (and recommended) way of creating Machine Trust Accounts is

simply to allow the Samba server to create them as needed when the client
is joined to the domain.
Since each Samba Machine Trust Account requires a corresponding UNIX
account, a method for automatically creating the UNIX account is usually
supplied; this requires configuration of the add machine script option in smb.
conf. This method is not required; however, corresponding UNIX accounts
may also be created manually.
Here is an example for a Red Hat Linux system:
 
[ global ]
add machine s c r i p t = / u s r / s b i n / us e radd −d / ←-
var / l