QLX26STUD

Linux Integration
with Windows (Samba)

(Course Code QLX26)
Student Notebook
ERC 5.0
IBM Certified Course Material

V1.2.2.2
cover
Student Notebook
The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. The original
repository material for this course has been certified as being Year 2000 compliant.
Copyright International Business Machines Corporation 1999, 2005. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
Trademarks
IBM is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Pentium is a trademark of Intel Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
AIX Hummingbird Perform
PowerPC PS/2 SP
March 2005 Edition
Student Notebook
Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Copyright IBM Corp. 1999, 2005 Contents iii
V1.2.2
TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Unit 1. Samba Overview and Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
What is Samba? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Samba Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Samba Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
smb.conf Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Samba Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Locating the Samba Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
File System Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Perform the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Verifying the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
The smbclient Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Unit 2. Network Browsing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
NetBIOS System Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Local Master Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
NetBIOS over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Domain Master Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Mapping IP Addresses to NetBIOS Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Unit 3. Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Win9x Password-Protected Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
WinNT Password-Protected User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Samba Username/Password Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Samba Groupname Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Encrypted Passwords (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Encrypted Passwords (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
pdbedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Guest Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Student Notebook
iv Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-17
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18
Unit 4. File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
The Purpose of File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Common Candidates for Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Sharing Home Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Sharing Other Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Filename Mangling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
Windows NT Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Other Sharing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
MS-Distributed File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
Unit 5. Printer Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2
Why Printer Sharing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3
Top-Level Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5
Example of Printer Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
Printer Drivers and Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
Auto Driver Installation Under Windows (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
Auto Driver Installation under Windows (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12
Pseudo-Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16
Unit 6. Windows NT Domain Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
A Windows Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
Remote Authentication with security=server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Remote Authentication with security=domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
Samba Primary Domain Controller Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
User/Group Management in a Samba Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13
Unit 7. Windows 2000 Domain Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Differences Between NT and 2000 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
Local Registry versus Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5
Username/Password versus Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Samba in a Windows 2000 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-11
Student Notebook
Copyright IBM Corp. 1999, 2005 Contents v
V1.2.2
TOC
Unit 8. User Policies and Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
User and Group Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
poledit.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Mapping Home Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Logon Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Unit 9. The LDAPSAM Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Security Account Manager Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Whats a Directory? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Directories versus Relational Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
LDAP Concepts (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
LDAP Concepts (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
The Core Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
The NIS Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
The Samba Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Typical LDAPSAM Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
The Samba/UNIX/LDAP Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Configure OpenLDAP - General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Configure OpenLDAP - Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
smbldap Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Configure UNIX Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Configure Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Migrating an Existing Domain to Samba/LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-30
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
Unit 10. WinBind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Domain Member Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Winbind Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Winbind Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Configure Winbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Configure NSS and PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Automatic Creation of Home Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Unit 11. Configuring Samba Using SWAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Samba Web Administration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
What Can SWAT Do For You? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
SWAT Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Student Notebook
vi Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
SWAT Globals Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
SWAT Shares Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7
SWAT Status Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8
What SWAT Cannot Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
Configuring [x]inetd to Support SWAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-13
Unit 12. Tips and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
Security Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5
Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-7
Test 1 Syntax of smb.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9
Test 2 Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10
Test 3 Connect to the Samba Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11
Test 4 Samba's Name Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
Test 5 Client Response to Name Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14
Test 6 Client Response to Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15
Test 7 Session Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16
Test 8 Client's Name Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17
Test 9 User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
Test 10 Full Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19
Still Having Trouble? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-21
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-22
Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Appendix C. List of smb.conf Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
Student Notebook
Copyright IBM Corp. 1999, 2005 Trademarks vii
V1.2.2
TMK
Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Pentium is a trademark of Intel Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
AIX Hummingbird Perform
PowerPC PS/2 SP
Student Notebook
viii Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Student Notebook
Copyright IBM Corp. 1999, 2005 Course Description ix
V1.2.2 BKM2MIF
Uempty
Course Description
Linux Integration with Windows (Samba)
Duration: 3 days
Purpose
This course is designed to teach the student how to install, configure,
and use the Samba package to share files and printers from a Linux
system on a Windows-based LAN. The course also covers Windows
NT/2000 domain membership and domain control.
Audience
The typical student will be a Linux system administrator who needs to
provide a file server and/or printer server for a Windows-based
network of workstations. Other candidates will be management
professionals concerned with the management of such a system.
Prerequisites
Familiarity with UNIX commands is required. Some background with
Windows-based networking would be helpful, as would a broad
understanding of networking concepts, but these are not required.
Objectives
At the end of the course, students should be familiar with and be able
to perform/configure:
Samba Overview and installation
Network Browsing
Authentication
File Sharing
Printer Sharing
Windows NT Domain Support
Windows 2000 Domain Support
User Policies and Profiles
The LDAPSAM backend
Winbind
Student Notebook
x Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
SWAT
Troubleshooting
Student Notebook
Copyright IBM Corp. 1999, 2005 Agenda xi
V1.2.2 BKM2MIF
Uempty
Agenda
Day 1
Welcome
Unit 1 - Samba Overview and Installation
Exercise 1 - Installing Samba
Unit 2 - Network Browsing
Exercise 2 - Network Browsing
Unit 3 - Authentication
Exercise 3 - Authentication
Unit 4 - File Sharing
Exercise 4 - File Sharing
Day 2
Unit 5 - Printer Sharing
Exercise 5 - Printer Sharing
Unit 6 - Windows NT Domain Support
Exercise 6 - Windows NT Domain Support
Unit 7 - Windows 2000 Domain Support
Unit 8 - User Policies and Profiles
Exercise 8 - User Policies and Profiles
Day 3
Unit 9 - The LDAPSAM Backend
Exercise 9 - The LDAPSAM Backend
Unit 10 - Winbind
Unit 11 - Configuring Samba Using SWAT
Exercise 11 - Configuring Samba Using SWAT
Unit 12 - Tips and Techniques
Student Notebook
xii Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Student Notebook
Copyright IBM Corp. 1999, 2005 Certification Information xiii
V1.2.2 BKM2MIF
Uempty
Certification Information
Several professional certifications currently exist for Linux. This
course, combined with other Linux courses, will prepare you for all of
them. For more information, see appendix B.
This course, in combination with other courses, has been certified by
ProCert (http://www.procert.com) as appropriate course material for
preparing for LPI certification tests. The statement below reflects this.
Linux Professional Institute Statement
This course is specifically designed to provide you with the skills,
knowledge and understanding required to become professionally
certified by LPI. To learn more about LPI certifications, or to register to
take an official LPI certification exam, visit www.lpi.org.
Student Notebook
xiv Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 1. Samba Overview and Installation 1-1
V1.2.2 BKM2MIF
Uempty
Unit 1. Samba Overview and Installation
What This Unit Is About
This unit covers the Samba product and the different ways in which it
can be installed.
What You Should Be Able to Do
After completing this unit, you should be able to:
Give an overview of Samba
Discuss the different distribution formats of Samba
Install Samba
How You Will Check Your Progress
Accountability:
Checkpoint questions
Lab exercises
Student Notebook
1-2 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Figure 1-1. Unit Objectives LX265.0
Notes:
Copyright BM Corporation 2005
Unit Objectives
Give an overview of Samba
Discuss the different distribution formats of Samba
nstall Samba
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 1-2. What is Samba? LX265.0
Notes:
Samba is a product for integrating UNIX systems into a Windows network in such a fashion
that the Windows clients and servers do not need to be changed. This means that Samba
closely implements the Windows protocols and services.
Samba can run on any UNIX system, including Linux, AIX, HP-UX and Solaris.
Samba is an open-source project, developed and maintained by a virtual, worldwide team.
Its main Web site is http://www.samba.org.
What Is Samba?
A product for integrating UNX into a Windows network
No changes needed to Windows clients, servers
Runs on any UNX
Linux
AX
HP-UX
Solaris
Open Source (licensed under GNU GPL)
Developed and maintained by a virtual, worldwide team
Main Samba portal: www.samba.org
Student Notebook
Figure 1-3. Samba Features LX265.0
Notes:
Samba was originally written as a server product. However, in the course of developing the
server, several client tools were developed as well. These were mainly used to test the
server, but can also be used as standalone programs running on a workstation.
Both the client and the server programs basically support the following:
Browsing is the process whereby servers, between one another, discover who else is
active on the network, and what shares each server is offering. This is a highly
complicated process, but the end result is your Network Neighborhood window, which
lists all systems in the network. Samba can implement almost all functions required for
browsing.
Authentication is the process whereby it is established that a user is really who they
say they are. This is usually done by requiring the user to supply a password, and then
testing this password against a password database. This is supported to a large extent
by Samba, including nearly full support for Windows domains.
File sharing means that users can access files that are stored on a remote system.
Print sharing means that users can print files to printers that are attached to remote
systems.
Samba Features
Browsing
NetBOS over TCP/P
Local Master Browser
Domain Master Browser
WNS client support
WNS server support
Authentication
Unencrypted/encrypted passwords
Domain logons
Domain server
File sharing
Printer sharing
Remote printing
Automated configuration of printer drivers
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 1-4. Samba Overview LX265.0
Notes:
The Samba product consists of a large number of programs and files. Here are the most
important ones:
Two daemons. These two daemons (nmbd and smbd) handle name lookup and
browsing (nmbd) and authentication, file and print sharing (smbd). For a Samba server
implementation, these two daemons need to be running at all times.
A global configuration file: smb.conf. This file contains the global Samba configuration,
and is read by virtually all Samba programs, including smbd, nmbd, smbclient and
nmblookup. The location of this file depends on installation options chosen, but is
usually /etc/smb.conf or /etc/samba/smb.conf.
Various other configuration files, such as smbusers, smbpasswd and lmhosts. These
files are normally located in the same directory as smb.conf, and are referenced in
smb.conf.
Various user space tools. These tools either support the Samba daemons, or are used
by UNIX users as client-side tools.
Two daemons
nmbd: name lookup, browsing
smbd: authentication, file and print sharing
Global configuration file: smb.conf
Various other configuration files (referenced in smb.conf):
smbusers
smbpasswd
lmhosts
Various user-space tools
smbclient
nmblookup
smbprint
smbmount
net
GU admin tool: SWAT
Samba Overview
Student Notebook
A GUI administration tool: SWAT (Samba Web Administration Tool). SWAT is
developed alongside all the other Samba tools and is thus always kept up to date. It
implements a Web (HTTP/HTML) interface at TCP port 901, which allows you to create
your smb.conf file using a browser such as Netscape, Konqueror, Mozilla or Lynx.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 1-5. smb.conf Overview LX265.0
Notes:
The smb.conf file is the main configuration file of Samba. It is read by virtually all daemons
and other tools. Depending on the way the distribution is installed, it can typically be found
in /etc or /etc/samba.
The file is organized like a Windows .INI file: It contains multiple sections which are
identified with the section name in square brackets. Within each section you can specify
various options which always have the layout keyword = value. Various keywords and
values in Samba have synonyms and/or antonyms. For instance public = yes has the
same meaning as guest ok = true, and read only = yes is the exact opposite of writable
= yes.
The first section in the smb.conf file has to be the [global] section. It may define a large
number of global variables, which apply to all sections, daemons and/or tools. Some
general examples are:
netbios name The netbios name of this system.
workgroup The workgroup or domain that this system is a member of.
smb.conf Overview
Main configuration file of Samba
Typically located in /etc or /etc/samba
Global options in [gIobaI] section
For example; netbios name, Iog IeveI, Iog fiIe, hosts aIIow,
incIude, socket options, interfaces
Shares specified in [sharename] sections
Can have as many shares as you want
[homes] and [printers] are special template shares
Can contain variables (start with %)
testparm checks syntax of this file
Restart Samba daemons after editing this file
Student Notebook
log level A numeric value (0-100) which indicates how much logging output we
want.
log file Name of the Samba log file.
hosts allow A list of IP addresses and/or hostnames that are allowed to access the
Samba daemons.
include Name of a Samba configuration file which needs to be included at this
point.
socket options TCP Socket options. These can be used for tuning.
interfaces Interfaces that Samba needs to bind to.
During this course we will introduce a large number of other options.
The next sections of the smb.conf file all specify shares. Shares can be used for disk
sharing and printer sharing. Two special shares may be defined: [homes] and [printers]
These shares are used for sharing all home directories and all printers, respectively.
The smb.conf file may use variables instead of values, or variables as part of values. All
these variables start with a percent (%) sign and are interpreted by the daemon based on
the characteristics of the connection. As an example, the variable %u is replaced by the
username of the user that is logged on in that particular connection. A complete list of
smb.conf variables can be found in the appendix.
The smb.conf file is all-important, and it is a good habit to use the syntax checker testparm
before you actually restart your daemons to have them load a changed configuration file.
Do this every time you edit the smb.conf file.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 1-6. Samba Installation Overview LX265.0
Notes:
Before installing the Samba package, we should take a look at just what installation
includes.
Installation is composed of a number of parts. First is the acquisition of the software.
Second is to check the directories used for installation to determine if there are any
conflicts with existing software, and to ensure that those directories will supply adequate
space. And third, unpacking the software.
These procedures will be discussed in more detail over the next few pages.
Samba InstaIIation Overview
Locate and download the software
Solve file system conflicts
Perform the installation
Student Notebook
Figure 1-7. Locating the Samba Software LX265.0
Notes:
The first part of the installation involves locating the software. There are a number of ways
that software is distributed for the Linux system. Today, the main distribution channels are
Internet downloads and physical distribution on CD-ROM or DVD.
Samba can be distributed in various formats too:
The first is as a compressed TAR image of the source files. This is the way the Samba
team makes Samba available. When using this method, you need to compile the
sources yourself on your own system.
Precompiled binaries are sometimes distributed as compressed TAR archives as well.
The RPM Package Manager (RPM) format is a very convenient way to distribute
software. It is essentially a compressed cpio archive with additional information which
defines prerequisite packages and versions, install and uninstall scripts, and so forth.
These features allow the RPM packages to do a small amount of self-tailoring for the
system they're being installed on. RPMs can be distributed containing either binaries or
source code. Source code RPMs are usually called SRPMs.
Locating the Samba Software
Distribution options
nternet
CD-ROM, DVD
Distribution formats
.tar.gz file of source code
.tar.gz file of binaries
RPM file of source code - generic
RPM file of binaries - generic
RPM file of source code - from your distribution
RPM file of binaries - from your distribution
Student Notebook
V1.2.2 BKM2MIF
Uempty
RPMs can be generated by anyone, not just Red Hat. This means that you may find
RPMs that are created by volunteers on the Internet, which should work on any
distribution, and RPMs that are created by your distribution manufacturer. These RPMs
are typically tailored for your distribution.
Student Notebook
Figure 1-8. File System Conflicts LX265.0
Notes:
The next step is to review the directories that will be used by the software to make sure that
those directories are not already in use and contain conflicting file names.
In most cases, this step isn't really necessary because most packages will store their files
into a subdirectory which is based on the name of the package. For example, Samba by
default stores its configuration file as /etc/smb.conf and user information as
/etc/smbusers -- it's unlikely that another package will use the same name. But it can
happen, and the experienced administrator knows how much easier it is to check in
advance than to repair the damage afterwards! But if a directory is unpacked with different
permissions than the directory that already exists, permission problems can occur when
applications try to access that directory.
For TAR images, using tar -ztvf <pkgname>.tgz will provide a list of the contents of the
image. Then that list should be compared against your system's current state.
For RPM images, you can use rpm -qip <pkgname>.rpm to see an overview of what the
package is and does, and it often contains installation information, if necessary. Otherwise,
you can use rpm -qlp <pkgname>.rpm to list the filenames included in the package.
FiIe System ConfIicts
Directories
Problems with existing directories
Different ownership/permissions
Filenames
Problems with existing files
Different ownership/permissions
File system free space
Student Notebook
V1.2.2 BKM2MIF
Uempty
It's also possible to run out of space in the file system during installation. To check this,
you'll need to know the uncompressed size of the package. Use either tar -zt or rpm -qvl to
obtain that information. Unfortunately, when rpm -qip reports a size requirement, it doesn't
take into account the partitions on the existing system; the number it provides is a grand
total of the space required.
Student Notebook
Figure 1-9. Perform the Installation LX265.0
Notes:
The last step is to actually perform the installation. How this is done depends on the
distribution format:
The most complicated installation is when you have downloaded the source files from
the Samba Web site in .tar.gz format. You first need to unpack this file into a separate
directory. This is done with the tar -zxvf samba-version.tar.gz command. The
separate directory is usually created automatically.
Once unpacked, you need to configure Samba for your architecture. This is done with a
configure script, which comes with Samba. The configure script takes a large number
of options: Execute the ./configure --help command to see the options that are
available.
After configuration has finished you need to run make to compile all programs, and
make install to install the programs in the proper directories. The directories where the
programs and other files will be installed depend on the options that were passed to the
configure program.
Perform the InstaIIation
.tar.gz file of source code
tar -zxvf samba-version.tar.gz
./configure
make
make instaII
.tar.gz image of binaries
tar -zxvf samba-version.tar.gz
Look for INSTALL and README files
RPM file of binaries
rpm -ivh samba-version.arch.rpm
RPM file of source code
rpm -ivh samba-version.src.rpm
rpmbuiId -bb samba-version.spec
rpm -ivh samba-version.arch.rpm
Student Notebook
V1.2.2 BKM2MIF
Uempty
If you've got a .tar.gz image of the binaries, then you need to unpack this file with the tar
-zxvf samba-version.tar.gz command as well. Then, look for the INSTALL and
README files, which contain detailed instructions on how to install the programs and
other files properly on your architecture.
If you've got the RPM file of the binaries, all you need to do is install it with the
command rpm -ivh samba-version.arch.rpm. Keep in mind that distribution vendors
often separate the Samba binaries into several RPM package files. You may have to
specify more than one file with the RPM command.
If you've got the RPM file of the sources, then the first thing you need to do is install it.
This will create a number of files on your system, one of which is the file
samba-version.spec file. This file contains all the information and commands required
to build the binary RPM. With the rpm -bb samba-version.spec command you start
the build process of this binary RPM (use rpmbuild for RPM v4 had higher). At the end
of the process, you can install the binary RPMs, just like before, with the rpm -ivh
samba-version.arch.rpm command.
The advantage of the RPM technique is that it allows the computer to issue warnings and
errors if prerequisite software isn't available when the installation is performed. Typically,
this means installing the prerequisites first. Also, the RPM system admonishes adherence
to the Linux FSSTND (File System Standard) by all package builders. The FSSTND
specifies where configuration files should be placed, where program files should be put,
and so on. (See it at http://www.pathname.com/fhs/)
Student Notebook
Figure 1-10. Verifying the Installation LX265.0
Notes:
The installation can be verified in a number of ways. The best technique is to try running
the server daemon because checking each option is not practical.
If you already had a working Samba configuration, that same configuration file should still
work. A simple way to check this is with the testparm program which is installed along with
the rest of the binaries. When you run testparm, it reads in the specified configuration file
using the same technique as the Samba server (it literally calls the same functions). After
generating any warnings or errors, it dumps the configuration to stdout, allowing you to
verify it visually.
Then start the server. If this is an upgrade from an existing installation, you may have to
stop the previous server first. So choose either /etc/rc.d/init.d/smb start or
/etc/rc.d/init.d/smb restart, respectively, depending on which of those situations apply to
your site. Note that networking must be configured and running before the server will run.
In order to run the server automatically upon boot-up, execute chkconfig smb on.
Finally, browse the network from a client. If you are using Windows Explorer, you should
see the default network name of Mygroup under the Entire Network tree. If you are using
Verifying the InstaIIation
testparm: Tests syntax of smb.conf file
testprns: Tests availability of samba printers
Start the server
Samba start or use distribution-specific scripts
May have to stop the existing server
Browse the Samba server
Use Windows ExpIorer from a Windows client
Use smbcIient from the same machine
Use smbcIient from another Linux host
Use graphical Linux file manager
konqueror uses Ian:// or rIan://
NautiIus uses smb://
Student Notebook
V1.2.2 BKM2MIF
Uempty
smbclient, you should see a list of default shares (one of them will be IPC$). The following
page describes the options on smbclient.
Many Linux distributions include graphical file managers that are also able to browse the
network. Konqueror in the KDE environment and Nautilus in the GNOME environment
have this ability.
Student Notebook
Figure 1-11. The smbclient Command LX265.0
Notes:
The smbclient command comes with the Samba package. It is used as the Linux client for
connecting to SMB shares.
The first example given above logs in to the Samba server as the guest account (discussed
more in the next unit) and lists the resources available on that server.
The second example of the command provides an interactive session, similar to the one
that ftp provides. Once connected, the user can issue get and put commands to retrieve or
send files.
The -L option should be used to determine if the Samba server is even running and
listening for network requests. The version that connects to a share name will determine if
specific shares are configured correctly. The default is for users home directories to be
automatically shared by Samba, so the above command should function correctly. In later
units, we'll learn how to add additional shares, both disk space and printers.
The smbcIient Command
smbcIient -L ServerName {-N|-U UserName}
Logs on to ServerName as a guest or as UserName and lists
information about the server
ServerName is the NetBOS name of the machine, or the Linux
host name if the NetBOS name hasn't been configured
smbcIient //ServerName/share {-N|-U UserName}
Provides an interactive, ftp-like, file transfer session
Log on to ServerName as guest or as UserName
Connects to share
Should receive an interactive smb:> prompt which accepts
ftp-style commands Is, dir, get, put, ...
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 1-12. Checkpoint LX265.0
Notes:
Write down your answers here:
1.
2.
3.
Checkpoint
1. T/F. The main configuration file of Samba is smb.conf.
2. T/F. Samba always needs to be installed from the source, if your
distribution does not provide an RPM.
3. T/F. When installing from source, you can select where all files go
when you run the make install command.
Student Notebook
Figure 1-13. Unit Summary LX265.0
Notes:
Unit Summary
Samba Overview
Samba nstallation
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 2. Network Browsing 2-1
V1.2.2 BKM2MIF
Uempty
Unit 2. Network Browsing
This unit covers network browsing, which is the way for a
NetBIOS-based network to determine which systems are available in
the network, and what shares they offer.
Describe how a NetBIOS system is identified
Describe the function of a Local Master Browser and Domain
Master Browser
Describe the function of a WINS server
Configure Samba to participate in network browsing
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
Describe how a NetBOS system is identified
Describe the function of a Local Master Browser and Domain Master
Browser
Describe the function of a WNS server
Configure Samba to participate in network browsing
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 2-2. NetBIOS System Identification LX265.0
Notes:
On any NetBIOS network, every system is identified with a netbios name, a unique name
of 15 characters maximum. This name may consist of the letters A-Z (netbios names are
case insensitive), digits 0-9 and the characters !@#$%^&()-'{}.~ (it is not recommended to
put a lot of these characters in...) Since netbios names have to be unique across a network,
it is useful to devise a system to allocate netbios names, especially for client workstations.
You could for instance base netbios names on the ID number of the employee, the serial
number of the machine, the MAC address or the IP address.
Samba also allows a system to have multiple NetBIOS names through the use of the
netbios aliases directive. This is against the NetBIOS standard but does not cause any
problems in practice. It can be useful in migration scenarios.
Another thing that identifies a NetBIOS system is the workgroup name. Workgroups are
logical collections of machines but have (at this level) no particular advantage or
disadvantage
1
. As with netbios names, workgroup names are 15 characters maximum.
1
This comes when we start looking at domains.
NetBIOS System Identification
Every system on a NetBOS network is identified with a netbios
name
Maximum 15 characters
Has to be unique
A Samba system can have multiple netbios aIiases
Useful in migration scenarios
Every system on a NetBOS network is part of a workgroup
Maximum 15 characters
Every system on a NetBOS network may have a server string
associated with it
smb.conf [global] entries:
netbios name = <name>
netbios aIiases = <Iist of names>
workgroup = <name>
server string = <comment>
Student Notebook
Finally, every NetBIOS system may have a server string associated with it. This is a piece
of text that shows up when information about a system is requested, and may for instance
list the owner of the system, the operating system and version or the services that are
offered.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 2-3. Local Master Browser LX265.0
Notes:
When a system is turned on, it announces itself to the world using a broadcast message. It
would be a waste of resources if every system attempted to keep track of every other
system in the network. That's why the network is logically divided into workgroups. In each
workgroup, one system is elected Local Master Browser (LMB). This system keeps track
of all systems in the workgroup and the shares they offer.
The election process works roughly as follows:
When a system is turned on, it sends a message requesting the name of the LMB for a
given workgroup. If an LMB exists, the system registers itself with the LMB.
If no LMB yet exists, the system initiates browser elections. In principle, all systems in
the workgroup will automatically take part in these elections, and the system that has
the highest OS Level wins. If multiple systems have the same OS Level, then the
system with the highest uptime wins.
The OS Level (sometimes also called the OS Summary) is a way for Microsoft to
distinguish various operating systems. With each new operating system that is brought
LocaI Master Browser
Every workgroup elects a LocaI Master Browser
System with highest OS IeveI
System with highest uptime
Certain systems may force LMB elections even if an LMB is
already there
The LMB collects information about the workgroup
Machines in workgroup
Shares for each machine
IocaI master = yes|no
preferred master = yes|no
os IeveI = <number>
host1A host2A host3A host4A
LMB
Student Notebook
out, the OS Level increases. As an example, Windows for Workgroups and Windows 95
both have an OS Level of 1. Windows NT Workstation uses 16 and Windows NT Server
uses 32.
Depending on the number of systems involved, browser elections can take up to a
minute to complete.
If the LMB crashes, then any system that notices this can start master browser elections
too.
Certain systems (such as primary domain controllers) must also be LMB to function.
They can therefore force browser elections even if another LMB is present.
The LMB keeps track of all systems in the workgroup, and of all shares that each system
offers. All systems in the workgroup send a request to the LMB if they want to know
something about the workgroup. In addition to this, each LMB broadcasts its existence to
all other systems on the network. This ensures that other LMBs know which LMBs there
are on the network.
Samba can function as a Local Master Browser. To let Samba participate in LMB elections,
set local master = yes, and to configure the OS level for Samba, use the os level
directive. Samba can also force LMB elections when preferred master = yes.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 2-4. NetBIOS over TCP/IP LX265.0
Notes:
The traditional NetBIOS protocol is not routable. Among other things, this means that
NetBIOS packets cannot traverse a router into another physical network.
To solve this problem, Microsoft has decided to use NetBIOS over TCP/IP for almost all of
its communications. NetBIOS thus may use the routing functionality of TCP/IP to let
packets traverse into other networks. NetBIOS over TCP/IP is the default as soon as the
TCP/IP protocol is installed.
Samba only supports NetBIOS over TCP/IP.
When running NetBIOS over TCP/IP, two issues arise:
Domain Master Browsers, who solve the problem of local systems doing broadcasts
where they announce their services.
Mapping NetBIOS names to IP addresses.
NetBIOS Over TCP/IP
A traditional NetBOS is not routable: Cannot traverse multiple
networks
NetBOS over TCP/P uses routing function of P to implement
workgroups that span multiple networks
Automatically used in Windows when TCP/P protocol is installed
Samba only supports NetBOS over TCP/P
When running NetBOS over TCP/P, two issues arise:
Finding systems on the other side of the router
Mapping NetBOS names to P addresses
Student Notebook
Figure 2-5. Domain Master Browser LX265.0
Notes:
If a workgroup spans multiple physical networks, then the LMBs on each segment will elect
a Domain Master Browser (DMB) between themselves. This DMB then keeps a list of all
LMBs and thus is able to resolve queries from clients.
In order for this to work, the LMBs need to know that other LMBs are active on the network.
There are basically two ways in which this can happen:
The LMBs register themselves with a WINS server and thus are able to determine that
other LMBs serve the same workgroup.
The workgroup is a domain: All systems in the domain make use of one Primary
Domain Controller (PDC) for authentication. Such a PDC is required also to be the
DMB. Since all systems know the IP address of the PDC, they also know which DMB to
use.
Domains and PDCs will be covered in a later unit.
To let Samba participate in DMB elections, set domain master = yes.
Domain Master Browser
f a workgroup spans multiple physical network segments, then the
LMBs on each segment will elect a Domain Master Browser
between themselves
Elections based on same criteria as LMB
Keeps a list of all LMBs
domain master = yes|no
host1A host2A host3A host4A
host1B host2B host3B host4B
router
LMB2
LMB1
DMB
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 2-6. Mapping IP Addresses to NetBIOS Names LX265.0
Notes:
The NetBIOS protocol traditionally does not handle IP addresses. In order to run NetBIOS
over TCP/IP, you need to add this capability though. There are basically two ways of doing
this:
Static mapping: When this is used, all systems in the workgroup need to configure an
LMHOSTS file which contains the IP addresses and netbios names of all other systems
on the network. This could be compared to TCP/IP hostname resolution via the
/etc/hosts file.
Dynamic mapping: When this is used, all systems are configured (either statically or via
DHCP) with the IP address of a WINS server
2
. This WINS server allows all systems to
register their NetBIOS name (and some other important things, such as workgroup,
LMB/DMB capability) with it, together with the IP address of the system. Note that a
WINS server is not tied to a workgroup or domain: One WINS server can serve
hundreds of workgroups/domains at once.
2
The official RFC documents talk about a NetBIOS Name Server (NBNS) instead of Windows Internet Naming Server (WINS). The
DHCP server option is called netbios-name-servers.
Mapping IP Addresses to NetBIOS Names
NetBOS traditionally does not handle P addresses
Running NetBOS over TCP/P, needs to be done somehow?
Static mapping: LMHOSTS file
Syntax similar to /etc/hosts
Needs to be replicated on all systems
Dynamic mapping: WNS server
Server which allows clients to register themselves
Usually handles all workgroups in a network
Windows allows Backup WNS servers - Not implemented in
Samba
Imhosts fiIe = <fiIename>
wins support = yes|no
wins server = <IP address>
Whether a Windows system uses WNS depends on static or DHCP
settings
Student Notebook
Windows allows for Backup WINS servers to be configured, in case the primary WINS
server crashes. Samba does not have that functionality (yet).
To run Samba as a WINS client, use the wins server = <IP address> option line.
To run Samba as a WINS server, use the wins support = yes option line. Never
use wins support = yes together with a wins server = <IP address> line!
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
1.
2.
3.
Checkpoint
1. T/F. The Local Master Browser keeps a list of all systems on the
network and their P addresses.
2. The Samba parameter that is most important in the outcome of
master browser elections is the _______________ parameter.
3. T/F. When this WNS server is down, nobody is able to browse the
local network.
Student Notebook
Notes:
Unit Summary
System identification
Network browsing
WNS servers
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 3. Authentication 3-1
V1.2.2 BKM2MIF
Uempty
Unit 3. Authentication
This unit covers authentication in a Windows environment, and how
Samba handles this.
Describe the way Windows performs authentication in general
Explain the difference between share level and user level security
Explain the way Samba handles authentication
Explain the difficulties involved in encrypted passwords, and how
Samba handles this
Use the pdbedit tool
Set up a guest account
Accountability:
Checkpoint Questions
Lab exercises
Student Notebook
Notes:
Unit Objectives
Describe the way Windows performs authentication in general
Explain the difference between share level and user level security
Explain the way Samba handles authentication
Explain the difficulties involved in encrypted passwords, and how
Samba handles this
Use the pdbedit tool
Set up a guest account
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 3-2. Authentication LX265.0
Notes:
Authentication is the process of establishing the fact that you are who you say that you are.
In Windows, this is always done using a username/password combination. This
combination is entered when the system starts (Windows 95/98/ME), or when you log on
(Windows NT/2000/XP).
In Windows 95/98/ME, the authentication phase is optional, since these systems do not
have their own username/password database. Instead, the information given here is stored
in a *.PWL cache file and used for authentication when a server is accessed via the
network.
In Windows NT/2000/XP, authentication is mandatory. The username and password
entered are used both for local and remote authentication.
Windows usernames and passwords are case insensitive and may contain spaces. In
contrast, UNIX usernames and passwords are case sensitive and may (generally) not
Authentication
Authentication: Establishing the fact that you are actually who you
say you are
n Windows this is done using a username/password combination
which you enter when the system starts (Win9x/ME) or when you
log on (WinNT/2000/XP)
This username/password combination is used every time you
setup a network connection
Windows usernames/passwords:
May contain spaces
Case insensitive
UNX usernames/passwords:
May generally not contain spaces
May generally not exceed 8 characters
Case sensitive
Samba needs mapping of Windows username/passwords to UNX
username/passwords
Student Notebook
contain spaces
1
. Furthermore, UNIX usernames and passwords are generally limited to
eight characters
2
.
This means that in most cases, a mapping between Windows usernames/passwords and
UNIX usernames/passwords is required. How this is done is the topic of this unit.
1
Technically, a username can contain spaces, but a lot of programs will not handle this properly. And you need to surround the
username with quotes every time it is part of a shell command, such as chown joe doe joesfile.
2
Most Linux distributions use MD5 instead of crypt() to encrypt passwords. This means that passwords can be longer than eight
characters.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 3-3. Win9x Password-Protected Shares LX265.0
Notes:
In Windows 9x (95/98/ME), a share can be created and protected with a password. This
means that everybody who knows the password can access the share.
Samba can emulate this when the global parameter security = share is configured. This
results in the client sending (only) the password when trying to access the share. The client
does not send the username.
This form of security maps particularly badly to UNIX's concept of security, since UNIX
security is completely built around user IDs. So in order to properly protect the share,
Samba needs to guess the username that belongs to the password. It does this by trying
out the password given on ALL UNIX user accounts. Obviously, with a large user database,
this is not really efficient. To limit the user accounts that are checked this way, specify the
users = <username list> with the shares that are protected this way.
With the increased capabilities of Samba, security = share is no longer considered good
practice. Do not configure this unless you have to (for instance when you need to support
really old clients).
Win9x Password-Protected Shares
n Windows 9x, a share can be protected with a password
To emulate this in Samba:
security = share
Result: client only sends the password to the server, not the
username
Samba needs to guess the username, based on the password
Not very efficient!
To limit the number of passwords searched, specify users = <Iist
of users> with the share
Do not do this with Samba unless you have to!
Windows
client
Samba
server with
security=
share
Logon request
(contains password only)
Student Notebook
Figure 3-4. WinNT Password-Protected User Accounts LX265.0
Notes:
Windows NT and its successors implement a more advanced model of security. In this,
every user has their own user account, which is protected by a password. Only certain
users have access to certain shares.
Since this follows the UNIX security model more closely, this is easier to implement in
Samba. To implement this, set security = user.
A client who encounters a server who is in user level security will send both the username
and the password to the server. This allows Samba to test the password given against the
UNIX user account and thus to authenticate the user.
Knowing which UNIX user account is involved is important for another reason: After Samba
has authenticated the user, it performs a fork() system call, which spawns off a child
process. This child process then performs the setuid() system call, setting its effective user
ID to the user ID of the authenticated user, and then handles the rest of the connection.
This way, the regular UNIX permissions also apply to all users who access the system via
Samba.
WinNT Password-Protected User Accounts
n Windows NT, a user account is protected with a password
Only specific user accounts have access to a particular share
To enable this in Samba:
security = user
Result: username and password are sent to server
Samba can authenticate user based on password
smbd daemon then forks and performs a setuid() system call to
switch over to the UD of that user
From that point, regular UNX permissions apply as well
Windows
client
Samba
server with
security=
user
Logon request
(contains username and password)
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 3-5. Samba Username/Password Mapping LX265.0
Notes:
As we've seen before, the rules that apply to Windows usernames and UNIX usernames
differ. This may lead to the situation that a Windows client tries to access a Samba server
with a username that would be illegal under UNIX. If this happens, you need to create an
smbusers file which contains the UNIX username and all Windows usernames (if
necessary, surrounded with quotes) that map to this UNIX username. This file needs to be
referenced in the smb.conf file with the username map global option. The file contents look
like this:
root = Administrator admin
nobody = guest pcguest smbguest
john = "John Doe"
If no map file exists, or if the Windows username is not mapped to a UNIX username in this
file, then Samba will try to use the Windows username as UNIX username directly.,
Windows passwords are verified as regular UNIX passwords
3
, for instance through PAM (if
your system supports PAM).
3
Except when encrypted passwords are used. This is covered in the next visual.
Samba Username/Password Mapping
Username mapping is performed in smbusers file
Contents: <unix username> = <windows usernames>
f no map or map file found, Samba assumes that the windows
username is the same as the UNX username
Passwords are verified as regular UNX passwords (unless
encrypted - discussed later)
Usernames and passwords in Windows are generally case
insensitive and often transferred as CAPTALS
Samba converts them to lowercase before testing
f no match, change one character to capital and try again, and so
forth... (CPU intensive!)
username map = <smbusers fiIe>
username IeveI = <max number of capitaIs>
password IeveI = <max number of capitaIs>
Student Notebook
A second problem that Samba needs to solve is that usernames and passwords in most
Windows versions are case insensitive and are (normally, but this depends on the client)
transferred in capital letters. Samba converts all these usernames and passwords to
lowercase before testing. If no match is found, Samba will convert the first character to
uppercase and test again. It will do that again with the second character, the third and so
on. And then will try every possible combination with two capitals, then three, and so forth.
How far Samba goes with this is determined with the username level and password level
options in smb.conf.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 3-6. Samba Groupname Mapping LX265.0
Notes:
With the introduction of Samba 3.0, it is also possible to map Windows groups to UNIX
groups. The implementation of this is completely different though. Instead of using a flat file
like smbusers, we now use a Trivial DataBase file, /var/cache/samba/group_mapping.tdb.
These TDB files (we will meet more of them, later in the course) cannot be modified easily
by hand. Instead, we use the net command to modify these.
In case of groupname mapping, the command to use is net groupmap, which allows you
to list all groupmappings, and to add, remove and modify group mappings.
When mapping Windows groups to UNIX groups, it is advisable to at least create a
mapping for a few default Windows Domain groups (we will discuss Windows Domains
later on in this course):
Domain Users
Domain Guests
Domain Admins
The suggested, corresponding UNIX groups are, respectively, users, nobody and root.
Samba Groupname Mapping
Stored in /var/cache/samba/group_mapping.tdb
Modify with net groupmap series commands:
net groupmap Iist
net groupmap add ntgroup="<NT group>" unixgroup="<UNIX
group>"
net groupmap deI ntgroup="<NT group>"
net groupmap modify
Advisable to create a group mapping for, at least, the following
default Windows Domain groups:
Domain Users (suggestion: users)
Domain Guests (suggestion: nobody)
Domain Admins (suggestion: root)
Student Notebook
Figure 3-7. Encrypted Passwords (1 of 2) LX265.0
Notes:
Traditionally, passwords were sent over the network in clear text. This makes it easy for a
hacker to compromise security, since a simple sniffer is sufficient to obtain literally
hundreds of passwords. Starting with Windows 95 OSR (OEM Service Release) 2 and
Windows NT 4.0 SP (Service Pack) 3, passwords are encrypted by default, and
unencrypted passwords are no longer allowed.
To disable encrypted passwords in these and later operating systems, you need to edit a
registry entry. Which entry to edit varies from version to version. The best approach is to
look in the Samba distribution files for the *.REG file which name matches your operating
system. Transfer this file to the Windows system and double-click on it. This will
automatically start REGEDIT.EXE, the registry editor, which will make the required change
for you. Then reboot the system and it will use unencrypted passwords again.
Warning: Using unencrypted passwords is considered a severe security risk!
When encrypted passwords are used, Samba can no longer use regular UNIX
authentication, since the way Windows encrypts passwords is not compatible with UNIX,
Encrypted Passwords (1 of 2)
Starting with Windows 95 OSR 2 and Windows NT 4.0 SP 3,
passwords are encrypted by default
To disable: edit registry entry
Samba can no longer use regular UNX passwords; needs to do its
own administration
smbpasswd file stores username, userid, 2 passwords (LANMAN
and NT), account flags and Last Change Time
smb passwd fiIe = <smbpasswd fiIe>
encrypt passwords = yes|no
# cat /etc/samba/smbpasswd
.
testuser:500:1DC88ACE96117D0FAAD3B435B51404EE:6CAB9C70CAF6F0F2E0BC9ACFCEF8F2CF:[UX ]:LCT-40FAD489:
.
Student Notebook
V1.2.2 BKM2MIF
Uempty
and both methods are one-way encryptions. Samba thus needs to do its own password
administration. This is done by means of an smbpasswd file.
Student Notebook
Figure 3-8. Encrypted Passwords (2 of 2) LX265.0
Notes:
As said before, the smbpasswd file needs to contain the encrypted passwords of all
Windows users in your network. There are basically two ways of getting all these
passwords in:
The first method involves adding all users by hand. This is done with the smbpasswd
-a command, which adds the user account to the smbpasswd file. It also asks for the
new password of this user.
The other method is automatic migration. This is only possible if all your current users
are already using unencrypted passwords. When this is the case, you can set the
smb.conf option update encrypted = yes.
When this is configured, all incoming (non-encrypted) passwords are tested against the
regular UNIX passwd files, but also encrypted and added to the smbpasswd file. After
you have left this running for a number of weeks, you've collected all encrypted
passwords in the smbpasswd file and can upgrade your Samba server to use encrypted
passwords exclusively.
Encrypted Passwords (2 of 2)
Creating smbpasswd by hand:
Use smbpasswd -a command to add existing UNX users to
smbpasswd file and set password
Creating smbpasswd automatically:
Use update encrypted = yes to let Samba create the
smbpasswd file automatically when users log in with their
(unencrypted) password
Useful when introducing encrypted passwords
Changing passwords:
Samba can change user passwords upon client request
Use smbpasswd to change passwords from UNX
Keeping UNX and Samba passwords synchronized:
unix password sync = yes|no
passwd program = /bin/passwd %u
passwd chat = <chat with passwd>
Or, on PAM enabled systems: pam password change = yes|no
Student Notebook
V1.2.2 BKM2MIF
Uempty
Samba also allows you to change your passwords. When this is done from a Windows
client, Samba makes the change itself. But a UNIX user can also change a Samba
password by means of the smbpasswd program.
Using encrypted passwords means that users will have two passwords on the same server.
This may lead to confusion. You therefore might want to configure password
synchronization. This is automatically done by Samba and smbpasswd if the unix
password sync option is turned on in smb.conf. When turned on, Samba or smbpasswd
will call the password program and will perform the passwd chat conversation with it to
change the UNIX password.
On a PAM enabled system, you can use pam password change = yes instead of
password program and password chat. Samba will then use PAM to change the UNIX
password of the user.
Student Notebook
Figure 3-9. pdbedit LX265.0
Notes:
The pdbedit tool allows you to manage the two other fields in the smbpasswd file: the
account flags and the Last Change Date. Obviously, particularly the account flags are of
interest.
A Windows user account can have 11 different flags. For a full list see man pdbedit. Only
five flags make sense to change however, and can thus be changed by pdbedit:
N Account requires no password
D Account is disabled
H Account requires a home directory
L Account is locked automatically after a number of bad login
attempts
X Account password does not expire
To set any of these flags, use pdbedit -c with the flag in capitals, surrounded by square
brackets and quotes. To reset any of these flags, use the lowercase letter.
pdbedit
pdbedit: Tool to manage the other fields in smbpasswd file.
Becomes more powerful if you use a different password store
(later in this course)
pdbedit -L: List all user accounts known to Samba
pdbedit -Lv <user>: List details of user
pdbedit -c "[D]" <user>: Disable user account
pdbedit -c "[d]" <user>: Enable user account
Various other options: see man pdbedit
Most options do not work with the "flat file" approach we're using
right now (/etc/samba/smbpasswd)
Student Notebook
V1.2.2 BKM2MIF
Uempty
The pdbedit tool also allows you to set various other user account properties, such as the
users home directory share, the profile share and so forth. Take a look at the manual page
of pdbedit for details. Note however, that our current smbpasswd file does not have the
capability of storing this data. Because of this, with our current flat file SAM backend,
these settings will not be stored anywhere. In a later unit we are going to discuss the
LDAPSAM backend, which is one of the backends which is capable of storing these user
account properties.
Student Notebook
Figure 3-10. Guest Account LX265.0
Notes:
When a user logs in to the Samba server with an unknown or with no username, then the
results depend on the setting of the map to guest parameter:
When set to never, nothing happens. The user is not authenticated and is not granted
access to the system.
When set to bad user, the user is mapped to the guest account. This means that the
user can access all shares that were identified as being available for the guest user.
When set to bad password, the user is mapped to the guest account as well.
Moreover, all users that try to access the server with a valid username but with the
wrong password are also mapped to the guest account.
This option leads to the situation that a user who logs in to the server but by accident
types a wrong password gets error messages like Share does not exist instead of
Wrong Password. This can be really confusing, both for the user and the help desk.
Use of this method is therefore not recommended.
The guest account option identifies the UNIX user account that is used to implement the
guest account.
When a user logs on to the samba server with an unknown
username, results depend on "map to guest" parameter
map to guest = never: Not authenticated
map to guest = bad user: Mapped to "guest account" account
map to guest = bad password: Mapped to "guest account"
account, even if the username exists but the password is wrong
The guest account parameter determines which UNX account is
used as guest account
guest account = <UNIX guest account name>
Guest Account
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
1.
2.
3.
4.
Checkpoint
1. T/F. On the more recent versions of Windows, encrypted
passwords are enabled by default.
2. n what file does Samba store the encrypted passwords?
3. When you have an existing UNX user and you want that user to be
added to the smbpasswd file, the command to run is
_______________________ .
4. f you want to lock a Samba account, the command to execute is
_______________________ .
Student Notebook
Notes:
The locations that Samba uses for its files and directories are configurable. Some of them
can only be changed at the time the software is compiled (which is one reason why an
administrator may want to compile the code themselves). Others, like log files and spool
directories, can be overridden in the configuration file.
Most of the parameter values in the global section become defaults for the dynamically
created shares based on homes and printers, although there are exceptions. This will be
discussed more in the following units.
We also looked at some sample configurations, including a couple of pages on how a
Windows client would be configured if it were to cooperate with Samba on a network.
Unit Summary
Authentication
Share level authentication
User level authentication
Windows/UNX username/password/group mapping
Encrypted passwords
pdbedit
Guest account
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 4. File Sharing 4-1
V1.2.2 BKM2MIF
Uempty
Unit 4. File Sharing
This unit will introduce the student to the configuration details for using
Samba as a file server. There are basically two different, but similar,
configurations: home directories, and all other directories.
Create shares for UNIX users' home directories
Create shares for other directories
Discuss and configure sharing options
Discuss and configure NT ACLs on shares
Discuss and configure MS-DFS
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
Create shares for UNX users' home directories
Create shares for other directories
Discuss and configure sharing options
Discuss and configure NT ACLs on shares
Discuss and configure MS-DFS
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 4-2. The Purpose of File Sharing LX265.0
Notes:
File sharing means providing non-local access from network clients to a central storage
repository.
Typically, file sharing is used to provide access to resources located in a single spot without
having to copy the information all around the network. For example, there may be a
common set of memo templates, letterhead templates, reports, and so on, that the
company may desire to make available to all of its office staff. A good approach would be to
place all of those files on a single machine somewhere on the network and provide public
access to those files. Then the office staff can access them as needed, and when an
update needs to be done, it can be done in just a single location -- on the server.
Those resources are typically public, as in the above scenario, but private resources can
be shared also. These would be resources that require clients to authenticate themselves
to the server and prove who they are. Then certain individuals can be configured with
access.
In addition to making it easier for the user (in terms of accessing the data), it's also easier
for the administrator of the information when the data needs updating or backing up. And
Access to private resources
Access to shared resources
Ease of administration
Permissions
Backups
Configuration
The Purpose of FiIe Sharing
Student Notebook
because all of the data is in one place, access can be controlled centrally as well
(controlling the floppy that's being passed around is much more difficult). And lastly, the
actual implementation of the data storage can change without affecting the clients. For
example, the data could be moved to CD-ROM and yet the clients could continue to access
it from the server in exactly the same way. The data could even be moved to another host
on the network, and as long as the file server can still access it, the data could continue to
be shared.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 4-3. Common Candidates for Sharing LX265.0
Notes:
Generally, users will want to be able to access their own data from anywhere on the
network. On UNIX machines, individualized data is usually stored in the home directory of
each user. This is a default configuration for Samba.
Of course, other locations might also be desirable shares, such as /tmp for temporary
storage space.
Because of how networks can connect many different types of machines, often there will be
a desire for machine A to obtain files from machine B when they don't have any file sharing
protocols in common. Sometimes Samba can help in this situation. For example, machine
A is a Windows98 client. Machine B is an NFS file server. If Samba were installed on a
Linux machine on the same network, it could mount the NFS file systems and then provide
a share for that mount point. No software needs to be purchased for the Windows client,
which can be a major savings if hundreds of clients are involved. And Samba provides an
interface that the Windows user is already familiar with.
Another example might be a CD-ROM jukebox, or NFS mounted file systems (Network File
System) from other UNIX hosts.
User's home directories
For all users
Only for the owner
Temporary public storage
Other public storage
Team directories
Access to resources not available via SMB
NFS file systems
CD-ROM file systems
Common Candidates for Sharing
Student Notebook
Figure 4-4. Sharing Home Directories LX265.0
Notes:
The first example shown here is the [homes] share. This is a special share which is used as
a template for the home directory of the user that logs in. All options in this share are used
for the home directory of the user, except for one: browsable, which will automatically be
set to yes. And obviously the name of the share will not be homes, but will be replaced by
the username.
Strangely enough, the homes share itself is also considered a true share. This means that
when a user logs in, he or she will always be able to access two shares at least: the
homes share, and a share which is named after its own username. But since the homes
share is not browsable. the user will not generally see this. Both shares lead to the home
directory of that user.
This makes an interesting trick possible: When the user executes the command
net use H: \\server\homes, then the users home directory will always be accessible as H:,
no matter what the username is
1
.
1
We will incorporate this later on in a domain logon script.
Sharing Home Directories
[homes] is a template which is used for every user account in
/etc/passwd
[homes]
path = /home/%u
comment = Home Directory of %U
browsabIe = no
writabIe = yes
vaIid users = %S
Defaults for sharing the home directory of the user are taken from
the [homes] template, except:
Name of the share = username instead of "homes"
Browsable = yes
Useful MS-DOS command:
net use H: \\server\homes
Will always map your own home directory as H:
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 4-5. Sharing Other Directories LX265.0
Notes:
If you want to share other directories than just home directories alone, then you need to list
all these shares individually.
The share definition in smb.conf starts with the share name in brackets. This is followed by
the options that apply to the share. For each share, the following options are almost always
specified:
comment, which contains a description of the share.
writable, which determines if a user can write to the share, or if this is a read-only
share. (The option read only is the inverse of this option.)
browsable, which specifies whether the share shows up in a browse list, such as your
Network Neighborhood.
public, which is a synonym for guest ok, and determines if the guest user (a user
mapped to the guest account) has access to the share.
path, which specifies the UNIX directory for the share.
Specify the share name inside the brackets
Example:
[tmp]
comment = Free disk space here
writabIe = yes
browsabIe = yes
pubIic = yes
path = /tmp
Sharing Other Directories
Student Notebook
Figure 4-6. Filename Mangling LX265.0
Notes:
As with usernames and passwords, UNIX filenames do not conform to the same
restrictions as Windows filenames. In order to correctly map these filenames to each other,
you might need to configure filename mangling.
The default settings of Samba conform to Windows NT filename mangling when it deals
with Windows WfW/95/98/ME, in that it is case insensitive but case preserving.
mangle case Controls if names that have characters that aren't of the default
case are mangled. For example, if this is yes then a name like Mail
would be mangled.
case sensitive Controls whether filenames are case sensitive. If they aren't then
Samba must do a filename search and match on passed names.
default case Controls what the default case is for new filenames.
preserve case Controls if new files are created with the case that the client passes,
or if they are forced to be the default case.
FiIename MangIing
UNX filenames are case sensitive
Windows filenames are case insensitive and may need to conform
to 8.3 format
Various options exist for filename mangling:
mangIe case = yes|no
case sensitive = yes|no
defauIt case = upper|Iower
preserve case = yes|no
short preserve case = yes|no
UNX filenames that start with a dot are hidden files
hide dot fiIes = yes|no
Student Notebook
V1.2.2 BKM2MIF
Uempty
short preserve case Controls if new files which conform to the 8.3 syntax (upper case
and suitable length) are created upper case or if they are forced to
be the default case. This option can be used with preserve case =
yes to permit long filenames to retain their case, while short names
are lowercase.
Another difference between UNIX and Windows filenames is that in UNIX a file is made
hidden by starting the filename with a dot. To control whether these files need to be visible
from Windows, use the hide dot files option.
Student Notebook
Figure 4-7. Windows NT Access Control Lists LX265.0
Notes:
Windows NT supports Access Control Lists (ACLs) by default on the NTFS filesystem. This
means that each and every directory and file can have its own list of users that have
various kinds of access to it.
A directory (folder) allows the following permissions to be configured on a per-group and
per-user basis:
Full Control
Change
Read-Only
Add
Add and Read
List
No Access
Windows NT Access ControI Lists
Windows NT supports ACLs on files and directories
f Samba runs on an OS+Filesystem which supports ACLs, then
NT-compatible ACLs are supported
n Linux, need to (re)mount the filesystem with the "acl" option
Enable in Samba with nt acI support = yes
f the OS or Filesystem does not support ACLs, only the default
UNX permissions are used
May need to set additional options:
force user = <username>
force group = <groupname>
create mask = <mask>
force create mask = <mask>
directory mask = <mask>
force directory mask = <mask>
inherit permissions = yes|no
Student Notebook
V1.2.2 BKM2MIF
Uempty
A file allows the following permissions:
Full Control
Change
Read-Only
No Access
If Samba runs on an operating system and filesystem that supports ACLs, then Samba will
make use of these ACLs to implement Windows NT ACLs as long as nt acl support = yes.
Most Linux systems today will support ACLs, but this support is disabled by default. To
enable ACL support, you need to (re)mount the filesystem on which you want to use ACLs
with the acl option. The command to do this is mount -o remount,acl <filesystem>.
Dont forget to add the acl option to /etc/fstab too!
If Samba runs on an operating system or filesystem that does not support ACLs, then
Samba uses the regular UNIX file and directory permissions (rwxrwxrwx). If this is not
enough for your requirements, then you can use some options on the share to enhance
your security a little further:
force user
force group
create mask
force create mask
directory mask
force directory mask
inherit permissions
Student Notebook
Figure 4-8. Other Sharing Options LX265.0
Notes:
There are other options that you might want to specify when configuring shares.
The first set of options that you might want to specify is who has read and write access to
the share. There are basically two options that apply here:
writable is the opposite of read only. They specify in general if the share is read-only or
read-write.
write list is a list of usernames who are permitted to write to a share which is read-only
in general. The opposite of a write list is a read list, which specifies the list of users who
can only read from a share which is writable in general.
The next parameter that you might want to use is the valid users parameter, which
specifies a list of users that are given access to the share. Users that are not in this list will
not even see the share in their browse list.
The next two parameters specify whether guest access is allowed or forced. guest ok
gives access to the share for the guest user, and guest only forces every user (even a
legitimate one) to be mapped to the guest account when accessing the share. This can be
Other Sharing Options
Read Only, Read-Write, Read-Mostly
writabIe = yes|no or read onIy = yes|no
write Iist = <username Iist> or read Iist = <username Iist>
Specify valid users
vaIid users = <username Iist>
Allow/Force guest access
guest ok = yes|no or pubIic = yes|no
guest onIy = yes|no
Execute commands before/after share is accessed
root preexec = <command>
preexec = <command>
postexec = <command>
Locking
Iocking = yes|no
Stackable VFS Modules
vfs objects = <Iist>
Student Notebook
V1.2.2 BKM2MIF
Uempty
useful if all users need to access a certain directory as a particular user. (If needed, you
can specify a guest account parameter within the share definition so that not the regular
guest account, but a guest account specific for this share is used.)
There are also smb.conf options that force Samba to execute a command before and after
a user accesses a share. The two most important ones are preexec and postexec, but
there are a few more related to this:
preexec specifies a script or command to execute before the share is opened. The
command or script is run as the user that connects to the share.
preexec close = yes|no determines if the share should be closed or not if the preexec
command failed.
root preexec and root preexec close are identical to preexec and preexec close, but
all commands are run as root instead of the user that connected to the share.
postexec specifies a script or command to execute after the share has been closed.
The command or script is run as the user that connected to the share.
root postexec is identical to postexec, but the command is run as root instead of the
user that connected to the share.
Locking is fully implemented in Samba and makes use of the operating systems features,
where possible. For read-only shares, locking is generally not required and turning it off
with locking = no has proven to be able to deliver a performance increase. The
disadvantage is that if somebody accesses the share directory not via Samba, but via
another method, then he or she might be able to write to files that would otherwise be
locked.
The last directive is vfs objects. This directive enables the Stackable VFS Modules, which
are separate modules that are invoked before Samba invokes a read/write/close/open
operation. With the use of these modules, you can extend Samba functionality yourself.
VFS modules are somewhat experimental, but some of the more useful modules currently
available are:
audit Audits file access to the syslog facility.
recycle Implements a Recycle Bin (in the form of a .recycle directory) to
which files are copied when an unlink operation takes place.
(unlink normally deletes the file.)
vscan Scans a file which is written or read for viruses.
VFS Modules will not be covered further in this course. For more information, see the
Samba documentation.
Student Notebook
Figure 4-9. MS-Distributed File System LX265.0
Notes:
The Microsoft Distributed Filesystem (MS-DFS) is a share that looks as one filesystem to
the user, but in reality consists of multiple shares, which look like regular directories to the
user. These shares may be on multiple servers. This concept is similar to the UNIX concept
of mounting local and network file systems on top of each other.
Samba supports MS-DFS as well. To implement it, three steps are required.
1. Add the host msdfs = yes directive to the smb.conf [global] section.
2. Add the msdfs root = yes directive to the share where you want to host MS-DFS.
3. Create a UNIX symbolic link on the DFS share which points to the share that you want
to mount here.
Note: It is the Windows client which access the share, not the Samba server!
Creating the symbolic link will seem strange at first since the link will not be interpretable
within the context of a UNIX filesystem: The link should point to msdfs:server\share which
is not a regular filename in a UNIX filesystem. Because of this, when doing a ls with color
enabled (default in most distributions) the link will be blinking red and white.
MS-Distributed FiIe System
DFS: Share that looks as one filesystem share to the user, but
consists of multiple shares (which look like directories)
Similar to the UNX concept of "mounting"
To implement in Samba:
Add to [global] section: host msdfs = yes
Add to a share: msdfs root = yes
Create UNX symbolic link on the share: In -s
msdfs:server\\sharename name
On the share, the directory name will now link to the share
server\sharename
Advantages of DFS:
Transparency to user
Flexibility to administrator
Disadvantages:
DFS share becomes a single point of failure
Student Notebook
V1.2.2 BKM2MIF
Uempty
Note that the backslash is a reserved character. The correct command to create the
symbolic link therefore is:
ln -s msdfs:server\\share name
This command creates a directory name which, when accessed from Windows, maps to
the share server\share. (Note the single backslash.)
The advantage of using DFS is that you only need to tell your userbase the name of one
share: the share that hosts the DFS. Users can then browse all directories and get access
to all other shares transparently (provided that they have access: normal access rules still
apply). If you need to move a share from one system to another, the only thing you need to
do is modify the symbolic link. The change then becomes completely transparent to the
users.
On the other hand, if users only know the name of the DFS share, then this share
becomes, as far as the users are concerned, a single point of failure: If the share is not
available, they dont know how they can otherwise access their data.
Student Notebook
Notes:
1.
2.
3.
Checkpoint
1. T/F. File sharing can be controlled on a per-user basis.
2. T/F. NFS filesystems and CD-ROM filesystems can be shared
using Samba.
3. T/F. t is possible to allow user joe to access a share, but still
prevent him from accessing individual files within the share.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
Unit Summary
Purpose of file sharing
Sharing home directories
Sharing other directories
Filename mangling
Window NT ACLs
Other share options
MS-DFS
Student Notebook
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 5. Printer Sharing 5-1
V1.2.2 BKM2MIF
Uempty
Unit 5. Printer Sharing
This unit describes the setup and configuration of printer sharing using
Samba.
Configure Samba to share all the host system printers
Configure individual printer shares
Configure auto-installation of Windows drivers
Setup pseudo-printers
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
Configure Samba to share all the host system printers
Configure individual printer shares
Configure auto-installation of Windows drivers
Setup pseudo-printers
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 5-2. Why Printer Sharing? LX265.0
Notes:
Printer sharing is a fairly common technique in most organizations. It allows a large group
of individual users to combine access to printers which would otherwise sit idle for long
periods. For example, the accounting department might need a printer for accounts
receivable. Sales may want a printer for sales projections. Neither group, on their own, will
be using the printer for a significant duration, so it makes more economic sense for them to
share a single printer than for each department to have its own.
This also allows a wider variety of printer types to exist within an organization, because
individual departments may not have the budget for black and white laser printers, color
dye-sublimation printers, color ink jets, and so on. Yet, in a shared environment, each
department can access any or all of those printer resources.
It also helps the IT staff. They can centralize configuration of these printers to a single host
and all print requests can then go to that host. Software updates can be applied to the host
without updating individual machines (except that in a Windows environment, this isn't
practical since each client has its own set of driver files). The IT group can also configure
printer accounting at a single point, both for pages printed and spool space used (at some
Reduced hardware costs
Ability to choose printer type
Centralized configuration and updates
Printer accounting
Central allocation of disk (spool) space
Possibility of dedicated maintenance staff
Why Printer Sharing?
Student Notebook
sites this can be significant if jobs are printed shortest-job-next and a large job sits in spool
space for a long time).
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 5-3. Top-Level Configuration LX265.0
Notes:
Samba does not have a printer spool mechanism built-in. Instead, it accepts print jobs from
Windows clients and submits them using the regular UNIX printer spool mechanism,
through the regular commands. Because of this, Samba needs to know what printer spool
mechanism your host operating system uses with the printing option. Examples of these
include BSD, AIX, LPRng, PLP, SYSV, HPUX, QNX, SOFTQ and CUPS. The setting of this
parameter influences, among other things, the setting of the printcap file and the print
command options.
Not shown in the figure but useful too are the lpq command, the lppause command, the
lpresume command and the lprm command.
When the load printers option is set to yes, then Samba will automatically make all
configured printers available for clients. As with the [homes] template share, there is a
template share called [printers] which specifies the options with which the printers will be
shared.
Global options:
printing = bsd|Iprng|cups
printcap name = <printcap fiIe>
Ioad printers = yes|no
print command = Ipr -r -P%p %s
f Ioad printers = yes then all configured printers will automatically
be shared
The [printers] share sets default options for all printers
[printers]
path = /var/spooI/samba
printabIe = true
guest ok = true
Samba stores all print files in path, then submits them to the regular
print spool with the print command
f printing = cups then Samba will use CUPS AP instead of print
command
Top-LeveI Configuration
Student Notebook
In the [printers] template share, some options that are typically defined are:
path: This is the directory where Samba will store the jobs that were submitted to it,
before submitting them to the right printer with the print command command.
read only = true or writable = no: This is required since otherwise users would be able
to place files here directly, instead of using the proper spooling commands.
printable = true: This means that the share is a printer share, not a file share.
guest ok = true: This allows all users to access the printers. For tighter security, you
might consider setting guest ok = false. On the other hand, if you also specify guest
only = yes, then users can delete (runaway) jobs from other users, which might be
appropriate for departmental printers.
If printing = CUPS, then the Samba behavior is a little bit different. CUPS has a
well-defined API which allows client programs to communicate with the CUPS daemon
directly, without going through the print programs (lpr, lpq and so forth). Samba will use this
API and will therefore not use the printcap file, print command and other directives. If
you want Samba to use these directives, then you need to set something other than
printing = CUPS. You can do this globally or on a share-by-share basis.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 5-4. Example of Printer Sharing LX265.0
Notes:
Shown above are two different printer shares. However, they each refer to the same
printer.
The first share, called pcl by clients, refers to the hplj4 printer configured on the host
operating system (in the /etc/printcap file). The writable attribute is properly set, as is the
path to the spool directory. Notice that the printer field was required to tell Samba which
OS printer to use, since it can't be determined from the share name (which is not the same
as the OS printer name). This share will automatically be available when browsing this
server, because it's configured by hand into the smb.conf file.
The second share, called ps by clients, also refers to the hplj4 printer, but this time in
postscript mode. The postscript mode is determined by the command we are using to
queue up a file to be printed. Notice the use of the %p as a place holder for the host's
printer name, and the use of -r to cause the spool file to be removed when printing is
complete. Without the %p, Samba would not have had any way of knowing the printer to
use, so the lpr command would execute using the default printer as defined by the host
OS. The %s is the full path name to the spool file (if you want only the filename, use %f
Simple example of two custom printer shares:
[pcI]
path = /var/spooI/samba/pcI
printabIe = yes
read onIy = true
printer = hpIj4
[postscript]
path = /var/spooI/samba/postscript
printabIe = yes
read onIy = true
printer = hpIj4
print command = /usr/bin/Ipr -r -P %p -t ps %s
Remember to set Ioad printers = no if you specify individual
printers
ExampIes of Printer Sharing
Student Notebook
instead). We wouldn't have to specify the command line normally, but with postscript
printers the -t ps option must be given to lpr or the job won't print correctly.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 5-5. Printer Drivers and Settings LX265.0
Notes:
A print job normally needs to be formatted properly for the printer in use: you cannot send
an MS-Word document, for instance, to a printer and expect it to be formatted correctly.
Instead, you need a printer driver which converts the print job into some sort of markup
language that the printer can understand.
The default Windows behavior is that the client system (the one on which the job was
submitted) formats the print job for the printer in use. This means that you need the correct
printer driver and the correct settings on each and every client workstation. To facilitate this,
the correct drivers and settings are normally stored on the print server, and can be
downloaded easily to the client workstation.
When the print job arrives through Samba in the printer subsystem (for example, CUPS),
the job is already formatted for the printer. This means that the printer subsystem should
not make any modification to the job anymore. This is called raw printing.
CUPS, by default, does not allow raw print jobs (defined as print jobs with a mime-type of
application/octet-stream) to be printed. This is done to prevent users from subverting the
Printer Drivers and Settings
Print job normally needs to be formatted properly for the printer in
use
Windows default behavior is that the client formats the job
Needs correct drivers and settings on each workstation
Drivers and settings are normally taken from the print server
The printer administrator stores the drivers and settings on the
print server
The printing subsystem on the print server (for example, CUPS)
does not modify the print job at all (enable "raw" printing)
Alternative approach (not further covered in this course)
Supply each client with a generic, "clean" PostScript driver
Let CUPS format the job for the printer
See Samba documentation for more information
Student Notebook
printer accounting subsystem. If you want to enable CUPS raw printing, you need to
modify two files:
1. Edit /etc/cups/mime.types and uncomment the following line at the end of the file:
application/octet-stream
2. Edit /etc/cups/mime.convs and uncomment the following line at the end of the file:
application/octet-stream application/vnd.cups-raw 0
In large organizations with multiple printers, another approach might be beneficial too. In
this approach, clients use a generic, clean postscript driver for all printers. This postscript
is then interpreted by CUPS and formatted properly for each printer. This means that all
your Windows clients only need one set of drivers and settings, which works for all printers.
The difficult, per-printer configuration is now done on the server, under direct control of the
printer administrator, instead of on hundreds of Windows client systems.
The postscript printer driver to use is written specifically for CUPS by the CUPS team. It is
derived from the Microsoft Postscript Driver that is part of the Microsoft Driver Development
Kit (MS-DDK). The advantage of using this driver instead of other postscript drivers is that
this driver supports all of the options that a Postscript printer might support, while not
imposing any physical limitations on the printer which is finally used.
This second approach will not be covered further in this course. See the Samba
documentation for more information.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 5-6. Auto Driver Installation Under Windows (1 of 2) LX265.0
Notes:
As of Samba 2.2, there is support for the native Windows NT printing mechanisms. This
includes support for downloading printer driver files on demand to Windows
95/98/ME/NT/2000/XP clients, also called Point-n-Print. You can also upload printer
drivers to Samba via the Windows NT Add Printer Wizard (APW). Windows NT printer
access control lists (ACLS) and advanced printer queue manipulation is also supported.
To support the auto uploading and downloading of printer driver files, you must first
configure a file share called [print$]. This name is hard coded in Sambas internals, as well
as in Windows. The path variable should be set to something appropriate to your
installation. Other parameters that should be set are browsable, write list, and file and
directory mode values.
Next, we need to create the subdirectory structure in the [print$] path. These subdirectories
correspond to the supported client architectures. For Windows 95/98/ME, create a
directory called WIN40. For WIndows NT/2000/XP, a directory called W32X86. For
Windows NT PowerPC, a directory called W32PPC, and so on.
Create a directory for the driver files, owned by group lp
mkdir -p /etc/samba/drivers/{WIN40,W32X86}
chgrp -R Ip /etc/samba/drivers
chmod -R 2775 /etc/samba/drivers
Global settings:
show add printer wizard = yes
printer admin = @Ip
use cIient driver = no
Make a share called print$
path = /etc/samba/drivers
browsabIe = yes
guest ok = yes
read onIy = yes
write Iist = @Ip, root
create mode = 0664
directory mode = 0775
Auto Printer Driver InstaIIation (1 of 2)
Student Notebook
Figure 5-7. Auto Driver Installation under Windows (2 of 2) LX265.0
Notes:
Once the [print$] share is created, the driver files need to be uploaded to the share. There
are currently two methods to do this:
Install the print driver locally on the Windows client, then use the Samba command line
utility rpcclient with various subcommands like adddriver, getdriver, setdriver, and so
forth, to determine which files belong to the driver, and upload them to the Samba
server. This needs to be done for any Windows 9X/ME clients, but is NOT
recommended due to the complexity involved.
Use the Windows NT/2000/XP Add Printer Wizard utility to upload and install the
drivers. This is the recommended procedure.
Once you have uploaded the drivers, you also need to configure the settings on the print
server correctly for this printer. After all, the clients will not only download the drivers from
the print server, but will also download the driver settings. Having both correct from the
start saves a lot of problems later.
Auto Printer Driver InstaIIation (2 of 2)
Upload drivers to Samba server
From a Windows NT/2000/XP client, this can be done via the Add
Printer Wizard utility (recommended)
Use the rpccIient utility program and it's subcommands to upload
and configure the driver files
Drivers for various platforms are placed in separate directories
WIN40 Windows 95/98/ME
W32X86 Windows NT/2000/XP
W32PPC Windows NT for PowerPC
And so forth
Windows NT drivers: W32X86/2/ (kernel mode)
Windows 2000/XP drivers: W32X86/3/ (user mode)
Student Notebook
V1.2.2 BKM2MIF
Uempty
There are a number of methods to upload the drivers to your Samba system and configure
them properly, and two of these methods lead to the situation where you modified the
settings on the client, instead of on the print server. The only correct way of uploading the
drivers and configuring the printer settings on the Samba server is:
1. On your Windows Administrator system, open your Windows Explorer and browse your
Network Neighborhood until you get to your Samba-based Print server.
2. Go into the Printers folder, right-click on the printer you want to configure and select
Properties.
3. You will now get a warning Device settings cannot be displayed. [...] Do you want to
install the driver now? Click No here! If you click Yes, then you are going to install the
printer drivers locally instead of on the print server.
4. You will now see the printer properties window with five standard tabs. Go to the
Advanced tab and click on New Driver. This starts the Add Printer Driver Wizard. Use
this wizard to select the correct printer driver. It will be uploaded to the [print$] share on
your print server.
Note: If your printer properties window only contains greyed-out items, then most likely
your Administrator account is not mapped to the root account properly, or you are not
listed in the printer admin list.
5. Close the printer properties window, and open it again by right-clicking on the printer
icon and selecting properties. Depending on the printer driver, you will now see
additional tabs.
6. Select the Advanced tab and click on Printing Defaults. This opens an additional
window, which allows you to configure the printer driver settings on the print server. All
other tabs and windows you might find in the printer properties window will only modify
the printer driver settings on the local system.
7. Close all windows.
Once the drivers are installed, they will be placed in the corresponding architecture
directories. Under the W32X86 directory, an additional subdirectory is created for Windows
NT drivers and Windows 2000/XP drivers. This is because Windows NT drivers run in
kernel mode, while the Windows 2000/XP drivers run in user mode.
The printer driver settings are stored in /var/cache/samba/ntprinting.tdb and in
printer-specific files in /var/cache/samba/printing.
Student Notebook
Figure 5-8. Pseudo-Printers LX265.0
Notes:
A nice trick you can use on Samba is creating so-called pseudo-printers. These devices will
look like a printer to the user, but in reality will do something else entirely. This is done by
specifying a different print command for that printer.
Note that if you use printing = CUPS as your printing backend, then the print command
will never be used. So you need to specify, for instance, printing = lprng within the
pseudo-printer share definition, or things will not work as expected.
Pseudo-Printers
By defining a printer share with a custom print command, you can
do other things than just printing with the print job
Examples:
Mail to someone
Create a PDF
Fax it to someone
Note that, if printing = cups globally, then you need to specify
printing = Iprng in the pseudo-printer share, or else the print
command will not be used
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
1.
2.
3.
4.
Checkpoint
1. Which of the following is NOT a good reason for sharing printers
between workstations?
a. t may be possible to reduce maintenance costs.
b. Configuration changes and updates can be centralized.
c. Printer sharing saves paper and its by-products.
d. There is a potential for a wider variety of printer types.
2. Samba (configured with printing = cups) will automatically create
printer shares for you based on the host's list of defined queues by
reading the ___________________ file.
3. T/F. Users must be authenticated to use a printer share created by
the default configuration of [printers].
4. T/F. The share name for printer drivers has to be [print$].
Student Notebook
Notes:
We now know why we might want to share printers and how to share printers using
Samba, so all that's left is to DO IT!
Be sure to follow the guidelines given here and the configuration of the printers should be
relatively straightforward.
Unit Summary
Reasons for printer sharing
Automated sharing of all printers
Sharing individual printers
Automatic printer driver installation on Windows clients
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 6. Windows NT Domain Support 6-1
V1.2.2 BKM2MIF
Uempty
Unit 6. Windows NT Domain Support
In this unit we will see how to configure Samba as part of a Windows
NT domain, either as a domain server or as the Primary Domain
Controller (PDC).
List the advantages of working with Windows domains
Configure Samba as a server in a Windows NT domain
Configure Samba as a Primary Domain Controller
Perform User and Group Management in a Samba Domain
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
List the advantages from working with Windows domains
Configure Samba as a server in a Windows NT domain
Configure Samba as a Primary Domain Controller
Perform User and Group Management in a Samba Domain
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 6-2. A Windows Domain LX265.0
Notes:
A Windows Domain is a group of Windows servers and clients who share authentication
and authorization information. This means that any user, when logging in to any client, is
actually logged onto the domain instead of onto the machine that he or she happens to be
sitting at. If the authorization succeeds, the user can access any resources in the domain,
without the need to log on again.
The main characteristic is that the user is authenticated by a central server (the Primary
Domain Controller) when he or she logs on. This also allows the use of logon scripts and
roaming profiles.
A Windows Domain cannot exist without a Primary Domain Controller being present. Since
this machine is crucial to the existence of the domain, a typical domain will have several
backups, called Backup Domain Controllers, which automatically synchronize with the
Primary.
A Windows Domain
A Windows Domain is a group of clients and servers who share
authentication/authorization information
Main characteristics:
Central username/password management
Authentication is performed when logging in, not when accessing
the share
Supports logon scripts
Supports roaming profiles
A Windows Domain always needs a Primary Domain Controller
present
May be augmented with one or more Backup Domain Controllers
Student Notebook
Figure 6-3. Remote Authentication with security=server LX265.0
Notes:
One of the things the Samba team first added to Samba when working on Domain support
was security = server. In this security mode, a user logging on to a Samba server is not
authenticated against the local password database, but against a remote Windows server
or Samba server running in security = user mode. This was basically done by setting up a
second client connection to the authentication server.
Note that this is NOT the same as domain authentication: the client is only authenticated
when the user actually accesses the share, instead of when the user logs on.
There are two main drawbacks to this scheme:
For technical reasons, the connection to the authentication server needs to be kept
open for as long as the user is connected to the share. This can quickly lead to resource
starvation on the authentication server.
The user still needs a local UNIX user ID for Samba to perform the correct Windows
username to UNIX username mapping. This means that you still need to add user
accounts to UNIX, even if you're not sharing home directories at all.
Remote Authentication with security=server
nstead of local authentication, a Samba server can authenticate a
user against another system with security=server
Done by sending a logon request to the password server
specified in smb.conf
This is NOT domain authentication!
Disadvantages
Connection to authentication server needs to be kept open while
share is used (resource starvation)
User still needs a local UNX user account
Windows
client
Samba
server with
security=
server
Windows
or Samba
server
Logon request Logon request
Student Notebook
V1.2.2 BKM2MIF
Uempty
security = server is not used much anymore. Samba has improved and does a far better
job of implementing Windows Domains now.
Student Notebook
Figure 6-4. Remote Authentication with security=domain LX265.0
Notes:
The current version of Samba has near complete Windows Domain support. One of the
things that Samba can do is function as a server in a Windows Domain, where
authentication is passed off to the Primary Domain Controller. This is implemented with the
security = domain option. You also need to specify the password server option, which
should mention the NetBIOS name of the Primary Domain Controller, and the NetBIOS
names of any Backup Domain Controllers, if you have them. Alternatively, you can specify
password server = *, which allows Samba to use the same PDC discovery mechanism
that Windows uses.
You also need to make sure that Samba joins the domain. This is done by creating a
machine account for the Samba server on the PDC, and then executing the command net
rpc join -U Administrator%password. This command can only be executed when the
Samba daemons are not running.
When your Samba system has successfully joined the domain, it will store domain
information in the secrets.tdb file, which is located in the same directory as the other
configuration files.
Remote Authentication with security=domain
security=domain allows domain logons
Password is verified on PDC instead of locally
Specify PDC with password server = {<PDC Name>|*}
Samba server needs to "join" the domain
Create machine account on PDC using Server Manager for
Domains, or:
Stop Samba; net rpc join -U Administrator%passwd; Start
Samba
User still needs a local UNX account!
Only the password is verified on the domain controller
Windows
client
Samba
server with
security=
domain
Windows
PDC
Logon request
Password
validation
Student Notebook
V1.2.2 BKM2MIF
Uempty
With this security setting, one of the problems of security=server has been solved. One
problem remains though: even though the password is checked somewhere else, the user
still needs a local user ID. How to solve this is covered in the Winbind topic.
Student Notebook
Figure 6-5. Samba Primary Domain Controller Support LX265.0
Notes:
Samba can also function as a Primary Domain Controller (PDC). This means that all
authentication is handled by the Samba server, instead of by a Windows machine.
A number of things need to happen before a Samba server can be a PDC though:
First, you need to make sure that the Samba server becomes Local Master Browser
and Domain Master Browser. This is done by setting the os level to a reasonably high
value, and by enabling local master and domain master. You also need to be able to
force browser elections after a restart of the Samba daemons, so you also need to
enable preferred master.
Because the Samba PDC server is the system who performs authentication against the
local databases (the smbpasswd file), you need to put the system in security = user
mode.
You need to enable domain logons so that the Samba server knows that it may be
asked to perform domain logons.
You need to create a [netlogon] share, with settings writable = no and public = no.
Samba Primary Domain ControIIer Support
Samba can function as Primary Domain Controller too:
security = user
domain Iogons = yes
os IeveI = 64
domain master = yes
IocaI master = yes
preferred master = yes
Create [netIogon] share (writabIe = no, pubIic = no)
Machine trust accounts are implemented as regular UNX user
accounts
Name: <NetBIOS name>$
To create machine accounts automatically:
add machine script = /usr/sbin/useradd -g users -s /bin/faIse -M %u
Not implemented: PDC/BDC communication
Student Notebook
V1.2.2 BKM2MIF
Uempty
Being the PDC, the Samba server should also support the regular Windows (or Samba)
servers that are part of the domain. For these systems, a Machine Trust Account needs to
be created. For technical reasons, the Samba team has chosen to implement these
accounts as regular user accounts under UNIX. The user name of these accounts should
be the NetBIOS name of the server, followed by a dollar sign ($). These accounts are not
for logging in, so you might want to set their home directory to /dev/null, and their shell to
/bin/false. You do need to set an initial Samba password though, which is used for the
machine to join the domain.
The command to manually add a machine trust account thus would be:
useradd -g 100 -d /dev/null -c "Machine Nickname" -s /bin/false -M machine_name$
passwd -l machine_name$
smbpasswd -a -m machine_name
The Samba team also added support to the Samba PDC server to create machine trust
accounts on the fly. This is done with the add machine script parameter. Only the root
user is allowed to create machine trust accounts. When you add a machine to a domain,
you therefore need to authenticate to the Samba PDC as a user (for example,
Administrator) which is mapped to the UNIX root account (smbusers file).
The smb.conf line that is needed to create machine trust accounts on the fly is:
add machine script = /usr/sbin/useradd -g users -d /dev/null -c "%U" -s /bin/false
-M %u
Something that is not yet implemented is the communication protocol that is used to
synchronize the PDC with the BDCs. This means that Samba cannot support any Windows
BDCs, nor can it function as a BDC to a Windows PDC.
Student Notebook
Figure 6-6. User/Group Management in a Samba Domain LX265.0
Notes:
Once your Samba-based domain is established, you will want to manage your user and
groups in this domain as well. There are two approaches that you can use for this:
1. Manage all users and groups from UNIX
2. Manage all users and groups from Windows
To manage all your users and groups from UNIX, you need to remember that a Samba
account needs two bits of information: the UNIX authentication information and the
Windows authentication information. UNIX authentication data is stored in /etc/passwd and
managed with the regular useradd/usermod/userdel/groupadd/groupmod/groupdel
commands, while the Windows authentication data is stored (mostly) in smbpasswd, and is
managed with the smbpasswd and net commands.
A second approach which is probably more familiar to your system administrators is to
manage users and groups from Windows. For this, you need to use the usrmgr.exe tool.
This tool is installed by default on a Windows NT system, and can also be found on the
Windows 2000 server CD
1
. This tool can communicate directly with Samba, and Samba is
1
usrmgr.exe is not included with Windows 2000 Professional
User/Group Management in a Samba Domain
Approach 1: Manage all users from UNX
Create UNX account with useradd
Create Samba account with smbpasswd -a
Approach 2: Manage all users from Windows
Done using usrmgr.exe tool from Windows NT
Needs the following scripts defined in [global] section of smb.conf
to create the UNX accounts:
add user script
deIete user script
add group script
deIete group script
add user to group script
deIete user from group script
Samba will create the Samba-part of the account (in smbpasswd
file) automatically
The Windows user creating the user account should be mapped
to the UNX root account (smbusers file)
Student Notebook
V1.2.2 BKM2MIF
Uempty
able to manage the Windows account data (which is stored, after all, in a Samba controlled
file) directly. However, for the UNIX part of the Samba account, Samba needs to know
which commands to invoke if it needs to manage these. Because of this, you need to add
the following directives to smb.conf:
add user script = /usr/sbin/useradd -g users -s /bin/false -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
For Red Hat and Fedora, also add:
add user to group script = /usr/bin/gpasswd -a %u %g
delete user from group script = /usr/bin/gpasswd -d %u %g
For SuSE, use:
add user to group script = /usr/sbin/groupmod -A %u %g
delete user from group script = /usr/sbin/groupmod -R %u %g
Student Notebook
Notes:
1.
2.
3.
Checkpoint
1. T/F. You can have multiple Primary Domain Controllers on one
network.
2. What steps do you need to undertake to configure a Samba server
as member of a domain?
_____________________________________________
_____________________________________________
_____________________________________________
3. What configuration is necessary to allow you to manage user
accounts and groups from Windows (using usrmgr.exe)?
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
A server makes resources (called shares) available to clients on the network. Clients find
those shares by browsing the network. Browse lists are created by the Local Master
Browser for each network segment, since browse information is broadcast and
broadcasting doesn't span network segments. Then all of the LMBs get together and send
their information to a Domain Master Browser (this domain has nothing to do with a
security domain). The DMB then relays the information back to other LMBs on other
segments so that the entire network is kept up to date. The biggest problem with this
scheme is that it doesn't scale well when you've got hundreds or thousands of Windows
clients.
Once a server name is found from the browse lists, it has to be converted into an IP
address so that a conversation can take place. This can be done only partly by DNS,
because DNS doesn't store name_type information needed by the SMB protocol. So
something called WINS is used instead. Samba can be a WINS server, or an NT machine
can take that role.
Unit Summary
Windows NT Domains
security = server
security = domain
Configuring Samba as member of a domain
Configuring Samba as PDC
User and Group Management in a Samba domain
Student Notebook
Clients can be authenticated in either share mode or user mode. These were discussed
previously in the unit on file sharing. This unit covered setting up Samba as a client in an
NT Domain.
Batch scripts and user preferences can be stored on a server to be automatically
downloaded when the user logs on to a server.
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 7. Windows 2000 Domain Support 7-1
V1.2.2 BKM2MIF
Uempty
Unit 7. Windows 2000 Domain Support
In this unit we will explore the capabilities of Samba to participate in a
Windows 2000 domain.
Discuss the main differences between Windows NT and Windows
2000 domains
Discuss the current capabilities of Samba with regards to Windows
2000-style domains
Join Samba as a member in a Windows 2000-style domain
Accountability:
Student Notebook
Notes:
Unit Objectives
Discuss the main differences between Windows NT and Windows
2000 domains
Discuss the current capabilities of Samba with regards to Windows
2000-style domains
Join Samba as a member in a Windows 2000-style domain
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 7-2. Differences Between NT and 2000 Domains LX265.0
Notes:
The introduction of Windows 2000 marked a milestone in the development of Windows
domains. There are two main differences between Windows NT and Windows 2000
domains:
1. A Windows 2000 domain uses Active Directory instead of local registry files to store
authentication information. Active Directory is based on the LDAP standard, which has
two main advantages over regular databases: They have an hierarchical keyspace,
making it easy to tie several directories together into one structure, and theyre fairly
easy to extend in case applications need additional data to be stored with an account.
2. A Windows 2000 domain uses Kerberos to authenticate users instead of sending the
user and password of the user to all servers. This is more secure (a rogue server in a
domain wont be able to intercept (encrypted) passwords, for instance) and it integrates
data communication encryption with authentication. Kerberos also makes it easier to
distribute authentication information over multiple servers. This makes it easier to
perform load balancing.
Differences Between NT and 2000 Domains
Active Directory vs. Local Registry
LDAP-based database of all user/group/machine account data
Allows hierarchical structure of domains ("branch", "tree", "forest")
instead of "interdomain trust accounts"
Fairly easy to extend, for example, by applications that require
additional authentication data to be stored
Kerberos authentication versus username/password
More secure
ntegrates encryption of data communication
Easier to distribute authentication information over multiple
servers
Student Notebook
Unfortunately, Microsoft does not use the LDAP and Kerberos protocols according to the
standards. Instead, it has made several proprietary extensions to both standards, making
interoperability difficult. For both, connecting as a client application or workstation is no
problem at all, but PDC/BDC communication, for instance, is virtually impossible without
using these proprietary extensions. That makes it extremely hard for Samba to participate
in Windows 2000 domains.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 7-3. Local Registry versus Active Directory LX265.0
Notes:
The visual shows a graphical illustration of the hierarchical setup of Active Directory:
With Windows NT (top picture), each domain had its own database of authentication
information and it was not possible to use your credentials from one domain to authenticate
in another domain, unless (complicated and brittle) interdomain trust relations are set up.
With Windows 2000 domains, the keyspace is hierarchical. This makes it easy to use
authentication information from one branch of the tree in another branch.
LocaI Registry versus Active Directory
Domain "A" Domain "B"
interdomain
trust relation
Forest
"cn=ibm,cn=com"
Tree
"ou=nl,
cn=ibm,cn=com"
Tree
"ou=ca,
cn=ibm,cn=com"
Branch
"ou=ites,ou=ca,
cn=ibm,cn=com"
Branch
"ou=ites,ou=nl,
cn=ibm,cn=com"
Branch
"ou=esg,ou=nl,
cn=ibm,cn=com"
Student Notebook
Figure 7-4. Username/Password versus Kerberos LX265.0
Notes:
Again, in the top picture the Windows NT style of authentication is shown. The Windows
client sends a logon request (consisting of the username and an encrypted password) to
the Windows server. This server then validates the username and password with the PDC.
This means that a rogue Windows server always receives the (encrypted) passwords of
users. This server can then try to brute-force them, or use these encrypted passwords in
connections of its own.
With Kerberos (bottom picture), the procedure is different. In a Kerberos realm, there
should be one server (domain controller) which is trusted by all parties. Windows clients
authenticate against this domain controller and identify the server they want to
communicate with. The trusted DC then generates a Kerberos ticket, which contains some
authentication information for the client, but also some (encrypted) authentication
information for the server. The Windows client then sends this ticket to the server, who is
able to verify the authenticity of the client.
Note that the above picture and text is a gross simplification of the Kerberos protocol. In
reality, the DC (as shown above) really consists of two servers: the Kerberos Authentication
Username/Password versus Kerberos
Windows
client
Windows
PDC
Logon request
Password
validation
Windows
server
Windows
client
Windows
server
Windows
DC
a
u
t
h
e
n
t
i
c
a
t
i
o
n

r
e
q
u
e
s
t

(
e
n
c
r
y
p
t
e
d
)
K
e
r
b
e
r
o
s

t
i
c
k
e
t
K
e
r
b
e
r
o
s

t
i
c
k
e
t
c
o
m
m
u
n
ic
a
t
io
n

e
n
c
r
y
p
t
e
d

w
it
h

t
ic
k
e
t
Student Notebook
V1.2.2 BKM2MIF
Uempty
Server (KAS) and the Kerberos Ticket Granting Server (TGS). Communication is also more
complicated than shown here, but the basic principle holds: it is the Kerberos ticket that
authenticates you, not a username/password combination.
A point to note is that Kerberos tickets have a limited lifetime, typically five or ten minutes,
to prevent against replay attacks. Because of this, it is very important that the clocks on all
systems are more-or-less synchronized.
Student Notebook
Figure 7-5. Samba in a Windows 2000 Domain LX265.0
Notes:
Samba is, to a large extent, able to play a role in a Windows 2000 domain.
The first thing to note is that a Windows 2000 domain, even when operating in native
mode, is still able to accept NT-style logons (with username/password authentication). This
means that everything youve seen so far is still working. The only thing that Windows 2000
domains do not support anymore is PDC/BDC communication, NT-style. But Samba is not
able to support that anyway, so thats no great loss.
If you have both Samba and Kerberos installed on your system, you can become a
member server in a Windows 2000 domain too. For this you need to setup Kerberos
correctly (/etc/krb5.conf), and you need to set two directives in the smb.conf file: security =
ads and a realm name. After this, you can join the Windows 2000 domain with net ads
join.
Samba can NOT, as of now, function as a Windows 2000 domain controller. The reason for
this is mostly in the proprietary extensions that Microsoft made to the LDAP protocol for
AD, and to the Kerberos protocol.
Samba in a Windows 2000 Domain
Windows 2000 domains still support NT-style logons (client and
server, but not PDC/BDC communication)
So anything you saw earlier is still possible with W2K
clients/servers
Samba+Kerberos can become a member server in a Windows 2000
domain
Set up Kerberos for proper W2K realm (/etc/krb5.conf)
smb.conf: set security = ads and a reaIm name
net ads join -U Administrator%password
Samba can NOT become a DC for a Windows 2000 domain (yet)
Various reasons - see Samba documentation
Useful commands in a Kerberos environment:
kIist: List all your Kerberos tickets
kinit: Obtain and cache Kerberos tickets - useful for testing
Student Notebook
V1.2.2 BKM2MIF
Uempty
Were not going to cover Kerberos in full here. Its a complicated subject, worthy of its own
course. However, two commands can be useful:
klist shows a list of all tickets that your server obtained.
kinit obtains and caches Kerberos tickets. This is useful for testing.
Student Notebook
Notes:
1.
2.
Checkpoint
1. T/F. Samba can become a member server in a Windows
2000-style domain.
2. What steps do you need to undertake to join a Samba server in a
Windows-2000 style domain?
_____________________________________________
_____________________________________________
_____________________________________________
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
Unit Summary
Differences between Windows NT and 2000 domains
Active Directory
Kerberos
Samba capabilities with regards to Windows 2000 domains
Joining Samba in a Windows 2000 domain
Student Notebook
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 8. User Policies and Profiles 8-1
V1.2.2 BKM2MIF
Uempty
Unit 8. User Policies and Profiles
In this unit were going to configure Samba so that it supports user
policies and profiles.
Automatically map a users home directory to a Windows drive
letter
Create and activate logon scripts
Discuss dynamic logon scripts
Create user and group policies
Set up roaming profiles
Set up mandatory profiles
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
Automatically map a users home directory to a Windows drive letter
Create and activate logon scripts
Discuss dynamic logon scripts
Create user and group policies
Set up roaming profiles
Set up mandatory profiles
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 8-2. User and Group Policies LX265.0
Notes:
In a Windows domain, an administrator can set policies for users. Policies are essentially
lists of things that users can or cannot do, something that in UNIX is solved by setting
permissions on individual commands or files.
In Windows NT, the policy for a system is stored on the [netlogon] share, in a registry file
called ntconfig.pol. When a user logs on to a client system in the domain, this policy is
merged with the local registry of that client. This is called the tattoo effect, because this
merge is not undone when the user logs out.
The tattoo effect might cause severe problems if the policy somehow prevents the
administrator to log in. Because of this, it is best to leave the policy for the default user
and default computer (in the ntconfig.pol file) as it is, and only modify policies for specific
users and groups.
NT-style policies are created with the poledit.exe
1
program by the administrator, and
cannot be changed by the users at all.
1
Just as with usrmgr.exe, poledit.exe is included with Windows 2000 Server, but not with Windows 2000 Professional.
User and Group PoIicies
Windows NT-style policies:
Registry file on PDC (\\netlogon\ntconfig.pol)
Merged with the local registry of the client when a user logs in
(tattoo effect)
Contains dozens of security settings for users and/or groups
For example, contents of Start menu, where certain files are located
and so forth
Created with poledit.exe by administrator
Not changeable by the user
Windows 2000-style policies:
Same idea as Windows NT-style policy, but stored in Active
Directory
Not supported by Samba (yet)
Student Notebook
With the introduction of Windows 2000, policies are no longer stored in a single file, but are
stored into Active Directory. Because of this, there is no tattoo effect and far more flexibility.
Samba, however, is not able to support these kinds of policies.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 8-3. poledit.exe LX265.0
Notes:
The visual shows a screenshot of poledit.exe. As with usrmgr.exe, poledit.exe is not
available on the Windows 2000 Professional CD, but it can be installed from the Windows
2000 Server CD.
In the visual you are able to see that were editing [netlogon]\ntconfig.pol, our main policy
file in the domain. In addition to the default entries Default Computer and Default User,
weve created a separate policy for the user samba1. For this user, weve disabled the Find
command from the start menu.
Note that you should be really careful in modifying the Default Computer and Default
User policies. Because of the tattoo effect, any changes in here will be left in all systems
long after you might have changed the policy. Worst case, this might prevent the
administrator to log in, which means that the system needs to be reinstalled from scratch.
poIedit.exe
Student Notebook
Figure 8-4. User Profile LX265.0
Notes:
The user profile is a collection of directories and registry settings which are either stored
locally (typically in C:\Documents and Settings\Username) or on a network share. This last
location allows a user to access his/her profile regardless of the systems he or she logs in
on, and is therefore called a roaming profile.
Roaming profiles, in contrast to home directories, are not accessed over the network
throughout the day. Instead, the whole profile is copied to the local system when the user
logs in, and is copied back to the server when the user logs out. This means that if the
profile is big, logging in and logging out will take a long time, depending on network
bandwidth.
It is very common for profiles to become very big because, by default, directories such as
Desktop and My Documents are part of the profile. And these are the places where most
Windows applications, by default, store their data. Profiles of several GB in size have been
observed over and over again, leading to a lot of user complaints.
User ProfiIe
Stored locally or on a network share ("roaming profiles")
Roaming profiles: copied to the local computer when a user logs in,
copied back to server when user logs out
f the profile contains a lot of data, logging in and logging out will
be slow, depending on network bandwidth
Contains various user-specific directories
My Documents, Application Data, Desktop
Cookies, Favorites, Start Menu, ...
Contains a file (NTUSER.DAT) with user-specific registry settings
A "mandatory" profile is created by renaming NTUSER.DAT to
NTUSER.MAN
User can still change the profile, but changes will not be copied
back to server when the user logs out
To prevent changes at all, modify user policy
Profile location identified with Iogon path = \\%L\profiIes\%u, or
with user-specific setting in SAM
Student Notebook
V1.2.2 BKM2MIF
Uempty
In addition to various directories, the profile also contains a registry file called
NTUSER.DAT. This file contains such things as the background image of the desktop and a
few other user-specific settings.
A system administrator can decide to make a profile mandatory. This is done by renaming
the file NTUSER.DAT to NTUSER.MAN. In this case, the profile is copied to the client
workstation when the user logs in, but it is not copied back to the server when the user logs
out. This means that next time the user logs in, the original profile is used again. While the
user is logged in however, the user is still able to change his desktop, store files in My
Documents and so forth. This is very confusing to users and because of this, mandatory
profiles are usually combined with very strict policy settings.
The location of a roaming profile can be specified in Samba with the logon path =
\\%L\profiles\%u directive. This directive then applies to all users. In addition to this, if you
use a SAM which supports it (this will be discussed later), you can specify a different profile
location for each user.
Student Notebook
Figure 8-5. Mapping Home Directories LX265.0
Notes:
To prevent slow logons and logouts, caused by big profiles being copied back and forth,
make sure users keep their profile small and store their personal data in their home
directory. You can make this easier by setting a policy that ensures that some default
directories are not part of the profile, but stored elsewhere.
Note that the location of some directories, particularly My Documents is not specified in
the policy file, but rather by the My Documents shortcut on the desktop. Right-click on this
icon, and simply change the location.
Home directory use is made easier for users if the home directory is mapped to a local
drive. Most often, this local drive is called H: (for Home) or U: (for User). This mapping can
be established automatically when the user logs in by setting the smb.conf logon home
and logon drive directives.
Mapping Home Directories
To prevent slow logins/logouts, make sure users use their home
directory instead of their profile for data
A policy setting allows you to store most "standard" directories on
that home directory as well, instead of the profile
Some directories, for instance My Documents, are shortcuts on
the desktop instead of policy settings
To automatically create a map for the home directory when the user
logs in:
Iogon home = \\%N\%U
Iogin drive = H:
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 8-6. Logon Scripts LX265.0
Notes:
If you want to setup more mappings for users, or if you want to execute other commands
when a user logs in, logon scripts can be useful. These logon scripts are simple BAT or
CMD files which are stored on the [netlogon] share, and they are executed when the user
logs in.
Note that these files need to use the MS-DOS line ending (CR/LF) instead of the UNIX line
ending (LF). This can be achieved by using :set tx in vi, or by modifying the file afterwards
with unix2dos.
To enable the script, use the logon script = logon.bat directive in smb.conf. Obviously,
this enables the same logon.bat script for all users. You can also specify logon script =
%u.bat to have user-specific scripts.
A useful feature in Samba, which is not possible in Windows, is to use dynamic logon
scripts. To use this, create a UNIX script or program which generates the logon.bat script
for you, and execute this UNIX script or program with a root preexec directive on the
[netlogon] share. Obviously, you can use the whole list of %variables as argument to the
Logon Scripts
For mapping other directories when a user logs in, and for various
other tasks, a Iogin script can be useful
BAT or CMD file, stored on [netlogon], which is executed when the
user logs in
Note: Needs MS-DOS line ending (CR/LF) instead of UNX (LF)
smb.conf: Iogon script = Iogon.bat
An example logon script:
@echo off
net use s: \\groupserver\samba
net use t: \\tmpserver\tmp
To create your logon scripts dynamically: Create a UNX script or
program which generates the logon script, and run this
script/program as root preexec script in the [netlogon] share:
root preexec = generate_Iogon_script %m %u %a %g %L
Student Notebook
script or program, and use this to make a truly custom logon script for each user, based on
group membership and various other parameters.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
1.
2.
3.
Checkpoint
1. T/F. When a Linux user logs on to a Windows domain with
smbpasswd, the logon script is executed by smbpasswd in an
emulated MS-DOS environment.
2. List the smb.conf directives that are required for mapping the users
home directory to a local drive letter.
_____________________________________________
_____________________________________________
_____________________________________________
3. T/F. When a user has a mandatory profile, he or she is not able to
change the background image on the desktop.
Student Notebook
Notes:
Unit Summary
Automatic mapping of home directories to local drive letters
Logon scripts and automatic generation of logon scripts
User and group policies
Roaming profiles
Mandatory profiles
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 9. The LDAPSAM Backend 9-1
V1.2.2 BKM2MIF
Uempty
Unit 9. The LDAPSAM Backend
In this unit we will see how to configure Sambas LDAPSAM backend,
which is used to store both Windows and UNIX account data.
List various SAM backends supported by Samba
Discuss the main characteristics of LDAP
Discuss the Samba/UNIX/LDAP ecosystem
Configure OpenLDAP, smbldap-tools, Samba and UNIX to use
LDAP as backend
Discuss user management in an LDAPSAM environment
Discuss migration from Windows NT to Samba/LDAP
Accountability:
Lab exercises
Student Notebook
Notes:
Unit Objectives
List various SAM backends supported by Samba
Discuss the main characteristics of LDAP
Discuss the Samba/UNX/LDAP ecosystem
Configure OpenLDAP, smbldap-tools, Samba and UNX to use
LDAP as backend
Discuss user management in an LDAPSAM environment
Discuss migration from Windows NT to Samba/LDAP
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-2. Security Account Manager Backends LX265.0
Notes:
The Security Account Manager (SAM) is the component of Samba that stores all Windows
authentication data, such as passwords, home directory location, account flags and so
forth. You select the SAM to use with the passdb backend directive in smb.conf, and you
may actually specify multiple backends, if necessary. This last thing can be useful in a
migration scenario.
Samba 3.x supports several SAMs:
smbpasswd The default SAM, where Samba stores authentication data in
/etc/samba/smbpasswd and a few related files. The
disadvantage of this SAM is that only a few bits of information
can be stored, and that performance with a large number of
users is not good.
tdbsam A SAM which stores all authentication data in Trivial DataBase
(TDB) files. The advantage over smbpasswd is that TDB
lookups are faster than flat file lookups, making performance
Security Account Manager Backends
Security Account Manager (SAM): Samba component that stores
authentication information
dentified with passdb backend = <SAM>[:<SAM URL>]
May specify multiple backends (useful when migrating)
Possible SAMs:
smbpasswd (default): Traditional Samba backend
(/etc/samba/smbpasswd and friends)
tdbsam: Uses TDB (Trivial DataBase) files in /etc/samba
mysqI: Uses MySQL
nispIussam: Uses NS+
Idapsam: Uses LDAP Directory
Advantages of most other backends over smbpasswd:
Performance (indexed lookups instead of flat file lookups)
Can store more user attributes (for example, home dir, profile dir)
Replication easier
ntegrates with existing infrastructure for authentication data
(NS+, LDAP)
Student Notebook
with 100s of users far better. But on the other hand, it is harder
to make manual changes to these files.
mysql A SAM which uses MySQL to store authentication data.
Advantages: performance and easier replication of data.
nisplussam A SAM that uses NIS+ to store authentication data. The main
advantage is that it integrates with an existing authentication
subsystem.
ldapsam A SAM that uses LDAP to store authentication data. This is the
most powerful SAM that Samba supports. Advantages are:
Performance
Hierarchical keyspace: Just like Active Directory, allows easy
integration of multiple domains into one big hierarchical
structure.
Integration with existing authentication subsystem: UNIX can
use LDAP too as its authentication subsystem.
Allows more flexible storage of user attributes, including
Windows attributes such as home directory share, profile share,
login drive, logon script and so forth.
Easy replication of authentication data, negating the need for
PDC/BDC communication, Windows-style.
The only real disadvantage of LDAPSAM is that the
configuration is quite complex.
In this unit were going to discuss the LDAPSAM backend. Information on other backends
can be found in the Samba documentation.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-3. Whats a Directory? LX265.0
Notes:
A directory is a listing of information about objects arranged in some order that gives details
about each object. Common examples are a city telephone directory and a library card
catalog. For a telephone directory, the objects listed are people; the names are arranged
alphabetically, and the details given about each person are address and telephone number.
Books in a library card catalog are ordered by author or by title, and information such as the
ISBN number of the book and other publication information is given.
In computer terms, a directory is a specialized database, also called a data repository, that
stores typed and ordered information about objects. A particular directory might list
information about printers (the objects) consisting of typed information such as location (a
formatted character string), speed in pages per minute (numeric), print streams supported
(for example PostScript or ASCII), and so on.
Directories allow users or applications to find resources that have the characteristics
needed for a particular task. For example, a directory of users can be used to look up a
persons e-mail address or fax number. A directory could be searched to find a nearby
What's a Directory?
A "directory" is a listing of information about objects arranged in
some order that gives details about each object
Directories allow users or applications to find resources that have
the characteristics needed for a particular task
Examples of directories:
City telephone directory
Library card catalog
Student Notebook
PostScript color printer. Or a directory of application servers could be searched to find a
server that can access customer billing information.
The terms white pages and yellow pages are sometimes used to describe how a directory
is used. If the name of an object (person, printer) is known, its characteristics (phone
number, pages per minute) can be retrieved. This is similar to looking up a name in the
white pages of a telephone directory. If the name of a particular individual object is not
known, the directory can be searched for a list of objects that meet a certain requirement.
This is like looking up a listing of hairdressers in the yellow pages of a telephone directory.
However, directories stored on a computer are much more flexible than the yellow pages of
a telephone directory because they can usually be searched by specific criteria, not just by
a predefined set of categories.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-4. Directories versus Relational Databases LX265.0
Notes:
A directory is often described as a database, but it is a specialized database that has
characteristics that set it apart from general purpose relational databases. One special
characteristic of directories is that they are accessed (read or searched) much more often
than they are updated (written). Hundreds of people might look up an individuals phone
number, or thousands of print clients might look up the characteristics of a particular printer.
But the phone number or printer characteristics rarely change.
Because directories must be able to support high volumes of read requests, they are
typically optimized for read access. Write access might be limited to system administrators
or to the owner of each piece of information. A general purpose database, on the other,
hand needs to support applications such as airline reservation and banking with high
update volumes.
Because directories are meant to store relatively static information and are optimized for
that purpose, they are not appropriate for storing information that changes rapidly. For
example, the number of jobs currently in a print queue probably should not be stored in the
directory entry for a printer because that information would have to be updated frequently
Directories versus ReIationaI Databases
Directory Relational Database
Examples LDAP, X.500,
Microsoft Active
Directory
DB2, Oracle,
PostgreSQL, MySQL
Keyspace Hierarchical Linear
Data Loosely structured Strictly structured
Optimized for Lookups Updates
Security model Simple Complex
Tables One or more,
unrelated
Typically more,
related
Atomic transactions
possible?
No Yes
Replication between
systems
Easy because
inconsistency is
(temporarily) allowed
Hard: inconsistency
not allowed
Way of accessing
information
Simplified and
optimized access
protocol (LDAP)
Structured Query
Language (SQL)
Student Notebook
to be accurate. Instead, the directory entry for the printer could contain the network address
of a print server. The print server could be queried to learn the current queue length if
desired. The information in the directory (the print server address) is static, whereas the
number of jobs in the print queue is dynamic.
Another important difference between directories and general purpose databases is that
directories may not support transactions (some vendor implementations, however, do).
Transactions are all-or-nothing operations that must be completed in total or not at all. For
example, when transferring money from one bank account to another, the money must be
debited from one account and credited to the other account in a single transaction. If only
half of this transaction completes or someone accesses the accounts while the money is in
transit, the accounts will not balance. General-purpose databases usually support such
transactions, which complicates their implementation.
Because directories deal mostly with read requests, the complexities of transactions can be
avoided. If two people exchange offices, both of their directory entries need to be updated
with new phone numbers, office locations, and so on. If one directory entry is updated, and
then other directory entry is updated there is a brief period during which the directory will
show that both people have the same phone number. Because updates are relatively rare,
such anomalies are considered acceptable.
The type of information stored in a directory usually does not require strict consistency. It
might be acceptable if information such as a telephone number is temporarily out of date.
Because directories are not transactional, it is not a good idea to use them to store
information sensitive to inconsistencies, like bank account balances.
Because general-purpose databases must support arbitrary applications such as banking
and inventory control, they allow arbitrary collections of data to be stored. Directories may
be limited in the type of data they allow to be stored (although the architecture does not
impose such a limitation). For example, a directory specialized for customer contact
information might be limited to storing only personal information such as names,
addresses, and phone numbers. If a directory is extensible, it can be configured to store a
variety of types of information, making it more useful to a variety of programs. Another
important difference between a directory and a general-purpose database is in the way
information can be accessed. Most databases support a standardized, very powerful
access method called Structured Query Language (SQL). SQL allows complex update and
query functions at the cost of program size and application complexity. LDAP directories,
on the other hand, use a simplified and optimized access protocol that can be used in slim
and relatively simple applications.
Because directories are not intended to provide as many functions as general-purpose
databases, they can be optimized to economically provide more applications with rapid
access to directory data in large distributed environments. Because the intended use of
directories is restricted to a read-mostly, nontransactional environment, both the directory
client and directory server can be simplified and optimized.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-5. LDAP Concepts (1 of 2) LX265.0
Notes:
At the heart of the LDAP definitions is the notion of object. An object is a single entry in
the LDAP directory. It typically has a number of attributes, such as the name, the address
or the telephone number.
All objects in an LDAP directory are of a specific object class, which is described in the
directory schema. Among other things, the schema describes the required and optional
attributes of an object, and describes the syntax of each attribute.
As an example, a person object is required to have a name, while a car object will be
required to have a license plate number. And both a person object and a company
object may have a telephone number, while a car object may not.
The definition of a telephone number attribute is also part of the schema. A typical
telephone number will consists of a number of digits, optionally separated with dashes,
brackets, slashes and spaces. But the dashes, brackets, slashes and spaces are not
relevant: The telephone number 345-5412 is considered equal to (345) 54 12.
LDAP Concepts (1 of 2)
LDAP objects are described using attributes
For example, telephonenumber=838-6004
All objects in an LDAP database have required and optional
attributes, this is described in the "Schema"
The "Distinguished Name" (DN) is the combination of attributes
which uniquely identifies an object in the database (key)
Typically: Base DN + one additional attribute
For example, C=US, O=IBM, OU=IT Education Services,
CN=John Smith
The "Base DN" is the combination of attributes which identifies the
LDAP directory itself
For example, C=US, O=IBM, OU=IT Education Services
Student Notebook
A Distinguished Name (DN) refers to a combination of attributes that uniquely identify a
directory or an object in that directory. When a DN refers to a directory, we typically call this
a Base DN. All objects in that directory will typically have the Base DN in common, and
will have one additional attribute, often the Common Name or CN, which uniquely identifies
the object in the database. In other words: the DN of an object in a directory is typically the
Base DN of the directory plus one additional attribute, most often the Common Name.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-6. LDAP Concepts (2 of 2) LX265.0
Notes:
LDAP directories typically have a globally unique Base DN. This makes it possible to
incorporate a large number of LDAP directories into a global, hierarchical structure not
unlike the global DNS system. In practice, such a global system does not exist, although
several global organizations (including IBM) have created their own internal hierarchical
structure.
The visual shows an example of such a global structure: Like DNS, there is a global root
directory which knows how to find the directories for each country. Every country directory
will know each organization in that country, and each organization knows each organization
unit. In the example above, up to here the complete structure is virtual.
There is an LDAP directory however, whose Base DN is ou=IT Education Services,
O=IBM, C=US. This LDAP directory contains one object, whose DN is CN=John Smith,
OU=IT Education Services, O=IBM, C=US. Apart from the attributes that make up the DN,
the object also defines a number of other attributes such as SN (Surname), Given name,
UID (User ID) and telephone number.
LDAP Concepts (2 of 2)
(Directory Root)
C=US
O=BM
OU=T Education Services
DN: CN=John Smith, OU=T Education Services, O=BM, C=US
CN: John Smith
OU: T Education Services
O: BM
C: US
SN: Smith
Givenname: John
UD: jsmith
telephonenumber: 838-6004
Root DN: OU=T Education Services, O=BM, C=US
C=CA C=NL
O=BM O=BM O=BM
Student Notebook
As said, the global structure typically does not exist. This means that organizations dont
have to conform to global naming conventions. However, to avoid problems in the future,
most organizations set their Base DN to something that can be derived from the actual
DNS name of that organization (which is, after all, globally unique). IBM for instance could
use the following Base DNs: cn=ibm,cn=com instead of C=US,O=IBM.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-7. The Core Schema LX265.0
Notes:
As part of the LDAP protocol definition, a set of schema was also defined that could be
used by LDAP implementations. These standard schema, although not required, have
gained widespread acceptance. Most organizations either only use the standard schema,
or use the standard schema as a basis to add their own attributes and object classes to.
This means that most LDAP implementations will be compatible with each other.
The core schema define a large number of attributes, such as common name, surname,
country, telephone number and so forth. With these attributes, the schema also define a
large number of object classes such as country, organization, person,
organizationalPerson and so forth. For each object class, the schema also specifies which
attributes are required and optional.
The "Core" Schema
Set of schema defined in various RFCs
Form the default building blocks of an LDAP directory
Attributes defined:
cn: Common name
sn: Surname
c: Country
...
ObjectClasses defined:
country
organization
person
...
Defines required/optional attributes for each ObjectClass
Student Notebook
Figure 9-8. The NIS Schema LX265.0
Notes:
The NIS schema is developed specifically to implement a UNIX (Posix) account. In this
schema, youll find all the fields that are normally stored in /etc/passwd, /etc/shadow,
/etc/group and so forth.
The "NIS" Schema
Set of schema that define the information needed to implement a
UNX account
Attributes defined:
userPassword
uidNumber
gidNumber
gecos
homeDirectory
loginShell
...
posixAccount
shadowAccount
posixGroup
...
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-9. The Samba Schema LX265.0
Notes:
The last schema we need to discuss here is the Samba schema. This schema was
developed specifically by the Samba team for the LDAPSAM backend. It is officially
registered and contains attributes weve already seen in the smbpasswd file and with the
pdbedit command.
The "Samba" Schema
Set of schema that define the information needed to implement a
Samba account
Attributes defined:
sambaLMPassword
sambaNTPassword
sambaAcctFlags
sambaPwdLastSet
sambaHomePath
sambaProfilePath
...
sambaSamAccount
sambaGroupMapping
sambaDomain
...
Student Notebook
Figure 9-10. Typical LDAPSAM Setup LX265.0
Notes:
In a typical LDAPSAM environment, LDAP is used to store both the UNIX and the Samba
authentication data, and possibly even more. At the very least, this means that youre going
to use both the NIS and Samba schema.
The advantage of this is that LDAP now stores all authentication data for a user within a
single LDAP object. This makes it easy to manage user and group accounts throughout
your environment, and makes it easy to replicate this information over a few servers (load
balancing, failover).
The main disadvantage of this is that the setup is rather complex, as you will see in this
unit. Also, you need to have management tools that are able to handle this setup. Most
tools, particularly the easy-to-user graphical ones, do not support the typical LDAPSAM
setup, meaning that you have to create them yourselves or revert back to the Command
Line Interface (CLI) tools.
TypicaI LDAPSAM Setup
n a typical environment, LDAP is used to store both UNX and
Samba authentication data
Advantages:
One location for ALL authentication information
Easy replication of authentication information
Disadvantages:
Complicated setup
Not all management tools are able to handle this
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-11. The Samba/UNIX/LDAP Ecosystem LX265.0
Notes:
The visual shows the LDAPSAM Ecosystem: all the components that make up a typical
LDAPSAM implementation, and their relationship with each other.
The first component, in the center, is the OpenLDAP server. In its directory, it holds both the
UNIX and Samba account information, and possibly even more than that.
Two UNIX subsystems, NSS and PAM, both retrieve UNIX account data from the
OpenLDAP server. NSS uses this account information to supply it to commands such as ls
-l, id, getent and so forth. PAM uses this information to authenticate the user when he or
she logs on to the UNIX system (locally or via the network).
Samba communicates with the OpenLDAP server as well. It uses OpenLDAP to manage
and retrieve the Samba (Windows) account information such as LANMAN and NT
passwords, user profile shares, logon drives and so forth.
In addition to Samba, you also need to install the smbldap-tools. These tools can be used
in two ways:
The Samba/UNIX/LDAP Ecosystem
OpenLDAP Server
(holds UNX and
Samba account
information)
NSS
Subsystem
PAM
Subsystem
OpenLDAP
(text-based)
client tools
gq or other
graphical
tools
smbldap-tools Samba
Retrieve UNX
account information
Perform UNX authentication
troubleshooting troubleshooting
Manage UNX and
Samba accounts
Manage and Retrieve
Samba account information
Samba uses the
smbldap-tools
to manage the
UNX accounts
Student Notebook
If you use these tools manually, from the command line, then you manage both the
UNIX and Windows data that is stored in OpenLDAP. So in this case you use these
tools as direct replacement for useradd, groupadd and so forth.
The smbldap-tools can also be used from Samba. In this case, the tools are only used
to manage the UNIX account data in LDAP: Samba will manage the Windows part of
the Samba account directly, without going through the smbldap-tools.
The last bit of kit youll find in the ecosystem is a series of tools used to troubleshoot LDAP.
Depending on your preferences and familiarity with LDAP, you will use the OpenLDAP CLI
client tools for this, or a graphical client such as gq.
Note that there are two components that need write access to the OpenLDAP database, in
addition to OpenLDAP itself: Samba and the smbldap-tools. In most installations, this is
done by simply configuring the RootDN password for these two components. This is the
approach used in this course. But it is also possible to setup a special management
account within LDAP, and to let Samba and the smbldap-tools bind to this management
account instead of the RootDN account.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 9-12. Configure OpenLDAP - General LX265.0
Notes:
The first step in configuring LDAPSAM is to configure OpenLDAP itself, through the
configuration file /etc/openldap/slapd.conf. The following items are important:
Make sure all required schema are included.
Choose a suffix for your LDAP environment. In the examples, we will use
dc=lx26,dc=com.
Define the RootDN for your OpenLDAP server, and set a RootDN password.
To encrypt this RootDN password, use the command slappasswd -h {MD5}.
For performance, set a few additional indices.
If you are using OpenLDAP 2.2 or higher (for example, on SLES9), then you need to know
that the Samba schema and smbldap-tools are not completely RFC compliant. OpenLDAP
2.2 by default will verify this and complain. To disable schema checking, add the following
to your slapd.conf file:
schemacheck off
Configure OpenLDAP - GeneraI
# /etc/openldap/slapd.conf
...
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
...
database ldbm
suffix "dc=lx26,dc=com"
rootdn "cn=Manager,dc=lx26,dc=com"
rootpw {MD5}JVjCcT8HpBD5QpncQEv/tg==
directory /var/lib/ldap
index objectClass,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq
index default sub
...
Student Notebook
Figure 9-13. Configure OpenLDAP - Authorization LX265.0
Notes:
We also need to configure LDAP authorization, to determine what users have what sort of
access to what data. Because were combining UNIX and Windows data in one server, this
is a bit complicated.
The userPassword attribute is used by PAM to authenticate a user. So users who are
not yet authenticated (anonymous users) should be able to use this attribute to
authenticate against it. The user itself should be able to change it, and other users
should not be able to see it at all.
The gecos and loginShell are two fields that UNIX users can traditionally change
themselves (through the chfn and chsh programs). We need to allow that too here.
The SambaLMPassword and SambaNTPassword attributes are used by Samba to
store the Windows password. Windows, depending on the version in use, uses either
LANMAN or NT encryption, and Samba needs to store both.
If a user authenticates to the Samba server, its not LDAP which verifies the password
(as is done in UNIX authentication), but Samba itself: Samba will bind to the LDAP
Configure OpenLDAP - Authorization
access to attr=userPassword
by self write
by anonymous auth
by dn="cn=Manager,dc=lx26,dc=com" write
by * none
access to attrs=gecos,loginShell
by self write
by * read
access to attrs=SambaLMPassword,SambaNTPassword
by self write
by * none
access to *
by * read
Student Notebook
V1.2.2 BKM2MIF
Uempty
server as RootDN, retrieve the SambaLMPassword and SambaNTPassword for the
user, and verify the password it received against these two. Because of this, the only
access that is really required is for the RootDN. In the future Windows users may get a
more direct path of communication with the LDAP server, and may be needing to
change their passwords themselves.
In any case, other users are not allowed to view these passwords at all.
All users have read access to all other attributes.
Note that the RootDN has write access to all attributes. The RootDN is also the only
account which is able to add objects to the LDAP database. Therefore, later in this unit, we
will see that both the smbldap-tools and Samba itself will bind as RootDN to LDAP.
Student Notebook
Figure 9-14. smbldap Tools LX265.0
Notes:
The smbldap-tools is a set of tools, written in perl, from www.idealx.org. Theyre included in
the Samba distribution, among the documentation. You need to copy them to a suitable
location (usually /usr/local/sbin) yourselves. In addition to this, you need to compile the
mkntpwd tool and install it in the same location.
The smbldap-tools use the Net::LDAP perl module extensively. On Fedora and Red Hat,
this module is not included, unfortunately. So you need to install this module from CPAN
yourselves. Look at the Exercise Instructions with Hints for this unit to see how to do this.
To configure the smbldap-tools, edit the file smbldap_conf.pm. This file will also contain the
plain-text RootDN password, so its wise to set the permissions on this file to 640.
When youve configured your smbldap-tools and have started your OpenLDAP server, run
the script smbldap-populate.pl. This populates the OpenLDAP server with an initial
structure and a few default accounts, including Administrator and nobody. The
Administrator user is by default a normal account. We will be using this account for a lot of
management too, so its wise to map this to the root account by setting the UID for this
account to zero.
smbIdap TooIs
Set of tools (written in perl) from www.idealx.org
ncluded in Samba distribution - copy to /usr/local/sbin
Fedora, Red Hat: nstall Net::LDAP perl module from CPAN
Modify smbldap_conf.pm for your situation, including RootDN
password (file should be mode 640 because of this)
Use smbIdap-popuIate.pI to populate LDAP with initial structure
By default, Administrator is a regular user - change this to map to
the root account
Use other smbIdap-* tools to manage user and group accounts
When used manually, use -a option to create/modify both the
UNX and Samba account information
When used from Samba, DO NOT use -a option, as Samba
creates/modifies the Samba account information itself
Verify correct initial population of LDAP directory:
sIapcat: Reads LDAP directory directly
Idapsearch: Reads LDAP directory through OpenLDAP
Student Notebook
V1.2.2 BKM2MIF
Uempty
Once done, you can use the other smbldap-* tools (smbldap-useradd.pl,
smbldap-usermod.pl and so forth) to manage user and group accounts. Remember that,
when you use these tools manually, you use them to manage both the UNIX and Windows
account data. This is done with the -a option. However, when you use these tools from
Samba, you only need them to manage the UNIX account data: Samba manages the
Windows data itself. So in that case, do not use the -a option.
Once your database has been populated, you can verify its contents directly using slapcat
or via the OpenLDAP server using ldapsearch.
Student Notebook
Figure 9-15. Configure UNIX Authentication LX265.0
Notes:
Now that weve got LDAP up and running, were going to configure our UNIX authentication
subsystem (consisting of NSS and PAM) to use it. Both of these subsystems can be
configured to use LDAP through the use of authconfig (Fedora and Red Hat) or yast
(SuSE).
After running authconfig or yast, verify that your /etc/nsswitch.conf file contains the
following:
nss_base_passwd dc=lx26,dc=com?sub
nss_base_shadow dc=lx26,dc=com?sub
nss_base_group ou=Groups,dc=lx26,dc=com?one
The reason for this is the following:
The smbldap-tools and Samba will store user accounts in the ou=People,dc=lx26,dc=com
hierarchy, while computer accounts are stored in the ou=Computers,dc=lx26,dc=com
hierarchy. However, as weve seen earlier, in UNIX, a computer account is implemented as
a user account (using <netbios name>$ as username). Therefore, programs like getent
Configure UNIX Authentication
NSS subsystem: Retrieves user information for programs like Is -I,
id, who, getent and so forth
PAM subsystem: Performs user authentication
Both subsystems need to be modified to use LDAP
Use distribution tool such as authconfig (Fedora, Red Hat) or
yast (SuSE) to accomplish this
Verify that /etc/nsswitch.conf contains the following, for correct
handling of Computer accounts:
nss_base_passwd dc=Ix26,dc=com?sub
nss_base_shadow dc=Ix26,dc=com?sub
nss_base_group ou=Groups,dc=Ix26,dc=com?one
Verify correct configuration:
getent: Reads passwd information through NSS subsystem
Logging in as regular user whose info is stored in LDAP (keep
root session open in case of problems)
Student Notebook
V1.2.2 BKM2MIF
Uempty
need to traverse both the ou=People,dc=lx26,dc=com and ou=Computers,dc=lx26,dc=com
trees. This is accomplished by specifying dc=lx26,dc=com?sub.
To verify the correct operation of NSS, you can use the getent passwd and getent group
commands. To verify the correct operation of PAM, login as a user that only exists in the
LDAP database.
Make sure to keep a root session open at all times while configuring PAM and/or NSS: If
you make a mistake during configuration, you might not be able to login as root again.
Student Notebook
Figure 9-16. Configure Samba LX265.0
Notes:
Were nearly done with the configuration of LDAPSAM. The last item is the Samba server
itself.
For starters, we need to remove everything that relates to our current smbpasswd SAM
backend, particularly the username map and smbpasswd file directives.
Then, were going to configure Samba to use LDAP as backend. The base configuration of
this starts with passdb backend = ldapsam:ldap://<servername>. We also need to
configure whether we want to use SSL or not, and various parameters that define the DNs
to use.
We also need to change our add/modify/delete user/machine/group scripts so that we use
the appropriate smbldap-tools command instead of the regular useradd, userdel and so
forth. A complete list of these commands is:
add machine script = \
/usr/local/sbin/smbldap-useradd.pl -w %u
add user script = \
Configure Samba
smb.conf:
Remove username map and smbpasswd fiIe
Add LDAP backend information:
passdb backend = Idapsam:"Idap://<servername>"
Idap ssI = none
Idap suffix = dc=Ix26,dc=com
Idap admin dc = cn=Manager,dc=Ix26,dc=com
Idap user suffix = ou=PeopIe
Idap group suffix = ou=Groups
Idap machine suffix = ou=Computers
Idap deIete dn = no
Change add/delete user/machine/group scripts to use
smbldap-tools
Store the RootDN password in /etc/samba/secrets.tdb:
smbpasswd -w <passwd>
Verifying correct configuration:
Use pdbedit -L/pdbedit -Lv <user> to verify Samba sees data
Use smbcIient to logon
Student Notebook
V1.2.2 BKM2MIF
Uempty
/usr/local/sbin/smbldap-useradd.pl -m %u
delete user script = \
/usr/local/sbin/smbldap-userdel.pl %u
set primary group script = \
/usr/local/sbin/smbldap-usermod.pl -g %g %u
add group script = \
/usr/local/sbin/smbldap-groupadd.pl %g
delete group script = \
/usr/local/sbin/smbldap-groupdel.pl %g
add user to group script = \
/usr/local/sbin/smbldap-groupmod.pl -m %u %g
delete user from group script = \
/usr/local/sbin/smbldap-groupmod.pl -x %u %g
The last thing to do is to store the RootDN password in the /etc/samba/secrets.tdb file. This
is done with the smbpasswd -w <passwd> command.
This finishes our LDAPSAM configuration. To verify this last part, use pdbedit to list the
LDAP data, but now by going via Samba. You can also use pdbedit to modify a few user
attributes such as the logon script, and verify through other means (for example, slapcat,
ldapsearch, ...) that this change really made it into the LDAP database.
The final test, obviously, is when you can logon, using smbclient or from a Windows
system, and when you can join Windows systems in your domain.
Student Notebook
Figure 9-17. Account Management LX265.0
Notes:
User management is done exactly like when we were using the smbpasswd SAM backend.
However, the LDAPSAM backend also allows you to store additional Windows attributes
such as the profile directory and the home directory of a user. There are several ways of
managing these attributes, most notably the usrmgr.exe and pdbedit tools. But you can
also manage them using the smbldap-tools, via ldapmodify (part of the OpenLDAP client
tools), gq and other graphical tools.
Now that LDAP is configured, you can also reap a few additional benefits. Two benefits
stand out:
The first benefit is that LDAP has support built-in for replication. This leads to higher
availability and load balancing of your LDAP service. Replicating LDAP servers is not
covered here, but is part of the LX07 course.
The second benefit is that you dont need to let each Samba member server become part
of your domain: traditionally a domain was formed so that each server had access to the
same authentication data, but now you can configure each member server as an LDAP
client and get essentially the same result and functionality.
Account Management
As with the smbpasswd backend, account management is done
using usrmgr.exe or pdbedit
But you can now modify attributes like the logon script, the profile
directory, the home directory and so forth as well
For larger sites, consider LDAP replication (covered in LX07 course)
and specify multiple passdb backends on each Samba server:
passdb backend = Idapsam:"Idap://main_server"
Idapsam:"Idap://backup_server"
With LDAP, each Samba server has direct access to UNX and
Samba account information
No need for security = domain or security = ads on a domain
member anymore - all Samba servers can run with security =
user
No need for native PDC/BDC communication
Student Notebook
V1.2.2 BKM2MIF
Uempty
Both these benefits mean that there is no need anymore to implement any of the PDC/BDC
protocols that Microsoft invented and carefully keeps secret.
Student Notebook
Figure 9-18. Migrating an Existing Domain to Samba/LDAP LX265.0
Notes:
Because the Samba/LDAP combination is so powerful, and offers essentially the same
benefits as a Windows 2000 domain, a lot of people are migrating their Windows NT
domains not to Windows 2000, but to Samba/LDAP. A few helpful hints and tips follow here
if you want to do the same thing:
If you dont want to unjoin and then join all your client workstations in a new domain, and a
complicated policy/profile migration, you can configure your Samba domain with the same
SID as the original Windows NT domain. This is done using net rpc getsid to get the SID
from Windows NT, and then store this in Samba with net setlocalsid. Make sure this new
SID is also used in the smbldap-tools, and make sure you never bring up your new Samba
server while the old Windows NT PDC is still running!
Migrating all existing user, group and computer accounts can be done using net vampire.
For this to work successfully, your Samba server first needs to be joined as a member
server in the Windows NT domain. In addition to this, pdbedit also has functionality to
migrate accounts from one SAM to another.
Migrating an Existing Domain to Samba/LDAP
Make sure you retain the current SD
Retrieve SD from Windows PDC using net rpc getsid and use
this in your Samba/LDAP domain (net setIocaIsid)
Migrate all current user accounts to Samba using pdbedit and/or
net rpc vampire
Note: These only create the Samba accounts, not the UNX
accounts!
net rpc vampire disables all accounts: use pdbedit to enable
Migrate all current profiles to Samba using Samba tool profiIes
Watch out for ACLs when copying data from existing Windows
shares to Samba
Lots of ACLs are normally a sign of a weak user/group design
Use the migration to implement a better design which does not
rely on ACLs
f you need to retain ACLs, copy your files from Windows to
Samba using Windows Explorer, while logged in as Administrator
(should be mapped to root on UNX)
Student Notebook
V1.2.2 BKM2MIF
Uempty
If you change the domain SID, then you need to be aware of the fact that this SID is stored
in the user profile as well. The Samba tool profiles allows you to dive into this user profile
and change the domain SID with one single command.
The last bit of advise is with regards to ACLs. Experience has shown that a lot of Windows
file shares are filled with ACLs, mainly to work around a weak user/group structure. A
migration is normally a good opportunity to create a better user/group structure which does
not need ACLs anymore. If you do need to retain ACLs though, make sure that you copy
your data using Windows tools (for example, Windows Explorer), while logged in as
Administrator. Copying data using traditional UNIX tools (for example, cp) does not copy
the ACLs.
Student Notebook
Notes:
1.
2.
3.
Checkpoint
1. n what locations do you need to configure the RootDN password?
2. What is the main directive that tells Samba to use LDAP as its
backend?
_____________________________________________
_____________________________________________
_____________________________________________
3. T/F. t is possible to only store Samba account data in LDAP, and
store the UNX account data somewhere else.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
Unit Summary
SAM backends
LDAP concepts
Samba/LDAP ecosystem
OpenLDAP/smbldap-tools/UNX/Samba configuration
Account management in an LDAPSAM environment
Migration from Windows NT to Samba/LDAP
Student Notebook
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 10. WinBind 10-1
V1.2.2 BKM2MIF
Uempty
Unit 10. WinBind
In this unit we will discuss Winbind, the component of Samba that
automatically creates UNIX accounts on-the-fly, and maps them to
Windows accounts.
Discuss the reasons and alternatives for using Winbind
List the Winbind components
Configure Winbind
Configure autocreation of home directories
Accountability:
Student Notebook
Notes:
Unit Objectives
Discuss the reasons and alternatives for using Winbind
List the Winbind components
Configure Winbind
Configure autocreation of home directories
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 10-2. Domain Member Challenge LX265.0
Notes:
So far weve discussed standalone servers and domain controllers based on Samba. In
both cases weve seen that Samba needs both a UNIX account (typically stored in
/etc/passwd and friends, or in a backend such as NIS or LDAP) and Windows account data
(typically stored in /etc/samba/smbpasswd or another SAM such as LDAP) to function.
A Samba-based domain member has this same problem: It needs UNIX and Windows
account data. The Windows account data, obviously, is provided by the Windows- or
Samba-based Domain Controller, but what about the UNIX account data? There are a
number of ways in which you can obtain this.
The first approach is by making sure you dont need UNIX account data at all. This is
possible by only allowing guest accounts on your system, with guest only = true, or forcing
a specific UNIX user account to be used, with force user = <user>. Obviously, in the last
case, that single UNIX account has to exist on your system.
The second approach is to create all UNIX account data manually on each domain
member. This is very cumbersome in large installations, but may just be the easiest
solution for small environments.
Domain Member ChaIIenge
A Samba-based Domain Member retrieves all Windows
Authentication data from the Domain Controller
...but, for Samba to work properly, it also needs a UNX account to
setuid() to
Approach 1: Make sure UNX accounts are not needed, for instance
through guest onIy = true or force user = <username>
Approach 2: Create UNX accounts for all users manually on each
Samba-based domain member
Approach 3: Let Samba-based domain members use a UNX
authentication backend such as NS or LDAP
Approach 4: Use Winbind to create UNX accounts on-the-fly
These UNX accounts are called DOMAN+Username
Student Notebook
The third approach is to use a UNIX authentication backend such as NIS or LDAP. When
using LDAP, you can even combine this with Windows authentication data stored in LDAP
as well, as weve seen in the previous unit. But if your Domain Controller is not
Samba-based but a regular Window system, this is not going to work.
The last approach, which were going to cover in this unit, is to use Winbind. Winbind
creates UNIX accounts on the fly, when they are needed. These UNIX accounts are called
DOMAIN+Username, and the mapping of such a username to a UID is retained for the next
time.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 10-3. Winbind Components LX265.0
Notes:
The Winbind system consists of four important components.
The first component is the Winbind daemon, winbindd. Although part of the Samba suite,
and configurable through smb.conf, it runs completely separate from nmbd and smbd.
The second component is /lib/security/pam_winbind.so. This PAM library hooks into the
PAM subsystem so that PAM uses Winbind to authenticate a user, and to create an
account mapping, if needed.
The third component is /lib/libnss_winbind.so. This NSS library hooks into the NSS
subsystem so that programs such as getent, id, who and ls -l will get the correct UNIX
account data from Winbind.
The last component is the file /var/cache/samba/winbindd_idmap.tdb. In this file,
Winbind stores the dynamic mapping of Windows accounts to UNIX UIDs for the future.
This file is very important: if you lose it, all the mapping that has been done on your local
system is lost. So make sure to incorporate this file into your backup scheme and
everything.
Winbind Components
winbindd: Separate daemon, runs independently of smbd and
nmbd
Configuration file smb.conf
/Iib/security/pam_winbind.so: PAM module which integrates into
PAM subsystem so PAM uses Winbind to create account mapping if
needed
/Iib/Iibnss_winbind.so: NSS library which integrates into NSS
subsystem so NSS uses Winbind to retrieve account mapping if
needed
/var/cache/samba/winbindd_idmap.tdb: File in which the dynamic
mapping is retained for the future
DO NOT LOSE THS FLE!
This information can also be stored in LDAP (Not covered in this
course)
Student Notebook
It is possible to store the Winbind mapping information in LDAP as well, through the use of
the idmap backend directive. This is not covered in this course however. Read the Samba
documentation for details.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 10-4. Winbind Ecosystem LX265.0
Notes:
The visual shows the Winbind ecosystem. You can see that both NSS and PAM have two
sources (at least) of UNIX account information: The regular UNIX files /etc/passwd and
friends, and the Winbind daemon. The Winbind daemon itself retrieves its configuration
from smb.conf, and stores the mapping it uses in winbindd_idmap.tdb (or another idmap
backend, if configured).
Winbind Ecosystem
Winbind daemon
NSS
Subsystem
PAM
Subsystem
/etc/passwd
& friends
smb.conf
winbindd_idmap.tdb
libnss_files.so libnss_winbind.so
pam_unix.so
pam_winbind.so
Student Notebook
Figure 10-5. Configure Winbind LX265.0
Notes:
To configure Winbind, you first need to make Samba a member of a Windows NT/2000
domain. After all, if Samba is not a member of a domain, where is the Windows account
data coming from?
Then, configure your smb.conf file with the following directives. Note that these directives
are only used by the winbindd daemon, not by nmbd or smbd.
The winbind separator is the character that separates the domain name from the
username. A good choice (used in this course) is the + character. However, there might be
an issue if you use NIS as well, since the + is a reserved character for NIS in your
/etc/passwd file. Another popular choice is the backslash, which is used within Windows as
well. The disadvantage of using the backslash is that it needs to be escaped almost
everywhere, since it is a reserved character for the bash shell. Whatever winbind separator
you use, make sure that you make a choice and stick to it, since this character will be used
everywhere.
The idmap uid and idmap gid parameters identify the ranges that Winbind can use for its
dynamic mapping. Make sure that these ranges are large enough to handle all your
Configuring Winbind
Samba needs to be member of a Windows NT/2000 domain
Add smb.conf [global] options:
winbind separator = +
idmap uid = 15000-20000
idmap gid = 15000-20000
tempIate homedir = /home/%D+%U
tempIate sheII = /bin/bash
Stop and disable the nscd daemon (if running)
Start winbindd daemon
Verify correct operation using wbinfo and getent:
wbinfo --set-auth-user=Administrator%password sets the
domain administrator to use
wbinfo -u: List all Winbind user accounts
wbinfo -g: List all Winbind groups
Student Notebook
V1.2.2 BKM2MIF
Uempty
Windows users, and that these ranges do not overlap (now or in the future) with the UIDs
and GIDs of real UNIX accounts.
You can also specify a template homedir and a template shell. These templates are used
if any application asks the NSS/PAM subsystems for this information. After all, this
information is normally stored in /etc/passwd.
The next important thing is to check that the nscd daemon is not running. This Name
Services Caching Daemon is often confused with a Caching-Only Name Server, but in
reality it has nothing to do with DNS at all. Instead, it caches responses that are obtained
by the NSS subsystem from, for instance NIS servers so that network traffic is reduced in
case users execute, for instance, the ls -l command
1
. The nscd daemon however conflicts
with the Winbind daemon and should therefore be turned off.
Now you can start the Winbind daemon and test it. Testing is done using the commands
wbinfo -u, which lists all Winbind user accounts, and wbinfo -g, which lists all Winbind
group accounts.
Winbind does require access to the domain to be able to enumerate all domain users. In a
Windows NT domain, or in a Windows 2000 domain with restrict anonymous turned off,
this is no problem. In a Windows 2000 domain with restrict anonymous turned on
however, Winbind needs to logon as regular user to the Domain Controller to do this. This
is because the anonymous user is not allowed to enumerate all domain users when
restrict anonymous is turned on. Logging on as a regular user is achieved by setting the
user account and password to use with wbinfo --set-auth-user.
1
If a user executes ls -l, then the ls command will obtain the UID and GID of the owner/group from the inode. It then goes through the
NSS subsystem to obtain the user- and groupname belonging to this UID and GID. Without the nscd daemon, this would mean two
network requests for each and every file in your directory. Not efficient...
Student Notebook
Figure 10-6. Configure NSS and PAM LX265.0
Notes:
The last step in configuring Winbind is to modify your NSS and PAM configuration to use
Winbind. Note that Winbind is going to be used in addition to the existing authentication
schemes, not replace it.
For NSS, modify the /etc/nsswitch.conf file. Locate the passwd and group lines and add
winbind to these lines. This will make sure that the NSS subsystem also uses Winbind if
an account cannot be found in the regular files /etc/passwd and /etc/group.
Once you changed your NSS subsystem, you should be able to use like getent, id, who
and ls -l to obtain the DOMAIN+Username accounts.
For PAM, you need to add the pam_winbind.so module to all relevant PAM files. Which
files exactly depend on the distribution you use, and how extensively you want PAM to use
Winbind. As an example, if you want users to interactively logon to your Samba system
with their DOMAIN+Username account name, then you need to modify the
/etc/pam.d/logon configuration file.
Configure NSS and PAM
NSS: Modify /etc/nsswitch.conf
passwd: files winbind
shadow: files
group: files winbind
Verify NSS: getent passwd and getent group should now list the
additional DOMAN+User and DOMAN+Group accounts
PAM: Add pam_winbind.so to all relevant PAM files
Depends on distribution, e.g. Red Hat /etc/pam.d/system-auth:
auth sufficient /Iib/security/$ISA/pam_winbind.so
Verify PAM: Login as DOMAN+User on free virtual terminal
Note: Do not use authconfig, yast or other tools that modify NSS
and PAM afterwards anymore
Student Notebook
V1.2.2 BKM2MIF
Uempty
The change is easiest on Red Hat and Fedora, which both use pam_stack.so in almost all
PAM configuration files to point to the file /etc/pam.d/system-auth. A change in this last file
means that all other subsystems are automatically configured too. The change required is
thus limited to adding the pam_winbind.so to that file. The file will then look like this
(changes in bold):
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_winbind.so
auth sufficient /lib/security/%ISA/pam_unix.so likeauth nullok \
use_first_pass
The use_first_pass directive which is added to the pam_unix.so line means that
pam_unix.so should use the password that the user entered when pam_winbind.so asked
for it. Without this option, the user will need to enter his password twice.
You can also change the order, where pam_unix is evaluated first and pam_winbind
second. In this case, pam_winbind needs the use_first_pass option.
Once you configured PAM, you can verify that things work correctly by logging on as
DOMAIN+Username on a free virtual terminal. Again, when doing this, do not logoff your
root session in case you made mistake in your PAM configuration.
One thing to remember is that once you made manual changes to /etc/nsswitch.conf or
your PAM configuration, you should not use tools like authconfig or yast anymore to make
changes to the NSS or PAM subsystems.
Student Notebook
Figure 10-7. Automatic Creation of Home Directories LX265.0
Notes:
If you log in interactively to your Samba server as DOMAIN+Username, you will notice that
you will get a warning Home directory does not exist. This is because Winbind does not
automatically set up a home directory for the DOMAIN+Username users. In most cases,
this home directory is not required, particularly if your users access your system only via
Samba, and this Samba server does not share the home directories.
However, in certain circumstances, it might be beneficial to automatically create home
directories for these Winbind-managed accounts. This is then done through the
pam_mkhomedir.so library. As before, this is simply added to all relevant PAM files.
There is one catch here, however: Samba, by default, does not use PAM. The reason for
this is the encrypted passwords, which Samba in any case needs to encrypt and verify
itself, because the PAM subsystem does not know about the way Windows encrypts its
passwords. Thus, using PAM does not add any value to Samba.
To force Samba to use PAM anyway (with the obvious encrypted passwords lookups), set
obey pam restrictions = yes. This forces Samba to obey all pam restrictions, and this in
Automatic Creation of Home Directories
n some cases it might be useful to create a home directory for a
winbind-created account automatically
This can be done with the pam_mkhomedir.so module
Samba by default does not use PAM due to encrypted passwords.
To force use of PAM for session and account phase, modify
smb.conf:
obey pam restrictions = yes
Add pam_mkhomedir.so to all relevant PAM files, for example,
Red Hat /etc/pam.d/system-auth:
session required /Iib/security/$ISA/pam_mkhomedir.so \
skeI=/etc/skeI umask=0077
Student Notebook
V1.2.2 BKM2MIF
Uempty
turn means that pam_mkhomedir.so is activated automatically if a user accesses the
system through Samba, but without a home directory on the system.
Student Notebook
Notes:
1.
2.
3.
Checkpoint
1. T/F. Winbind is always required on a domain member server.
2. What are the Winbind components?
_____________________________________________
_____________________________________________
_____________________________________________
3. What are the steps to automatically create home directories?
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
A server makes resources (called shares) available to clients on the network. Clients find
those shares by browsing the network. Browse lists are created by the Local Master
Browser for each network segment, since browse information is broadcast and
broadcasting doesn't span network segments. Then all of the LMBs get together and send
their information to a Domain Master Browser (this domain has nothing to do with a
security domain). The DMB then relays the information back to other LMBs on other
segments so that the entire network is kept up to date. The biggest problem with this
scheme is that it doesn't scale well when you've got hundreds or thousands of Windows
clients.
Once a server name is found from the browse lists, it has to be converted into an IP
address so that a conversation can take place. This can be done only partly by DNS,
because DNS doesn't store name_type information needed by the SMB protocol. So
something called WINS is used instead. Samba can be a WINS server, or an NT machine
can take that role.
Unit Summary
Domain member challenge
Winbind concepts
Winbind components
Configuration of Winbind
Configuration of NSS and PAM for Winbind
Configuration of pam_mkhomedir.so
Student Notebook
Clients can be authenticated in either share mode or user mode. These were discussed
previously in the unit on file sharing. This unit covered setting up Samba as a client in an
NT Domain.
Batch scripts and user preferences can be stored on a server to be automatically
downloaded when the user logs on to a server.
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 11. Configuring Samba Using SWAT 11-1
V1.2.2 BKM2MIF
Uempty
Unit 11. Configuring Samba Using SWAT
This unit shows how to configure Samba using a graphical tool.
Discuss SWAT
Show how SWAT is used
Describe what SWAT can do for you
Configure [x]inetd to support SWAT
Accountability:
Lab Exercises
Student Notebook
Notes:
Unit Objectives
Discuss SWAT
Show how SWAT is used
Describe what SWAT can do for you
Configure [x]inetd to support SWAT
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 11-2. Samba Web Administration Tool LX265.0
Notes:
GUI interfaces are generally regarded as being more of a hand-holding strategy to using a
tool. By providing a simple and easier-to-use interface, the user can get the job done more
quickly. In the case of SWAT, this is definitely true. It is not that the GUI provides any great
amount of functionality; it merely integrates the configuration environment behind a Web
browser. Help is just a hyperlink away, directly into the online documentation. The interface
is cleaner, with hard-coded choices for those parameters that require them (such as yes/no
or true/false parameters).
Because the configuration is done through a Web browser, Samba can be configured from
afar and in a system-independent fashion. There is no need to learn vi just to edit the
smb.conf file.
And the interface can configure both basic and advanced features of Samba, so that a
beginning administrator can deal with the simple stuff first and get the shares up and
running, then come back to the configuration later and fine-tune it.
Samba Web Administration TooI
HTTP Engine for maintaining your Samba server
smb.conf
Various other Samba files
List status of Samba daemons
Start/Stop/Restart Samba daemons
List active connections
Can be accessed with any normal browser such as Netscape,
Konqueror, Lynx, MS E
Runs out of [x]inetd, TCP port 901
Student Notebook
Figure 11-3. What Can SWAT Do For You? LX265.0
Notes:
SWAT controls access to the modification of a smb.conf file by requiring the users to
authenticate themselves. When you connect to a SWAT home page, you'll be asked for
your user ID and password. If your user ID is root and your password is correct for the
Linux machine that SWAT is running on, you'll have the option of modifying values instead
of only displaying the current contents.
Every global parameter can be modified through SWAT. The big advantage is that they are
grouped by functionality on the SWAT page and there are links directly into the online help
documentation, should the exact details of a parameter be needed.
SWAT can configure both disk shares and printers. It can configure the default homes
share and the default printers share, although typically, the highest usage will come from
adding new disk shares.
In addition, SWAT has a status link which provides a snapshot view of what the server is
doing at the time the snapshot is taken. It reports on the number of active sessions, where
those sessions connected from, and much more.
What Can SWAT Do For You?
Adjust any and every global parameter
Configure disk space shares
Configure printer shares
View status of the current server daemons
View the configuration file in raw format
Manage passwords, both administrator and user
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 11-4. SWAT Home Page LX265.0
Notes:
As soon as you point your Web browser to http://localhost:901, you are prompted for a
username and password. Login as root and you will be presented with the SWAT Home
Page. From this page, you can access the various manual pages for Samba directly, and
you can go to various configuration screens.
SWAT Home Page
Student Notebook
Figure 11-5. SWAT Globals Page LX265.0
Notes:
Notice how the various parameters are grouped into categories. This makes it significantly
easier to configure various aspects of the server.
Also, you will notice that all fields have a Set Default button which puts the default value for
the field into the input box. This is interpreted to mean the default value for SWAT, not the
Samba server. Usually, it just empties out the field completely.
Another thing that is useful is the button advanced view. When you retrieve the globals
page, only the most common global options are visible. When you click on advanced
view, ALL global options are shown, even the ones that you do not even want to know
about!
SWAT GIobaIs Page
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 11-6. SWAT Shares Page LX265.0
Notes:
This is the starting point page for adding or modifying a share. If you choose an existing
share from the name to drop-down listbox and click Choose Share, the specifics for that
share will be displayed (next slide).
If you instead choose an existing share from the drop-down listbox and click Delete Share,
then the share configuration will be removed from the configuration file.
Lastly, you can type in the name of a new share that you want to create and click Create
Share. This will create a new share and display the share editing screen (next slide).
The top of the browser page shows the links to the various sections of the SWAT Web site.
SWAT Shares Page
Student Notebook
Figure 11-7. SWAT Status Page LX265.0
Notes:
This screen shows the current activity of the Samba server. It has an option to let itself
refresh every n seconds, so you can just keep this running somewhere in the background
to get a quick overview on what Samba is doing.
SWAT Status Page
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 11-8. What SWAT Cannot Do LX265.0
Notes:
The SWAT tool will not analyze your choices to make recommendations. It doesn't verify
that the list of user names that you put into the users parameter are actual Linux user
names (you may put names there and not have created the Linux names yet). It is only as
secure as your network browser, since it doesn't communicate using https. That means that
the authentication that happens at the beginning of the session is passed over the network
as plaintext.
And there is some configuration involved. You will need a browser for the interface,
although even a text-based browser such as lynx works just fine. And it requires that you
tweak the /etc/inetd.conf file or create an /etc/xinetd.d/swat file, depending on whether
your distribution uses inetd or xinetd. Most distributions configure SWAT automatically
when the RPM is installed.
What SWAT Cannot Do
Will not make recommendations
Will not warn about incompatible or nonsense combinations of
parameters
Does not verify the contents of most user-defined fields
s only as secure as a normal http connection
Student Notebook
Figure 11-9. Configuring [x]inetd to Support SWAT LX265.0
Notes:
There's not really a whole lot to configuring SWAT, since it runs out of [x]inetd.
If your distribution uses the inetd daemon, you need to edit the /etc/inetd.conf file and
tell inetd how to invoke SWAT when someone visits the interface port. That would be
done using a Web address like http://localhost:901/ from within a Web browser.
Add the line shown above at the end of the file. You may want to check first and see if it
has already been added. If it is already there, just make sure it is uncommented.
The first field of the inetd.conf file is a cross-reference to the /etc/services file. It would
be wise to check over there and make sure that the string SWAT showed up in column
one somewhere in that file.
Then just restart the inetd server. The easiest way is probably to use:
/etc/rc.d/init.d/inet restart
That shell script will locate the pid of the server and send it a HUP signal. If it can't find
the server, you will be notified.
Configuring [x]inetd to Support SWAT
f your distribution uses inetd:
Add the following line at the bottom of /etc/inetd.conf:
swat stream tcp nowait.400 root /usr/bin/swat swat
Restart the inetd server
f your distribution uses xinetd:
Change "disable = yes" into "disable = no" in /etc/xinetd.d/swat
(or: chkconfig swat on)
Might want to modify the "only_from" parameter in that same file
Restart the xinetd server
Student Notebook
V1.2.2 BKM2MIF
Uempty
If your distribution uses xinetd, then the process is even simpler. SWAT, when installed
from RPM, will put a file in /etc/xinetd.d, which contains the xinetd configuration for
SWAT. The only thing you need to do is enable it, because it is disabled by default. This
can be done by manually editing the file, or by running the command chkconfig swat
on.
After this, restart xinetd.
Student Notebook
Notes:
1.
2.
3.
Checkpoint
1. T/F. SWAT can configure both disk shares and printer share.
2. T/F. SWAT will check the contents of related parameters to ensure
that they do not contain contradictory or conflicting values.
3. n order to connect to SWAT via a Web browser, the
_______________________ file in the /etc directory must be
configured first.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
A graphical interface can significantly shorten the amount of time required to configure
Samba simply because it coordinates the editing activities, and groups parameters by
function.
However, a graphical interface is often not as powerful as a command line interface. For
example, how can you compare two smb.conf files to determine if they are essentially the
same (ignoring any comments)? If the GUI tool doesn't have such a solution built in, then
you are out of luck. But from the command line, it's simple enough to run testparm against
each configuration file and save the results. Then use diff to compare the two results.
Keep in mind that SWAT can shorten the time needed to configure Samba, but it doesn't
replace the need to understand what is going on behind the scenes.
Unit Summary
What is a GU interface good for?
Why use SWAT? -- what do you gain?
How do you configure SWAT?
Student Notebook
Student Notebook
Copyright IBM Corp. 1999, 2005 Unit 12. Tips and Techniques 12-1
V1.2.2 BKM2MIF
Uempty
Unit 12. Tips and Techniques
This unit summarizes various recommendations that have been made
throughout the course, as well as presenting new techniques for
diagnosing problems.
Understand upcoming Samba enhancements and features
Summarize performance issues
Review security issues
Provide techniques for diagnosing problems
Accountability:
References
WHATSNEW.txt Samba text documentation
DIAGNOSIS.txt Samba text documentation
Student Notebook
Notes:
Unit Objectives
Understand upcoming Samba enhancements and features
Summarize performance issues
Review security issues
Provide techniques for diagnosing problems
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-2. Performance Issues LX265.0
Notes:
Obviously, the solution to most performance issues is to buy a faster box. We would like
to present some ideas for what a typical box might be. Your mileage may vary.
Hardware: The faster the CPU, the faster the programs that run on that CPU, right? Not
necessarily. If an application is not CPU-bound, but is more I/O-bound (as Samba is in
most environments) then a faster CPU probably won't have the effect of speeding up your
server by the percentage difference in CPU speeds. For example, going from a 200 MHz
CPU to a 300 MHz CPU, you would expect a 50% increase in speed; programs that used
to take 3 minutes should now take 2 minutes. Unfortunately, that's not very realistic.
Memory availability is a large factor in performance, specifically cache size, and how
quickly a program can read its data from a disk or network has a definite impact.
The Samba server is typically not CPU-bound. Instead, most of its time is spent I/O-bound,
mostly to the network. Therefore, most performance gains will be realized by tuning your
TCP/IP stack. However, there are certain things that can be done in the server itself.
The default value for oplocks is on, and it is unlikely that you would want to turn
opportunistic locking off, since it allows clients to cache file access operations locally.
Performance Issues
Linux hardware
Linux Samba
opIocks and fake opIocks
socket options
read size
max xmit
Iog IeveI and debug IeveI
wide Iinks
read raw and write raw
Client setup
Student Notebook
Turning it off will likely cause a 30% or more slowdown in NetBench results, possibly more
in a real application environment situation. (Visit www.mindcraft.com/benchmarks/ for
links to various benchmarks.) The old fake oplocks parameter from pre-1.9.18 Samba is
deprecated and should not be used. However, setting fake oplocks = yes tells the server
to inform all clients that they can obtain an oplock. This can be of big benefit on read only
shares or shares which can guarantee that only a single client will be accessing them at a
time.
Many Samba users have reported that setting socket options = TCP_NODELAY results in
read times being cut in half. The best explanation seen for this is that the Microsoft TCP/IP
stack is slow in sending TCP ACKs.
Very little experimentation has been done with read size, which is used to control the size
of reads to and from disk and network devices. Proper adjustment will result in overlapping
I/O requests between the network and the disk and could conceivably speed things up
considerably. However, this parameter is likely to be very system-dependent (network card,
drivers used, disk type, disk drivers, adapter drivers, system memory available, bus type,
and so on).
The max xmit parameter controls how large a packet Samba should try to negotiate with
the client when the client connects. It defaults to 65536 bytes, although it is likely that
different clients will perform better with other sizes. Experimentation with your client
software on your network is required to know for sure.
Log levels (or debug level in the smb.conf file) higher than 2 will severely slow down the
server and should only be used for debugging. The slowdown is because the server does a
buffer flush on the log file after each output operation in case the server should crash (this
is debugging information, after all).
If you disable wide links (ignoring symbolic link checks is enabled by default) for security
purposes, the server must perform extra checking on file types. This will slow the server
down a bit, although having the getwd cache turned on will help somewhat (on by default).
You might try turning off read raw in the server. It seems that some clients are actually
slower when performing raw reads, presumably because they've been optimized for normal
file reads. Only experimentation will tell whether it's faster or slower for your network. The
same applies to write raw.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-3. Security Concerns LX265.0
Notes:
On the topic of security, what kind of security is there? I mean, we can make sure that the
Samba server is secure -- is that enough?
First, we can make our Linux systems secure by setting permissions on files and
directories correctly, requiring each user to have their own username and password,
requiring good passwords by doing dictionary checks and implementing password aging,
and so on. Samba will not provide more privileges than the host operating system does for
the user who has made contact with the server. So, if you create a share read-write and
Joe can't write there, the problem is likely the Linux permissions.
Second, network security is a little out of our scope, but there are a variety of problems
there. Handing around passwords in clear text, transmitting file data in clear text,
masquerading as another machine by using its IP or MAC address, by flooding a machine
with bad packets so that it can't process the packets of legitimate users, and so on. For
correcting these kinds of issues, you will need to visit a networking specialist; take a
TCP/IP class to find out more about network attacks.
Security Concerns
Samba shares versus Linux directory permissions
Encrypted passwords and password synchronization
Using hosts aIIow and hosts deny
Trusted Domains
nterdomain Trusted Accounts
Student Notebook
Third, securing the client is one of the most difficult parts of the picture. Windows likes to
think that it is friendly, but it isn't too friendly to the security auditor whose job it is to make
sure that unauthorized access hasn't been granted. Many Windows utilities and
applications don't create any logs of incoming or outgoing requests for files or data. This is
also outside the scope of a course on Samba.
So, what can we do with our Samba server? Let's review the possibilities:
Encrypted passwords. This is a good idea simply because modern releases of Windows
NT will refuse to talk to Samba otherwise.
UNIX password synchronization. Probably another good idea, since it allows users to
keep a single password for both the client and the Linux machine.
Samba has two parameters that can restrict access to the server based on host name or IP
address information. They are hosts allow and hosts deny. The general format of these
parameters is the same as the hosts.access(5) from the tcpwrapper package. A brief
description is that the IP address and netmask can be specified for either of these
parameters, and in fact, a list of such pairs can be provided. This means the administrator
can carefully craft the host access list to the server. For internal networks, hosts deny =
NONE and hosts allow = ALL might be sufficient. For Internet connected machines,
something like hosts deny = ALL and hosts allow = a.b.c.d/netmask might be more
appropriate, where a.b.c.d/netmask represents the range of IP addresses allocated to
your internal network. Of course, it couldn't hurt to set that up even on an internal network.
Samba can now participate in Windows NT security domain management, in the form of
having an entry in the NT machine account database. This also means, then, that a Samba
server can be part of a trusted domain and can provide user accounts which are trusted
independently as well.
Packet encryption of SMB data across a network is not supported at the SMB layer.
However, it should be possible to implement it at the TCP layer of the protocol. Whether
this is a good idea or not depends on the implementation. See Cheswick and Bellovin's
Firewalls and Internet Security, Addison-Wesley, and Stallings and Stephenson's
Implementing Internet Security, New Riders Publishing, for additional details.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-4. Problem Determination LX265.0
Notes:
Problem determination, in its simplest form, is simply locating what is causing a particular
problem. Implementing the solution may be a larger task.
Over the next few graphics, you will see a series of steps which will quickly allow you to
track down problems and obtain a list of possible solutions. This series of steps is useful in
real-world problem isolation.
However, there are some assumptions made about these steps.
First, the Linux machine running the Samba server that you are testing is called SSERV, for
Samba SERVer. We also assume that there's a Windows client which goes by the name
WCLIENT. The Windows client can be Windows 95, Windows 98, or Windows NT 4.0 or
later, running a Microsoft TCP/IP protocol stack. It must NOT have NetBIOS over IPX
installed. (This will cause problems with browse master elections as already detailed earlier
in the course.)
ProbIem Determination
Series of tests
Assumptions before running the tests
These tests are order-dependent
Student Notebook
The SSERV machine will need a share called tmp. If you don't have one, we suggest you
use the following smb.conf configuration to create one:
[tmp]
path = /tmp
writable = no
comment = Temporary space
If you have to add such a share, be sure to restart the server.
As you proceed through these tests, pay close attention to any error messages you
receive. If any of these tests report that your server is being unfriendly, you should first
check that your IP name resolution is correctly set up. For example, make sure that your
/etc/resolv.conf file points to valid name servers and that the /etc/nsswitch.conf has the
correct entries. See the DNS documentation and man pages for details. If you are not using
DNS for name resolution, make sure dns proxy = no appears in your smb.conf file. Use
testparm liberally and often to verify your configuration file.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-5. Test 1 Syntax of smb.conf LX265.0
Notes:
The testparm command should be used to verify the contents of the smb.conf file at all
times. It is too easy for a typo to go unnoticed in the configuration file. This is less likely
when SWAT is used, but the contents of the fields can still contain errors, and unless you
are looking at all of the possible parameters, you may not catch the fact that the values of
some parameters are interrelated.
The purpose of having you change directory and then provide a filename on the command
line is so that testparm doesn't grab a smb.conf from directory X when you're editing the
file in directory Y -- you'd never know. If you run testparm without any parameters, it will tell
you where it's reading the configuration file from. You can use this information to verify that
you're editing the correct file.
Test 1 - Syntax of smb.conf
Change to the directory containing the smb.conf
Execute the following command:
testparm smb.conf
f it reports any errors, the smb.conf is faulty
Student Notebook
Figure 12-6. Test 2 Network Connectivity LX265.0
Notes:
In order to run the ping command from the client, you will likely need to open a DOS
prompt window. Some application suites also include a ping command, such as the
Hummingbird eXceed package; you may use that version, if you like.
Ping is a very simple low-level command. It just sends out ICMP ECHO messages over the
wire and checks to see if they return back. If this doesn't work, there's a basic configuration
problem with the TCP/IP stack on the client.
If you get no route to host or host unreachable, then you may be on a separate subnet
that requires a router to forward packets and that router isn't forwarding ping packets. You'll
have to adjust the configuration of the router in this case. The odds are good that if the
router isn't passing ping packets, it probably won't pass other packets either.
If you get host not found or similar messages, your name resolution isn't working. Check
the DNS settings on the client in the Network Neighborhood Properties and check the
TCP/IP properties, the DNS tab, to see if DNS is correctly configured. Contact your network
administrator for the proper values.
Test 2 - Network Connectivity
Run the following command from the client:
Ping SSERV
You may have to open a DOS window to run ping
f you don't get a valid response, then your TCP/P is not configured
properly
Host not found means name resolution isn't working. Check:
/etc/hosts
/etc/resoIv.conf
/etc/nsswitch.conf
Could be behind a firewall
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-7. Test 3 Connect to the Samba Server LX265.0
Notes:
If the smbclient command can't connect to the server, there's a basic configuration
problem.
Bad password might mean an incorrect host configuration (Samba won't allow access), or
that the guest account is not a valid username (the guest account is used to access the
browse list on the server, because the information is public).
Connection refused means that no one is listening on the port, so check that smbd is
running. If smbd does appear to be running, check the hosts allow setting. At a minimum,
it should have the loopback device (which is what you are testing by running smbclient on
the Linux machine) such as hosts allow = a.b.c.d/yy 127.0.0.1. The value of yy should be
the number of bits in the netmask (such as 24 for a Class C address).
The problem could also be that another application is already listening on port 139 and so
Samba can't use that port. You can use netstat -a to verify this.
Test 3 - Connect to the Samba Server
Run the following command on the Linux box:
smbcIient -L SSERV
f you get a bad password error, it could be:
ncorrect hosts.aIIow, hosts.deny files,
nvalid vaIid users parameter in smb.conf
nvalid guest account parameter in smb.conf
f you get a connection refused error, the smbd service is not
running
Check with service smbd status or ps -ef | grep smbd
f you get a server software is not being friendIy error,
Check the command line parameters to smbd
Use testparm and verify log and spool directories
Student Notebook
Last, you can check the log.nmb log file, probably located in /usr/local/samba/var, to see
what IP address, broadcast address, and subnet mask were used by SSERV when the
name lookup daemon started. Run testparm to verify that they're the same.
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-8. Test 4 Samba's Name Lookup LX265.0
Notes:
This test checks the configuration of the nmbd daemon, the one responsible for doing
name-to-address translations.
Test 4 - Samba's Name Lookup
Run the following command on the Linux box
nmbIookup -B SSERV __SAMBA__
You should get the P address of your Samba server displayed.
f you don't, then nmbd is incorrectly installed.
Check your inetd.conf if you run it from there
Check that the daemon is running if you start it somewhere else
Student Notebook
Figure 12-9. Test 5 Client Response to Name Lookup LX265.0
Notes:
If the nmblookup fails, then the client isn't responding to the request for name translation.
The client software isn't configured correctly, the machine or software isn't up and running,
or the client name you used in the command is misspelled.
Test 5 - CIient Response to Name Lookup
nmbIookup -B WCLIENT '*'
You should get the client's P address displayed
f you don't, then
The client software is not set up correctly,
The software is not running, or
The client name is misspelled
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-10. Test 6 Client Response to Broadcast LX265.0
Notes:
If the client and server are not on the same subnet, the broadcast won't work. You'll have to
add the -B option to the command to set the broadcast address to the client's subnet value.
This test will likely fail if your subnet mask and broadcast address are not correct. Refer to
the results of Test 3 also.
Test 6 - CIient Response to Broadcast
nmbIookup -d 2 '*'
This is the same as test 5, but uses a broadcast
A number of NetBOS-over-TCP/P hosts should respond
You should see "got a positive name query response"
f this doesn't work, experiment with the
Interfaces parameter re: IP address, broadcast address, and
netmask
Student Notebook
Figure 12-11. Test 7 Session Configuration LX265.0
Notes:
If the smbclient command prompts for a password, enter the one for your current user
name. When successful, the smbclient prompt is smb> If you get that prompt, quit
smbclient by typing the quit command and pressing <Enter>.
Carefully consider the options listed above if you get a bad password response. The last
is particularly important if you're trying to coexist with a Windows NT 4.0 SP3+ network
where Windows NT requires encrypted passwords. You may have enabled them without
setting up all the details. See the unit on File Sharing for the details on user mode access to
shares.
The note on mixed-case passwords doesn't apply if you are using encrypted passwords.
Test 7 - Session Configuration
smbcIient '\\SSERV\tmp'
Enter the password of your current account
Test other accounts by adding -U accountname
f the error is invaIid network name, then
The tmp share is not set up correctly
f the error is bad password, the likely causes are:
shadow passwords enabled, but not compiled
vaIid users parameter is incorrect
You have a mixed-case password and password IeveI is too
small
The path of the tmp share is incorrect
encrypted passwords are enabled, but smbpasswd does not
exist
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-12. Test 8 Client's Name Lookup LX265.0
Notes:
You will need to open a DOS prompt window in order to run net view. Once again, some
application suites will have similar programs which won't require a DOS window.
Keep in mind that the name used to connect to SSERV will be the name you used to log on
to the Windows client. You will need to have a corresponding user account on the Linux
machine in order for this to work. Also, the password will have to be the same. The case
can differ in the passwords, but then the password level parameter needs to be set
appropriately in the smb.conf file.
If the error is specified host is not receiving requests, it means there is a listener on the
port, but they didn't want to talk to you. This is probably because some kind of port
monitoring software has connection requests from your client turned off. On Linux
machines, this is likely the tcpwrapper package.
Test 8 - CIient's Name Lookup
Run the following command on the Windows client
net view \\SSERV
You should get a list of shares on that server
f you get a network name not found error, then NetBOS name
resolution isn't working
Check the nmbd installation (command line and such)
Configure the client to use a WINS server
Enable DNS lookup on the client
Add SSERV to the Imhosts file on the client
f you get an invaIid network name or bad password error, refer to
Test 3 for appropriate solutions
Student Notebook
Figure 12-13. Test 9 User Authentication LX265.0
Notes:
Once again, you will need a DOS window for this command.
Older software, such as Windows for Workgroups, does not send the user name during
session startup, so it is possible that the server does not know who you are. You can
hard-code the smb.conf with your user name and try the test again. If it now works, then
this is the problem. Unfortunately, if this is the problem, the solution is not pretty. You can
either upgrade the software on the client (a good idea anyway), or allow guest access on
the server via guest ok = yes. This means that all access to the data in the share will be as
the guest account.
Test 9 - User Authentication
Run the following command on the client
net use X: \\SSERV\tmp
Enter your password
f you don't get command compIeted successfuIIy, there was a
problem
Check the TCP/P settings on the client
Check the smb.conf file for the hosts aIIow and hosts deny
parameters
t is possible the server can't figure out who you are
Add user = USERNAME to the tmp share, where USERNAME is
your username.
Restart the Samba server (smbd in particular)
Student Notebook
V1.2.2 BKM2MIF
Uempty
Figure 12-14. Test 10 Full Package LX265.0
Notes:
Linux distributions typically have the encrypted passwords support already compiled, so
you'll probably just have to turn them on in the configuration file. If not, however, you'll need
to refer back to the Installation unit to determine the requirements for source code
compilation.
Test 10 - FuII Package
From the Windows file manager, try to browse the server.
f you get invaIid password,
You are probably running Windows NT 4.0 SP3+ and aren't using
encrypted passwords
Either set
security = server
password server = Win_NT_Machine
Or compile in support for encrypted passwords and
encrypted passwords = yes
Student Notebook
Figure 12-15. Still Having Trouble? LX265.0
Notes:
There is not much else to do at this point. It is possible that your software has been
upgraded beyond the level used to write this material and that the protocols have changed
to add some new feature that breaks existing code.
You can use tcpdump-smb to sniff out SMB packets on the network between two known
working systems and then compare those packets with the dialogue between the machines
giving you the problems. This information can be used by the Samba development team to
help write patched code, and you may discover the problem yourself by just examining the
packet contents.
You can also browse through the /usr/doc/samba-*/docs hierarchy looking at the various
documentation. The textdocs subdirectory contains a file called DIAGNOSIS.txt which
was used in the generation of this portion of the unit. That document may well be more
up-to-date than this material, especially if there's been a recent release of the Samba
package.
You can visit http://www.samba.org/samba/ for more information, or join the mailing list at
samba@samba.org.
StiII Having TroubIe?
Try using tcpdump-smb to sniff out the problem (packet viewer)
Look at /usr/doc/samba-x.y.z/docs/textdocs
Visit http://www.samba.org/samba for more information
Subscribe to the Samba mailing list at samba@samba.org
Student Notebook
V1.2.2 BKM2MIF
Uempty
Notes:
Checkpoint
1. T/F. f you double the speed of the CPU, the performance of
Samba also doubles.
2. The SMB protocol supports encrypted passwords. Does it also
support encrypted data?
a. Yes
b. No
3. The final authority on Samba software and configuration is at this
URL:
http://www.______________________________
Student Notebook
Notes:
This unit has tried to address some common issues in setting up a Samba server.
We want to make sure we mention (yet again), that the Samba package is a moving
product and will continue to evolve over time. A good example is the comment made by a
Samba developer that there is a lot of encouragement for the Samba team to write their
own security server replication protocol, since Microsoft refuses to release the
specifications for theirs. Such things will undoubtedly have an impact on all facets of server
security.
We want to wish you luck in setting up your Samba configurations. We have found that
Samba is a very robust product, that certainly fills a need in the corporate environment. We
hope you enjoy using the package as much as we do.
Unit Summary
Performance issues
Security concerns
Problem determination help
Student Notebook
Copyright IBM Corp. 1999, 2005 Appendix A. Checkpoint Solutions A-1
V1.2.2
AP
Appendix A. Checkpoint Solutions
Unit 1
1. True
2. False
Third parties may also create RPMs.
3. False
Its the ./configure script which accepts the options where the files
should go.
Unit 2
1. False
The WINS server keeps a list of all systems on the network and
their IP addresses. An LMB only keeps a list of systems in its
workgroup and the shares they offer.
2. os level
3. False
When systems cannot use the WINS server, they fall back to
broadcasts.
Unit 3
1. True
2. The location and name of this file depend on the settings of the
smb passwd file parameter in smb.conf.
3. smbpasswd -a
4. pdbedit -c [D] <username>
Unit 4
1. True
2. True
3. True
joe must be given access to the share, but individual files can have
their Linux permissions adjusted so that the user joe does not have
access.
Student Notebook
A-2 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Unit 5
1. c
Printer sharing does not promote the saving of paper products.
2. This is a trick question. If printing = cups, then Samba will
communicate with cupsd directly to retrieve the list of printers.
Samba will not read the /etc/cups/printers.conf file itself.
3. True
The default configuration does not enable guest ok = yes.
4. True.
The [print$] sharename is hard-coded in Windows.
Unit 6
1. True
As long as they each manage a separate domain.
2. Configure security=domain and a password server in smb.conf.
Join the Samba server in the domain with the net rpc join
command.
3. You need to install usrmgr.exe on your Windows system, and
configure the various add/modify/delete user/group scripts in
smb.conf.
Unit 7
1. True
2. Configure security=ads and a password server in smb.conf.
Configure Kerberos
Join the Samba server in the domain with the net ads join
command.
Unit 8
1. False
2. logon drive and logon home
3. True, but this change will not be persistent when the user logs out.
Unit 9
1. In /etc/openldap/slapd.conf, encrypted with slappasswd
In /usr/local/sbin/smbldap_conf.pm, in plain text
In /etc/samba/secrets.tdb, with the command smbpasswd -w
2. passdb backend = ldapsam:<LDAP URL>
Student Notebook
Copyright IBM Corp. 1999, 2005 Appendix A. Checkpoint Solutions A-3
V1.2.2
AP
3. Yes, but it eliminates enormous benefits
Unit 10
1. False
2. winbindd daemon, pam_winbind.so, libnss_winbind.so,
winbindd_idmap.tdb
3. Add pam_mkhomedir.so to the relevant PAM configuration files,
and set obey pam restrictions = yes in smb.conf
Unit 11
1. True
2. False
SWAT will check each value to ensure that it is in the proper range,
for example, but it will not check multiple parameters to ensure
they make sense when used together.
3. /etc/xinetd.d/swat
Unit 12
1. False
It may come close, or it may not change at all. Performance is
constrained by all of the resources (CPU, memory, disk, network),
not just one.
2. No
3. samba.org
with various mirrors around the world.
Student Notebook
A-4 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Student Notebook
Course materials may not be reproduced in whole or in part without the prior
written permission of IBM.
Copyright IBM Corp. 1999, 2005 Appendix B. Certification Information B-1
V3.0
AP
Appendix B. Certification Information
As mentioned in this course, Linux is not a product which is owned by a single company.
Instead, it is developed by a loose team of volunteers on the Internet. As such, there is no
natural body responsible for Linux certification. At this moment, at least four organizations
have tried to fill this void and have come up with their own Linux certification program. IBM
supports three of these organizations:
The Linux Professional Institute (http://www.lpi.org) is an organization run by
volunteers with the sole purpose of implementing a vendor-neutral certification program
for Linux. They are sponsored by a number of Linux-related companies, among which
IBM. The certification tests are delivered by VUE (Virtual University Enterprises)
(http://www.vue.com). LPI aims to implement three levels of certification, of which the
first two levels are currently ready.
CompTIA (http://www.comptia.org) is the organization that has, in the past, already
developed a number of certifications that are aimed mostly at help desk personnel and
hardware engineers. Recently CompTIA introduced the Linux+ exam, which is aimed
at Linux Professionals with 6 months of experience with Linux. CompTIA tests are also
delivered by VUE, and by Prometric (http://www.prometric.com).
Red Hat (http://www.redhat.com) is the distributor of Red Hat Linux, one of the leading
commercial Linux distributions. As part of their service organization they have
developed their own education leading to the Red Hat Certified Technician and Red
Hat Certified Engineer exams. In contrast to the other Linux exams, the RHCT and
RHCE exams are performance based, which means that the examinee takes place
behind an actual Red Hat Linux system and needs to demonstrate his/her skills on this
system. The practical components of the RHCT exam takes about 2.5 hours, while the
practical components of the RHCE exam take about five hours.
For all three certification programs, the support of IBM extends to the following:
1. Involvement and/or active support in developing the certification program, the exam
objectives and test questions.
2. Where appropriate: sponsoring the certification program.
3. Developing courseware and teaching courses to prepare students for certification, and
where possible certifying this course material for the exams involved.
4. Exam delivery.
IBM IT Education Services Courseware
IBM IT Education Services started developing courseware for Linux at the end of 1998,
when no certification programs for Linux existed. The Linux curriculum was heavily
modeled after the AIX curriculum, but has changed since to reflect the different ways Linux
Student Notebook
B-2 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
and AIX are being used today. IBM's Linux course material is not tied to any particular
distribution, and is also not tied to any particular certification.
The total curriculum consists of more than fifteen courses that cover the Linux Operating
System, and an even larger number of courses that cover IBM middleware that runs on
Linux (such as DB2, MQSeries, Lotus Domino and so forth) and IBM hardware. For the
purpose of certification though, only seven courses are important:
The LX02 (Linux Power User) is the entry course in the IBM/Linux curriculum. Its aim is to
teach a Linux novice to install and configure Linux so that he/she is able to run Linux on
his/her personal workstation or home system in an environment that is mostly based on
MS-Windows.
The LX03 (Linux System Administration I: Implementation) is the main system
administration course. Its aim is to teach a Linux user the techniques and practices used in
installing, configuring, running and maintaining a Linux-based server.
The LX07 (Linux Network Administration I: TCP/IP and TCP/IP Services) is the main
network administration course. Its aim is to teach a Linux system administrator how to
configure TCP/IP and various TCP/IP services that run on Linux.
The LX22 (Linux Perl Programming) is the course that covers Perl programming.
The LX23 (Linux Bash Programming) is the course that covers Bash shell programming
and the various programs that are typically used in shell programs, such as grep, awk and
sed.
The LX24 (Linux Network Administration II: Network Security and Firewalls) covers
the configuration of a full-function firewall under Linux. As such, it also covers a number of
security aspects of Linux that are not particularly related to firewalls, but apply to any
networked system.
The LX25 (Linux as a Web server - Apache) is the course which covers Apache, the most
commonly used Web server on Linux and other UNIX platforms.
The LX26 (Linux integration with Windows - Samba) is the course which covers Samba,
the product which emulates a networked Windows NT server to the network.
All these courses are available from IBM IT Education Services and selected business
partners (pricing and availability may differ from country to country). For information on
pricing and scheduling, contact your local IBM IT Education Services representative.
IBM IT Education Services has developed these courses so that they can be taken in a
logical order. Furthermore, the organization of topics into courses is such that at the end of
a course, a student is able to fully grasp a topic, and is able to apply this successfully on his
Linux system(s).
From Education to Certification
IBMs arrangements of topics into IBMs Linux courses is not always consistent with the
requirements of the supported certifications. This leads to a problem when determining
Student Notebook
Copyright IBM Corp. 1999, 2005 Appendix B. Certification Information B-3
V3.0
AP
which courses are needed for which certification. A certain test might require installation
and basic configuration of a product. This is covered by a certain IBM/Linux course, but
that very same course also covers advanced configuration, which might be the subject of
an entirely different test.
As an example, IBM has one, two-day course about Samba (the LX26), which fully covers
the whole Samba product and its possibilities. Samba knowledge is tested by the LPI in two
places though: Test 102 (topic 1.13, objective 4) requires the examinee to install and
configure Samba using the included GUI tools or direct edit of the /etc/smb.conf file (which
is covered in the first two units of the LX26), while test 201 (topic 2.9, objective 1) requires
that the candidate should be able to set up a Samba server for various clients, including
setting up a login script and setting up and nmbd WINS server (which is the end objective
of the LX26).
This problem is too fundamental to solve by simply changing or rearranging the course
material, apart from the fact that we think that it is not desirable to specifically write courses
for certification. One of the purposes of this attachment is therefore to identify the areas
where IBM's course material does not match with certification objectives.
Student Notebook
B-4 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Education/Certification Matrix
The following table lists the required and recommended courses for each of the supported
certification programs:
Remarks to the table:
1. Required means: the subjects covered in this course are essential knowledge to pass
the exam.
Recommended means that a small portion of the exam (less than 5%) is covered in the
course listed. It is possible to pass the exam without this knowledge. Students do so
however at their own risk and should compare their knowledge with the exam
objectives.
2. CompTIA Linux+ also requires intimate knowledge of PC hardware in general (Domain
7) which accounts for 19% of the exam. This includes knowledge of the BIOS, IRQs, I/O
ports, DMA, ATA devices, SCSI devices, IEEE 1394 devices, PCMCIA devices, ISA
devices, PCI devices, APM and the ability to configure and replace them, were
applicable. This part of the exam is not related to Linux and thus not covered in any of
IBMs Linux courses. CompTIAs own education (and other education) that leads to
CompTIA A+ certification may be used to obtain this knowledge.
3. ProCert (http://www.procert.com) has certified these courses as appropriate course
material for preparing for LPI certification tests. This certification is only valid if all
courses, including the courses that are listed here as recommended are taken before
attempting an LPI certification test.
4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such
allowed to teach the Red Hat courses RH033, RH133 and RH253. These courses can
be used as an alternative to LX02, LX03 and LX07, respectively, to prepare for
RHCT/RHCE certification. They cannot be used for other certifications though, and
these courses are not scheduled in all countries.
Course
CompTIA LPI Red Hat
Linux+ Test 101 Test 102 Test 201 Test 202 RHCT RHCE
LX02 Required Required Required Required Required Required Required
LX03 Required Required Required Required Required Required Required
LX07 Required Required Required Required
LX22 Recomm.
LX23 Recomm. Recomm.
LX24 Required Recomm.
LX25 Recomm. Required Recomm.
LX26 Recomm. Required Recomm.
Student Notebook
Copyright IBM Corp. 1999, 2005 Appendix C. List of smb.conf Variables C-1
V1.2.2 BKM2MIF
Uempty
Appendix C. List of smb.conf Variables
%a Architecture of remote machine
%d Process ID of the current server process
%g Primary Group of %u
%G Primary Group of %U
%h Internet hostname of the server on which Samba is running
%H Home directory of %u
%I IP address for the client machine
%L NetBIOS name of the server. This is useful for dual personality Samba
servers, who have specified netbios aliases, who can do include =
%L.conf
%m NetBIOS name of the client machine. Most Samba configurations have a
log file per client, so log file = log.%m
%M Internet hostname of the client machine
%N The name of your NIS home directory server, otherwise identical to %L.
Works only if you compiled Samba with --with-automount, in which case
Samba is able to use the NIS server to determine and share your home
directory from the NFS server that exports your home directory.
%p The path to the users home directory on the NIS home directory server.
Useful in combination with %N.
%P The root directory of the current service
%R The protocol negotiated during connection setup
%S Name of the current service
%T Current date and time
%u The username of the current service
%U The username the client requested in the session setup. Not necessarily
the same as %u (for instance when force user or guest only is used)
%v Samba version number
%$(envvar) The value of the environment variable envvar
Student Notebook
C-2 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Copyright IBM Corp. 1999, 2005 Index X-1
Index
Symbols
%u 1-8
./configure 1-14
A
Access Control Lists 4-10
ACL 4-10, 9-31
Active Directory 7-3
add group script 6-11, 9-27
add machine script 6-9, 9-26
add user script 6-11, 9-26
add user to group script 6-11, 9-27
AIX 1-3
application/octet-stream 5-9
authconfig 9-24
Authentication 1-4
B
Backup Domain Controllers 6-3
Base DN 9-10
browsable 4-7
Browsing 1-4
C
case sensitive 4-8
chkconfig 1-16
CLI 9-16
CN 9-10
Command Line Interface 9-16
comment 4-7
Common Name 9-10
CompTIA B-1
configure 1-14
create mask 4-11
CUPS 5-6, 5-9, 5-14
D
debug level 12-4
default case 4-8
delete group script 6-11, 9-27
delete user from group script 6-11, 9-27
delete user script 6-11, 9-27
diff 11-13
directory mask 4-11
Distinguished Name 9-10
DMB 2-8
DN 9-10
dns proxy 12-8
domain logons 6-8
domain master 2-8, 6-8
Domain Master Browser 2-8
E
encrypted passwords 3-10, 12-19
F
fake oplocks 12-4
File sharing 1-4
force create mask 4-11
force directory mask 4-11
force group 4-11
force user 4-11, 10-3
fork() 3-6
FSSTND 1-15
ftp 1-18
G
getent 9-17, 9-24, 10-5
getwd cache 12-4
gq 9-18, 9-28
group_mapping.tdb 3-9
guest account 3-16, 4-13, 12-11, 12-18
guest ok 4-7, 4-12, 5-6, 12-18
guest only 4-12, 5-6, 10-3
H
hide dot files 4-9
4-6
host msdfs 4-14
hosts allow 1-8, 12-6, 12-11
hosts deny 12-6
HP-UX 1-3
I
id 9-17, 10-5
idmap backend 10-6
idmap backend, 10-7
idmap gid 10-8
idmap uid 10-8
include 1-8
inherit permissions 4-11
interfaces 1-8
K
KAS 7-7
Kerberos 7-3
X-2 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
Kerberos Authentication Server 7-6
Kerberos ticket 7-6
Kerberos Ticket Granting Server 7-7
kinit 7-9
klist 7-9
Konqueror 1-6
L
LDAP 9-9
LDAP schema 9-13
ldapmodify 9-28
ldapsam 9-4
ldapsearch 9-23, 9-27
libnss_winbind.so 10-5
Linux 1-3
Linux Professional Institute -xiii, B-1
LMB 2-5
lmhosts 1-5
load printers 5-5
local master 2-6, 6-8
Local Master Browser 2-5
locking 4-13
log file 1-8
log level 1-8
logon drive 8-8
logon home 8-8
logon path 8-7
logon script 8-9
LPI -xiii
LPI certification -xiii
LPI. See Linux Professional Institute
lppause command 5-5
lpq command 5-5
lpresume command 5-5
lprm command 5-5
LX02 B-2
LX03 B-2
LX07 B-2
LX22 B-2
LX23 B-2
LX24 B-2
LX25 B-2
LX26 B-2
Lynx 1-6
M
make 1-14
make install 1-14
mangle case 4-8
map to guest 3-16
max xmit 12-4
Microsoft Distributed Filesystem 4-14
Microsoft Driver Development Kit 5-10
mime-type 5-9
mkntpwd 9-22
mount 4-11
Mozilla 1-6
MS-DDK 5-10
MS-DFS 4-14
msdfs roo 4-14
mysql 9-4
N
net ads 7-8
net groupmap 3-9
net rpc 6-6
net rpc getsid 9-30
net setlocalsid 9-30
net vampire 9-30
netbios aliases 2-3
netbios name 1-7, 2-3
NetBIOS over TCP/IP 2-7
6-8, 8-3, 8-9
Netscape 1-6
netstat 12-11
Network Neighborhood 1-4
NIS+ 9-4
nisplussam 9-4
nmbd 1-5, 10-5, 10-8, 12-13
nmblookup 12-14
nscd 10-9
NSS 9-17, 10-5, 10-10
nss_base_group 9-24
nss_base_passwd 9-24
nss_base_shadow 9-24
nsswitch.conf 10-10, 12-8
nt acl support 4-11
ntconfig.pol 8-3
NTFS 4-10
NTUSER.DAT 8-7
NTUSER.MAN 8-7
O
obey pam restrictions 10-12
OpenLDAP 9-17
open-source 1-3
oplocks 12-3
OS Level 2-5
os level 2-6, 6-8
P
PAM 3-7, 9-17, 10-5
pam password change 3-13
pam_mkhomedir.so 10-12
pam_winbind.so 10-5, 10-10
passdb backend 9-3, 9-26
passwd chat 3-13
Copyright IBM Corp. 1999, 2005 Index X-3
password level 3-8, 12-17
password program 3-13
password server 6-6
path 4-7, 5-6
pdbedit 3-14, 9-27, 9-28, 9-30
-c option 3-14
PDC 2-8, 6-8
poledit.exe 8-3, 8-5
postexec 4-13
Postscript 5-10
preexec 4-13
preexec close 4-13
preferred master 2-6, 6-8
preserve case 4-8
Primary Domain Controller 2-8, 6-3, 6-8
print command 5-5, 5-14
Print sharing 1-4
5-11
printable 5-6
printcap file 5-5
printer driver 5-9
5-5
printing 5-5, 5-14
ProCert -xiii
profiles 9-31
public 4-7, 6-8
R
raw printing 5-9
read list 4-12
read only 4-7, 4-12, 5-6, 12-4
read raw 12-4
realm 7-6
realm name 7-8
Red Hat B-1
Red Hat Certified Engineer B-1
Red Hat Certified Technician B-1
REGEDIT.EXE 3-10
resolv.conf 12-8
RHCE. See Red Hat Certified Engineer
RHCT. See Red Hat Certified Technician
Roaming profiles 8-6
root postexec 4-13
root preexec 4-13, 8-9
root preexec close 4-13
RootDN 9-18
rpcclient 5-12
RPM 1-10
RPM Package Manager 1-10
S
SAM 3-15, 9-3, 9-30, 10-3
Samba B-3
security = ads 7-8
security = domain 6-6
security = server 6-4
security = share 3-5
security = user 3-6, 6-4, 6-8
Security Account Manager 9-3
server string 2-4
set primary group script 9-27
setuid() 3-6
share 4-6, 5-5, 5-11, 6-8, 8-3, 8-9
short preserve case 4-9
SID 9-30
slapcat 9-23, 9-27
slappasswd 9-19
smb.conf 1-5
smbclient 1-17, 1-18, 9-27, 12-11, 12-16
get command 1-18
-L option 1-18
put command 1-18
smbd 1-5, 10-5, 10-8
smbldap-populate.pl 9-22
smbldap-tools 9-17, 9-22, 9-28
-a option 9-23
smbpasswd 1-5, 3-11, 3-12, 3-13, 3-14, 9-3, 9-26
-a option 3-12
-w option 9-27
smbpasswd file 9-26
smbusers 1-5, 3-7
socket options 1-8, 12-4
Solaris 1-3
SRPM 1-10
SWAT 1-6, 11-3
T
tattoo effect 8-3
tcpdump-smb 12-20
TDB 3-9
tdbsam 9-3
template homedir 10-9
template shell 10-9
testparm 1-8, 1-16, 11-13, 12-9
TGS 7-7
Trivial DataBase 3-9
U
unix password sync 3-13
unix2dos 8-9
update encrypted 3-12
username level 3-8
username map 3-7, 9-26
users 3-5
usrmgr.exe 6-10, 9-28
X-4 Linux Integration with Windows (Samba) Copyright IBM Corp. 1999, 2005
V
valid users 4-12
vfs objects 4-13
W
wbinfo
-g option 10-9
--set-auth-user option 10-9
-u option 10-9
who 10-5
wide links 12-4
winbind separator 10-8
winbindd 10-5, 10-8
winbindd_idmap.tdb 10-5
Windows Domain 6-3
Windows Explorer 1-16
WINS 2-9
wins server 2-10
wins support 2-10
workgroup 1-7
workgroup name 2-3
writable 4-7, 4-12, 6-8
write list 4-12
write raw 12-4
Y
yast 9-24
V1.2.2
backpg

QLX26STUD

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

QLX26STUD

Hochgeladen von

Copyright:

Verfügbare Formate

Linux Integration

with Windows (Samba)

Das könnte Ihnen auch gefallen