sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2025-02-14 01:57:53 +03:00
Code

syncing up with 2.2

Browse Source
This commit is contained in:
Gerald Carter -
parent 30e385a737
commit dd83f412e9
8 changed files with 0 additions and 3222 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
docs/textdocs/DOMAIN_CONTROL.txt
View File

@ -1,121 +0,0 @@
!==
!== DOMAIN_CONTROL.txt for Samba release 2.0.4 18 May 1999
!==
Initial Release: August 22, 1996
Contributor: John H Terpstra <samba-bugs@samba.org>
Copyright (C) 1996-1997 - John H Terpstra
Updated: July 5, 1998
Status: Current
Subject: Windows NT Domain Control & Samba
============================================================================
****NOTE:****
=============
The term "Domain Controller" and those related to it refer to one specific
method of authentication that can underly an SMB domain. Domain Controllers
prior to Windows NT Server 3.1 were sold by various companies and based on
private extensions to the LAN Manager 2.1 protocol. Windows NT introduced
Microsoft-specific ways of distributing the user authentication database.
See DOMAIN.txt for examples of how Samba can participate in or create
SMB domains based on shared authentication database schemes other than the
Windows NT SAM.
Microsoft Windows NT Domain Control is an extremely complex protocol.
We have received countless requests to implement Domain Control in Samba.
The 1.9.18 release of Samba contains experimental code to implement
this. Please read the file docs/NTDOMAIN.txt for more information on this.
============================================================================
Windows NT Server can be installed as either a plain file and print server
(WORKGROUP workstation or server) or as a server that participates in Domain
Control (DOMAIN member, Primary Domain controller or Backup Domain controller).
The same is true for OS/2 Warp Server, Digital Pathworks and other similar
products, all of which can participate in Domain Control along with Windows NT.
However only those servers which have licenced Windows NT code in them can be
a primary Domain Controller (eg Windows NT Server, Advanced Server for Unix.)
To many people these terms can be confusing, so let's try to clear the air.
Every Windows NT system (workstation or server) has a registry database.
The registry contains entries that describe the initialisation information
for all services (the equivalent of Unix Daemons) that run within the Windows
NT environment. The registry also contains entries that tell application
software where to find dynamically loadable libraries that they depend upon.
In fact, the registry contains entries that describes everything that anything
may need to know to interact with the rest of the system.
The registry files can be located on any Windows NT machine by opening a
command prompt and typing:
dir %SystemRoot%\System32\config
The environment variable %SystemRoot% value can be obtained by typing:
echo %SystemRoot%
The active parts of the registry that you may want to be familiar with are
the files called: default, system, software, sam and security.
In a domain environment, Microsoft Windows NT domain controllers participate
in replication of the SAM and SECURITY files so that all controllers within
the domain have an exactly identical copy of each.
The Microsoft Windows NT system is structured within a security model that
says that all applications and services must authenticate themselves before
they can obtain permission from the security manager to do what they set out
to do.
The Windows NT User database also resides within the registry. This part of
the registry contains the user's security identifier, home directory, group
memberships, desktop profile, and so on.
Every Windows NT system (workstation as well as server) will have its own
registry. Windows NT Servers that participate in Domain Security control
have a database that they share in common - thus they do NOT own an
independent full registry database of their own, as do Workstations and
plain Servers.
The User database is called the SAM (Security Access Manager) database and
is used for all user authentication as well as for authentication of inter-
process authentication (ie: to ensure that the service action a user has
requested is permitted within the limits of that user's privileges).
The Samba team have produced a utility that can dump the Windows NT SAM into
smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and
/pub/samba/pwdump on your nearest Samba mirror for the utility. This
facility is useful but cannot be easily used to implement SAM replication
to Samba systems.
Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers
can participate in a Domain security system that is controlled by Windows NT
servers that have been correctly configured. At most every domain will have
ONE Primary Domain Controller (PDC). It is desirable that each domain will
have at least one Backup Domain Controller (BDC).
The PDC and BDCs then participate in replication of the SAM database so that
each Domain Controlling participant will have an up to date SAM component
within its registry.
Samba can NOT at this time function as a Domain Controller for any of these
security services, but like all other domain members can interact with the
Windows NT security system for all access authentication.
When Samba is configured with the 'security = server' option and the
'password server = Your_Windows_NT_Server_Name' option, then it will
redirect all access authentication to that server. This way you can
use Windows NT to act as your password server with full support for
Microsoft encrypted passwords.
Note also, that since release of samba-1.9.18 we now support native encrypted
passwords too. To enable encrypted password handling several things need to be
done:
1) In smb.conf [globals]:
encrypt passwords = yes
smbpasswd file = /path/smbpasswd
the standard path is /usr/local/samba/private/smbpasswd but this may be
platform specific.
2) Use "smbpasswd -a" to add all users to the smbpasswd file.
Above all read all the documentation for encrypted password support - you will
need it!

151
docs/textdocs/DOMAIN_MEMBER.txt
View File

@ -1,151 +0,0 @@
TITLE INFORMATION: Joining an NT Domain with Samba 2.0
AUTHOR INFORMATION: Jeremy Allison, Samba Team
DATE INFORMATION: 7th October 1999
Table of Contents
Joining an NT Domain with Samba 2.0
-----------------------------------
In order for a Samba-2 server to join an NT domain, you must first add
the NetBIOS name of the Samba server to the NT domain on the PDC using
Server Manager for Domains. This creates the machine account in the
domain (PDC) SAM. Note that you should add the Samba server as a "Windows
NT Workstation or Server", NOT as a Primary or backup domain controller.
Assume you have a Samba-2 server with a NetBIOS name of SERV1 and are
joining an NT domain called DOM, which has a PDC with a NetBIOS name
of DOMPDC and two backup domain controllers with NetBIOS names DOMBDC1
and DOMBDC2.
In order to join the domain, first stop all Samba daemons and run the
command
smbpasswd -j DOM -r DOMPDC
as we are joining the domain DOM and the PDC for that domain (the only
machine that has write access to the domain SAM database) is DOMPDC. If this is
successful you will see the message:
smbpasswd: Joined domain DOM.
in your terminal window. See the smbpasswd
man page for more details.
This command goes through the machine account password change
protocol, then writes the new (random) machine account password for
this Samba server into a file in the same directory in which an
smbpasswd file would be stored - normally :
/usr/local/samba/private
The filename looks like this:
<NT DOMAIN NAME>.<Samba Server Name>.mac
The .mac suffix stands for machine account password file. So in
our example above, the file would be called:
DOM.SERV1.mac
This file is created and owned by root and is not readable by any
other user. It is the key to the domain-level security for your
system, and should be treated as carefully as a shadow password file.
Now, before restarting the Samba daemons you must edit your
smb.conf file to tell Samba it should now
use domain security.
Change (or add) your
"security ="
line in the [global] section of your
smb.conf to read:
security = domain
Next change the
"workgroup ="
line in the [global] section to read:
workgroup = DOM
as this is the name of the domain we are joining.
You must also have the parameter "encrypt passwords"
set to "yes" in order for your users to authenticate to the
NT PDC.
Finally, add (or modify) a:
"password server ="
line in the [global] section to read:
password server = DOMPDC DOMBDC1 DOMBDC2
These are the primary and backup domain controllers Samba will attempt
to contact in order to authenticate users. Samba will try to contact
each of these servers in order, so you may want to rearrange this list
in order to spread out the authentication load among domain
controllers.
Alternatively, if you want smbd to automatically determine the
list of Domain controllers to use for authentication, you may set this line to be :
password server = *
This method, which is new in Samba 2.0.6 and above, allows Samba
to use exactly the same mechanism that NT does. This method either broadcasts or
uses a WINS database in order to find domain controllers to
authenticate against.
Finally, restart your Samba daemons and get ready for clients to begin
using domain security!
Why is this better than security = server?
------------------------------------------
Currently, domain security in Samba doesn't free you from having to
create local Unix users to represent the users attaching to your
server. This means that if domain user DOM\fred attaches to your
domain security Samba server, there needs to be a local Unix user fred
to represent that user in the Unix filesystem. This is very similar to
the older Samba security mode "security=server", where Samba would pass
through the authentication request to a Windows NT server in the same
way as a Windows 95 or Windows 98 server would.
The advantage to domain-level security is that the authentication in
domain-level security is passed down the authenticated RPC channel in
exactly the same way that an NT server would do it. This means Samba
servers now participate in domain trust relationships in exactly the
same way NT servers do (i.e., you can add Samba servers into a
resource domain and have the authentication passed on from a resource
domain PDC to an account domain PDC.
In addition, with "security=server" every Samba daemon on a
server has to keep a connection open to the authenticating server for
as long as that daemon lasts. This can drain the connection resources
on a Microsoft NT server and cause it to run out of available
connections. With "security =domain", however, the Samba
daemons connect to the PDC/BDC only for as long as is necessary to
authenticate the user, and then drop the connection, thus conserving
PDC connection resources.
And finally, acting in the same manner as an NT server authenticating
to a PDC means that as part of the authentication reply, the Samba
server gets the user identification information such as the user SID,
the list of NT groups the user belongs to, etc. All this information
will allow Samba to be extended in the future into a mode the
developers currently call appliance mode. In this mode, no local Unix
users will be necessary, and Samba will generate Unix uids and gids
from the information passed back from the PDC when a user is
authenticated, making a Samba server truly plug and play in an NT
domain environment. Watch for this code soon.
NOTE: Much of the text of this document was first published in the
Web magazine "LinuxWorld" as the article "Doing the NIS/NT Samba".

331
docs/textdocs/ENCRYPTION.txt
View File

@ -1,331 +0,0 @@
!==
!== ENCRYPTION.txt for Samba release 2.0.5a 22 Jul 1999
!==
Contributor: Jeremy Allison <samba-bugs@samba.org>
Updated: April 19, 1999
Note: Please refer to WinNT.txt also
Subject: LanManager / Samba Password Encryption.
============================================================================
With the development of LanManager and Windows NT compatible password
encryption for Samba, it is now able to validate user connections in
exactly the same way as a LanManager or Windows NT server.
This document describes how the SMB password encryption algorithm
works and what issues there are in choosing whether you want to use
it. You should read it carefully, especially the part about security
and the "PROS and CONS" section.
How does it work ?
------------------
LanManager encryption is somewhat similar to UNIX password
encryption. The server uses a file containing a hashed value of a
user's password. This is created by taking the user's plaintext
password, capitalising it, and either truncating to 14 bytes (or
padding to 14 bytes with null bytes). This 14 byte value is used as
two 56 bit DES keys to encrypt a 'magic' eight byte value, forming a
16 byte value which is stored by the server and client. Let this value
be known as the *hashed password*.
Windows NT encryption is a higher quality mechanism, consisting
of doing an MD4 hash on a Unicode version of the user's password. This
also produces a 16 byte hash value that is non-reversible.
When a client (LanManager, Windows for WorkGroups, Windows 95 or
Windows NT) wishes to mount a Samba drive (or use a Samba resource) it
first requests a connection and negotiates the protocol that the client
and server will use. In the reply to this request the Samba server
generates and appends an 8 byte, random value - this is stored in the
Samba server after the reply is sent and is known as the *challenge*.
The challenge is different for every client connection.
The client then uses the hashed password (16 byte values described
above), appended with 5 null bytes, as three 56 bit DES keys, each of
which is used to encrypt the challenge 8 byte value, forming a 24 byte
value known as the *response*.
In the SMB call SMBsessionsetupX (when user level security is
selected) or the call SMBtconX (when share level security is selected)
the 24 byte response is returned by the client to the Samba server.
For Windows NT protocol levels the above calculation is done on
both hashes of the user's password and both responses are returned
in the SMB call, giving two 24 byte values.
The Samba server then reproduces the above calculation, using its own
stored value of the 16 byte hashed password (read from the smbpasswd
file - described later) and the challenge value that it kept from the
negotiate protocol reply. It then checks to see if the 24 byte value it
calculates matches the 24 byte value returned to it from the client.
If these values match exactly, then the client knew the correct
password (or the 16 byte hashed value - see security note below) and
is thus allowed access. If not, then the client did not know the
correct password and is denied access.
Note that the Samba server never knows or stores the cleartext of the
user's password - just the 16 byte hashed values derived from it. Also
note that the cleartext password or 16 byte hashed values are never
transmitted over the network - thus increasing security.
IMPORTANT NOTE ABOUT SECURITY
-----------------------------
The unix and SMB password encryption techniques seem similar on the
surface. This similarity is, however, only skin deep. The unix scheme
typically sends clear text passwords over the nextwork when logging
in. This is bad. The SMB encryption scheme never sends the cleartext
password over the network but it does store the 16 byte hashed values
on disk. This is also bad. Why? Because the 16 byte hashed values are a
"password equivalent". You cannot derive the user's password from them,
but they could potentially be used in a modified client to gain access
to a server. This would require considerable technical knowledge on
behalf of the attacker but is perfectly possible. You should thus
treat the smbpasswd file as though it contained the cleartext
passwords of all your users. Its contents must be kept secret, and the
file should be protected accordingly.
Ideally we would like a password scheme which neither requires plain
text passwords on the net or on disk. Unfortunately this is not
available as Samba is stuck with being compatible with other SMB
systems (WinNT, WfWg, Win95 etc).
PROS AND CONS
-------------
There are advantages and disadvantages to both schemes.
Advantages of SMB Encryption:
-----------------------------
- plain text passwords are not passed across the network. Someone using
a network sniffer cannot just record passwords going to the SMB server.
- WinNT doesn't like talking to a server that isn't using SMB
encrypted passwords. It will refuse to browse the server if the server
is also in user level security mode. It will insist on prompting the
user for the password on each connection, which is very annoying. The
only things you can do to stop this is to use SMB encryption.
Advantages of non-encrypted passwords:
--------------------------------------
- plain text passwords are not kept on disk.
- uses same password file as other unix services such as login and
ftp
- you are probably already using other services (such as telnet and
ftp) which send plain text passwords over the net, so not sending them
for SMB isn't such a big deal.
Note that Windows NT 4.0 Service pack 3 changed the default for
permissible authentication so that plaintext passwords are *never*
sent over the wire. The solution to this is either to switch to
encrypted passwords with Samba or edit the Windows NT registry to
re-enable plaintext passwords. See the document WinNT.txt for
details on how to do this.
The smbpasswd file.
-------------------
In order for Samba to participate in the above protocol it must
be able to look up the 16 byte hashed values given a user name.
Unfortunately, as the UNIX password value is also a one way hash
function (ie. it is impossible to retrieve the cleartext of the user's
password given the UNIX hash of it) then a separate password file
containing this 16 byte value must be kept. To minimise problems with
these two password files, getting out of sync, the UNIX /etc/passwd and
the smbpasswd file, a utility, mksmbpasswd.sh, is provided to generate
a smbpasswd file from a UNIX /etc/passwd file.
To generate the smbpasswd file from your /etc/passwd file use the
following command :-
cat /etc/passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd
If you are running on a system that uses NIS, use
ypcat passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd
The mksmbpasswd.sh program is found in the Samba source directory. By
default, the smbpasswd file is stored in :-
/usr/local/samba/private/smbpasswd
The owner of the /usr/local/samba/private directory should be set to
root, and the permissions on it should be set to :-
r-x------
The command
chmod 500 /usr/local/samba/private
will do the trick. Likewise, the smbpasswd file inside the private
directory should be owned by root and the permissions on is should be
set to
rw-------
by the command :-
chmod 600 smbpasswd.
The format of the smbpasswd file is
username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[Account type]:LCT-<last-change-time>:Long name
Although only the username, uid, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,
[Account type] and last-change-time sections are significant and
are looked at in the Samba code.
It is *VITALLY* important that there by 32 'X' characters between the
two ':' characters in the XXX sections - the smbpasswd and Samba code
will fail to validate any entries that do not have 32 characters
between ':' characters. The first XXX section is for the Lanman password
hash, the second is for the Windows NT version.
When the password file is created all users have password entries
consisting of 32 'X' characters. By default this disallows any access
as this user. When a user has a password set, the 'X' characters change
to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii
representation of the 16 byte hashed value of a user's password.
To set a user to have no password (not recommended), edit the file
using vi, and replace the first 11 characters with the asci text
NO PASSWORD
Eg. To clear the password for user bob, his smbpasswd file entry would
look like :
bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
If you are allowing users to use the smbpasswd command to set their own
passwords, you may want to give users NO PASSWORD initially so they do
not have to enter a previous password when changing to their new
password (not recommended). In order for you to allow this the
smbpasswd program must be able to connect to the smbd daemon as
that user with no password. Enable this by adding the line :
null passwords = true
to the [global] section of the smb.conf file (this is why the
above scenario is not recommended). Preferably, allocate your
users a default password to begin with, so you do not have
to enable this on your server.
Note : This file should be protected very carefully. Anyone with
access to this file can (with enough knowledge of the protocols) gain
access to your SMB server. The file is thus more sensitive than a
normal unix /etc/passwd file.
The smbpasswd Command.
----------------------
The smbpasswd command maintains the two 32 byte password fields in
the smbpasswd file. If you wish to make it similar to the unix passwd
or yppasswd programs, install it in /usr/local/samba/bin (or your main
Samba binary directory).
Note that as of Samba 1.9.18p4 this program MUST NOT BE INSTALLED
setuid root (the new smbpasswd code enforces this restriction so
it cannot be run this way by accident).
smbpasswd now works in a client-server mode where it contacts
the local smbd to change the user's password on its behalf. This
has enormous benefits - as follows.
1). smbpasswd no longer has to be setuid root - an enormous
range of potential security problems is eliminated.
2). smbpasswd now has the capability to change passwords
on Windows NT servers (this only works when the request is
sent to the NT Primary Domain Controller if you are changing
an NT Domain user's password).
To run smbpasswd as a normal user just type :
smbpasswd
Old SMB password: <type old value here - or hit return if there was no old password >
New SMB Password: < type new value >
Repeat New SMB Password: < re-type new value >
If the old value does not match the current value stored for that user,
or the two new values do not match each other, then the password will
not be changed.
If invoked by an ordinary user it will only allow the user to change
his or her own Samba password.
If run by the root user smbpasswd may take an optional argument,
specifying the user name whose SMB password you wish to change. Note
that when run as root smbpasswd does not prompt for or check the old
password value, thus allowing root to set passwords for users who have
forgotten their passwords.
smbpasswd is designed to work in the same way and be familiar to UNIX
users who use the passwd or yppasswd commands.
For more details on using smbpasswd refer to the man page which
will always be the definitive reference.
Setting up Samba to support LanManager Encryption.
--------------------------------------------------
This is a very brief description on how to setup samba to support
password encryption. More complete instructions will probably be added
later.
1) compile and install samba as usual
2) if your system can't compile the module getsmbpass.c then remove the
-DSMBGETPASS define from the Makefile.
3) enable encrypted passwords in smb.conf by adding the line
"encrypt passwords = yes" in the [global] section
4) create the initial smbpasswd password file in the place you
specified in the Makefile. A simple way to do this based on your
existing Makefile (assuming it is in a reasonably standard format) is
like this:
cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd
Change ownership of private and smbpasswd to root.
chown -R root /usr/local/samba/private
Set the correct permissions on /usr/local/samba/private
chmod 500 /usr/local/samba/private
Set the correct permissions on /usr/local/samba/private/smbpasswd
chmod 600 /usr/local/samba/private/smbpasswd
note that the mksmbpasswd.sh script is in the samba source directory.
If this fails then you will find that you will need entries that look
like this:
# SMB password file.
tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Andrew Tridgell:/home/tridge:/bin/tcsh
note that the uid and username fields must be right. Also, you must get
the number of X's right (there should be 32).
5) set the passwords for users using the smbpasswd command. For
example, as root you could do "smbpasswd tridge"
6) try it out!
Note that you can test things using smbclient, as it also now supports
encryption.
==============================================================================
Footnote: Please refer to WinNT.txt also

304
docs/textdocs/NT_Security.txt
View File

@ -1,304 +0,0 @@
TITLE INFORMATION: Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4
AUTHOR INFORMATION: Jeremy Allison, Samba Team
DATE INFORMATION: 12th April 1999
Table of Contents
Viewing and changing UNIX permissions using the NT security dialogs
-------------------------------------------------------------------
New in the Samba 2.0.4 release is the
ability for Windows NT clients to use their native security
settings dialog box to view and modify the underlying UNIX
permissions.
Note that this ability is careful not to compromise the security
of the UNIX host Samba is running on, and still obeys all the
file permission rules that a Samba administrator can set.
In Samba 2.0.4 and above the default value of the parameter
"nt acl support" has been
changed from "false" to "true", so manipulation of permissions is
turned on by default.
How to view file security on a Samba share
------------------------------------------
From an NT 4.0 client, single-click with the right mouse button on
any file or directory in a Samba mounted drive letter or UNC path.
When the menu pops-up, click on the Properties entry at the
bottom of the menu. This brings up the normal file properties dialog
box, but with Samba 2.0.4 this will have a new tab along the top
marked Security. Click on this tab and you will see three buttons,
Permissions, Auditing, and Ownership. The Auditing
button will cause either an error message "A requested privilege is
not held by the client" to appear if the user is not the NT Administrator,
or a dialog which is intended to allow an Administrator to add
auditing requirements to a file if the user is logged on as the
NT Administrator. This dialog is non-functional with a Samba
share at this time, as the only useful button, the Add button
will not currently allow a list of users to be seen.
Viewing file ownership
----------------------
Clicking on the "Ownership" button brings up a dialog box telling
you who owns the given file. The owner name will be of the form :
"SERVER\user (Long name)"
Where SERVER is the NetBIOS name of the Samba server, user
is the user name of the UNIX user who owns the file, and (Long name)
is the discriptive string identifying the user (normally found in the
GECOS field of the UNIX password database). Click on the Close
button to remove this dialog.
If the parameter "nt acl support"
is set to "false" then the file owner will be shown as the NT user
"Everyone".
The Take Ownership button will not allow you to change the
ownership of this file to yourself (clicking on it will display a
dialog box complaining that the user you are currently logged onto
the NT client cannot be found). The reason for this is that changing
the ownership of a file is a privilaged operation in UNIX, available
only to the root user. As clicking on this button causes NT to
attempt to change the ownership of a file to the current user logged
into the NT client this will not work with Samba at this time.
There is an NT chown command that will work with Samba and allow
a user with Administrator privillage connected to a Samba 2.0.4
server as root to change the ownership of files on both a local NTFS
filesystem or remote mounted NTFS or Samba drive. This is available
as part of the Seclib NT security library written by Jeremy
Allison of the Samba Team, available from the main Samba ftp site.
Viewing file or directory permissions
-------------------------------------
The third button is the "Permissions" button. Clicking on this
brings up a dialog box that shows both the permissions and the UNIX
owner of the file or directory. The owner is displayed in the form :
"SERVER\user (Long name)"
Where SERVER is the NetBIOS name of the Samba server, user
is the user name of the UNIX user who owns the file, and (Long name)
is the discriptive string identifying the user (normally found in the
GECOS field of the UNIX password database).
If the parameter "nt acl support"
is set to "false" then the file owner will be shown as the NT user
"Everyone" and the permissions will be shown as NT "Full Control".
The permissions field is displayed differently for files and directories,
so I'll describe the way file permissions are displayed first.
File Permissions
----------------
The standard UNIX user/group/world triple and the correspinding
"read", "write", "execute" permissions triples are mapped by Samba
into a three element NT ACL with the 'r', 'w', and 'x' bits mapped
into the corresponding NT permissions. The UNIX world permissions are mapped
into the global NT group Everyone, followed by the list of permissions
allowed for UNIX world. The UNIX owner and group permissions
are displayed as an NT user icon and an NT local group icon
respectively followed by the list of permissions allowed for the
UNIX user and group.
As many UNIX permission sets don't map into common NT names such as
"read", "change" or "full control" then usually the permissions
will be prefixed by the words "Special Access" in the NT display
list.
But what happens if the file has no permissions allowed for a
particular UNIX user group or world component ? In order to
allow "no permissions" to be seen and modified then Samba overloads
the NT "Take Ownership" ACL attribute (which has no meaning in
UNIX) and reports a component with no permissions as having the NT
"O" bit set. This was chosen of course to make it look like a
zero, meaning zero permissions. More details on the decision behind
this will be given below.
Directory Permissions
---------------------
Directories on an NT NTFS file system have two different sets of
permissions. The first set of permissions is the ACL set on the
directory itself, this is usually displayed in the first set of
parentheses in the normal "RW" NT style. This first set of
permissions is created by Samba in exactly the same way as normal
file permissions are, described above, and is displayed in the
same way.
The second set of directory permissions has no real meaning in the
UNIX permissions world and represents the "inherited" permissions
that any file created within this directory would inherit.
Samba synthesises these inherited permissions for NT by returning as
an NT ACL the UNIX permission mode that a new file created by Samba
on this share would receive.
Modifying file or directory permissions
---------------------------------------
Modifying file and directory permissions is as simple as changing
the displayed permissions in the dialog box, and clicking the OK
button. However, there are limitations that a user needs to be aware
of, and also interactions with the standard Samba permission masks
and mapping of DOS attributes that need to also be taken into account.
If the parameter "nt acl support"
is set to "false" then any attempt to set security permissions will
fail with an "Access Denied" message.
The first thing to note is that the "Add" button will not return
a list of users in Samba 2.0.4 (it will give an error message of
"The remote proceedure call failed and did not execute"). This
means that you can only manipulate the current user/group/world
permissions listed in the dialog box. This actually works quite well
as these are the only permissions that UNIX actually has.
If a permission triple (either user, group, or world) is removed from
the list of permissions in the NT dialog box, then when the "OK"
button is pressed it will be applied as "no permissions" on the UNIX
side. If you then view the permissions again the "no permissions" entry
will appear as the NT "O" flag, as described above. This allows you
to add permissions back to a file or directory once you have removed
them from a triple component.
As UNIX supports only the "r", "w" and "x" bits of an NT ACL
then if other NT security attributes such as "Delete access"
are selected then they will be ignored when applied on the
Samba server.
When setting permissions on a directory the second set of permissions
(in the second set of parentheses) is by default applied to all
files within that directory. If this is not what you want you
must uncheck the "Replace permissions on existing files" checkbox
in the NT dialog before clicking "OK".
If you wish to remove all permissions from a user/group/world
component then you may either highlight the component and click
the "Remove" button, or set the component to only have the special
"Take Ownership" permission (dsplayed as "O") highlighted.
Interaction with the standard Samba create mask parameters
----------------------------------------------------------
Note that with Samba 2.0.5 there are four new parameters to
control this interaction.
These are :
security mask
force security mode
directory security mask
force directory security mode
Once a user clicks "OK" to apply the permissions Samba maps
the given permissions into a user/group/world r/w/x triple set,
and then will check the changed permissions for a file against
the bits set in the "security mask"
parameter. Any bits that were changed that are not set to '1'
in this parameter are left alone in the file permissions.
Essentially, zero bits in the "security mask"
mask may be treated as a set of bits the user is not allowed to change,
and one bits are those the user is allowed to change.
If not set explicitly this parameter is set to the same value as the
"create mask" parameter to provide compatibility
with Samba 2.0.4 where this permission change facility was introduced.
To allow a user to modify all the user/group/world permissions on a file,
set this parameter to 0777.
Next Samba checks the changed permissions for a file against the
bits set in the "force security mode"
parameter. Any bits that were changed that correspond to bits set
to '1' in this parameter are forced to be set.
Essentially, bits set in the "force security mode"
parameter may be treated as a set of bits that, when modifying security on a file, the
user has always set to be 'on'.
If not set explicitly this parameter is set to the same value as the
"force create mode" parameter to provide compatibility
with Samba 2.0.4 where the permission change facility was introduced.
To allow a user to modify all the user/group/world permissions on a file,
with no restrictions set this parameter to 000.
The "security mask" and
"force security mode" parameters
are applied to the change request in that order.
For a directory Samba will perform the same operations as described above
for a file except using the parameter "directory security mask"
instead of "security mask", and
"force directory security mode" parameter instead
of "force security mode".
The "directory security mask"
parameter by default is set to the same value as the "directory mask"
parameter and the "force directory security mode"
parameter by default is set to the same value as the
iurl("force directory mode")(smb.conf.5.html#forcedirectorymode) parameter
to provide compatibility with Samba 2.0.4 where the permission change facility was introduced.
In this way Samba enforces the permission restrictions that an administrator
can set on a Samba share, whilst still allowing users to modify the
permission bits within that restriction.
If you want to set up a share that allows users full control
in modifying the permission bits on their files and directories and
doesn't force any particular bits to be set 'on', then set the following
parameters in the smb.conf.5 file in
that share specific section :
security mask = 0777
force security mode = 0
directory security mask = 0777
force directory security mode = 0
As described, in Samba 2.0.4 the parameters :
create mask
force create mode
directory mask
force directory mode
were used instead of the parameters discussed here.
Interaction with the standard Samba file attribute mapping
----------------------------------------------------------
Samba maps some of the DOS attribute bits (such as "read only")
into the UNIX permissions of a file. This means there can be a
conflict between the permission bits set via the security dialog
and the permission bits set by the file attribute mapping.
One way this can show up is if a file has no UNIX read access
for the owner it will show up as "read only" in the standard
file attributes tabbed dialog. Unfortunately this dialog is
the same one that contains the security info in another tab.
What this can mean is that if the owner changes the permissions
to allow themselves read access using the security dialog, clicks
"OK" to get back to the standard attributes tab dialog, and
then clicks "OK" on that dialog, then NT will set the file
permissions back to read-only (as that is what the attributes
still say in the dialog). This means that after setting permissions
and clicking "OK" to get back to the attributes dialog you
should always hit "Cancel" rather than "OK" to ensure
that your changes are not overridden.

332
docs/textdocs/PRINTER_DRIVER2.txt
View File

@ -1,332 +0,0 @@
!==
!== PRINTER_DRIVER2.txt for Samba release 2.2.0-alpha1 23 Nov 2000
!==
==========================================================================
Gerald Carter <jerry@samba.org> 14 Sep 2000
===========================================================================
Introduction
============
Beginning with the 2.2.0 release, Samba now supports the native Windows
NT printing mechanisms implemented via MS-RPC (i.e. the SPOOLSS named
pipe). Previous versions of Samba only supported the LanMan printing
calls.
The additional functionality provided by the new SPOOLSS support
includes:
o Support for downloading printer driver files to
Windows 95/98/NT/2000 clients upon demand.
o Uploading of printer drivers via the Windows NT
Add Printer Wizard (APW) or the Imprints tool set
o Support for the native MS-RPC printing calls such
as StartDocPrinter, EnumJobs(), etc... (See the MSDN
documentation for more information on the Win32
printing API)
o Support for NT Access Control Lists (ACL) on
printer objects
o Improved support for printer queue manipulation through
the use of an internal database for spooled job information.
Configuration
=============
In order to support the uploading of printer driver files, you
must first configure a file share named [print$]. The name of
this share is hard coded in Samba's internals so the name is
very important (print$ is the service used by Windows NT
print servers to provide support for printer driver download.
<aside>
Previous versions of Samba recommended using a share named
[printer$]. This name was taken from the printer$ service
created by Windows 9x clients when a printer was shared.
(Windows 9x printer servers always have a printer$ service
which provides read-only access via no password in order to
support printer driver downloads).
However, the initial implementation allowed for a parameter
named 'printer driver location' to be used on a per share basis
to specify the location of the driver files associated with that
printer. Another parameter named 'printer driver' provided a
means of defining the printer driver name to be sent to the
client.
These parameters, including 'printer driver file', are being
depreciated and should not be used in new installations.
For more information on this change, you should refer to the
"Migration" section of this document.
</aside>
You should modify the server's smb.conf file to create the
following file share (of course, some of the parameter values,
such as 'path' are arbitrary and should be replaced with
appropriate values for your site):
[print$]
path = /usr/local/samba/printers
guest ok = yes
browseable = yes
read only = yes
write list = ntadmin
The 'write list' is used to allow administrative level user accounts
to have write access in order to update files on the share.
See the smb.conf(5) man page for more information on configuring
file shares.
The requirement for 'guest ok = yes' depends upon how your
site is configured. If users will be guaranteed to have
an account on the Samba host, then this is a non-issue.
[author's note: The non-issue is that if all your Windows
NT users are guarenteed to be authenticated by the Samba server
(such as a domain member server and the NT user has already
been validated by the Domain Controller in order to logon
to the Windows NT console), then guest access is not necessary.
Of course, in a workgroup environment where you just want
to be able to print without worrying about silly accounts
and security, then configure the share for gues access.
You'll probably want to add 'map to guest = Bad User'
in the [global] section as well. Make sure you understand
what this parameter does before using it though. --jerry]
In order for a Windows NT print server to support the
downloading of driver files by multiple client architectures,
it must create subdirectories within the [print$] service
which correspond to each of the supported client architectures.
Samba follows this model as well.
Next create the directory tree below the [print$] share for
each architecture you wish to support.
[print$]-----
|-W32X86 ; "Windows NT x86"
|-WIN40 ; "Windows 95/98"
|-W32ALPHA ; "Windows NT Alpha_AXP"
|-W32MIPS ; "Windows NT R4000"
|-W32PPC ; "Windows NT PowerPC"
+++++++++++++ ATTENTION! REQUIRED PERMISSIONS +++++++++++++++++
Currently, the connected user must have uid 0 in order to
successfully install a new printer driver. There are two
points of authorization in this process.
o Access permissions to add files to the [print$]
share. This access control is managed using
the same semantics as normal file shares.
(i.e. filesystem permissions, write list,
writeable, etc...)
o Authorization to add entries to
$SAMBA/var/locks/ntdrivers.tdb
Updates to this TDB are curently restricted
to the root account.
Therefore, you must be connected to the samba host as the
root user in order to add a new printer driver.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!== The Windows NT APW
Once you have created the required [print$] service and associated
subdirectories, simply log onto the Samba server using a root account
from a Windows NT 4.0 client. Navigate to the "Printers" folder
on the Samba server. You should see an initial listing of printers
that matches the printer shares defined on your Samba host.
<aside>
It is possible on a Windows NT print server to have printers
listed in the Printers folder which are not shared. Samba does
not make this distinction. By definition, the only printers of
which Samba is aware are those which are specified as shares in
smb.conf.
Another interesting side note is that Windows NT clients do
not use the SMB printer share, but rather can print directly
to any printer on another Windows NT host using MS-RPC. This
of course assumes that the printing client has the necessary
privileges on the remote host serving the printer. The default
permissions assigned by Windows NT to a printer gives the "Print"
permissions to the "Everyone" well-known group.
</aside>
The initial listing of printers in the Samba host's Printers
folder will have no printer driver assigned to them. The way
assign a driver to a printer is to view the Properties of the
printer and either
o Use the "New Driver..." button to install a new printer
driver, or
o Select a driver from the popup list of installed drivers.
Initially this list will be empty.
If you wish to install printer drivers for client operating
systems other than "Windows NT x86", you will need to use the
"Sharing" tab of the printer properties dialog.
Assuming you have connected with a root account, you will
also be able modify other printer properties such as
ACLs and device settings using this dialog box.
!== Imprints
The Imprints tool set provides a UNIX equivalent of the Windows
NT Add Printer Wizard. For complete information, please refer
to the Imprints web site at http://imprints.sourceforge.net/
as well as the documentation included with the imprints source
distribution. This section will only provide a brief introduction
to the features of Imprints.
What is Imprints?
Imprints is a collection of tools for supporting the goals of
o Providing a central repository information regarding
Windows NT and 95/98 printer driver packages
o Providing the tools necessary for creating the Imprints
printer driver packages.
o Providing an installation client which will obtain
and install printer drivers on remote Samba and Windows
NT 4 print servers.
Creating Printer Driver Packages
The process of creating printer driver packages is beyond
the scope of this document (refer to Imprints.txt also included
with the Samba distribution for more information). In short,
an Imprints driver package is a gzipped tarball containing the
driver files, related INF files, and a control file needed by the
installation client.
The Imprints server
The Imprints server is really a database server that may
be queried via standard HTTP mechanisms. Each printer entry
in the database has an associated URL for the actual
downloading of the package. Each package is digitally signed
via GnuPG which can be used to verify that package downloaded
is actually the one referred in the Imprints database. It is
**not** recommended that this security check be disabled.
The Installation Client
<aside>
More information regarding the Imprints installation client is available
in the Imprints-Client-HOWTO.ps file included with the imprints source
package.
</aside>
The Imprints installation client comes in two forms.
o a set of command line Perl scripts
o a GTK+ based graphical interface to the command
line perl scripts
The installation client (in both forms) provides a means
of querying the Imprints database server for a matching
list of known printer model names as well as a means to
download and install the drivers on remote Samba and Windows
NT print servers.
The basic installation process is in four steps and perl code
is wrapped around smbclient and rpcclient.
foreach (supported architecture for a given driver)
{
1. rpcclient: Get the appropriate upload directory
on the remote server
2. smbclient: Upload the driver files
3. rpcclient: Issues an AddPrinterDriver() MS-RPC
}
4. rpcclient: Issue an AddPrinterEx() MS-RPC to actually
create the printer
!== The printer driver name space problem
One of the problems encountered when implementing the Imprints
tool set was the name space issues between various supported
client architectures. For example, Windows NT includes a driver
named "Apple LaserWriter II NTX v51.8" and Windows 95 calls
its version of this driver "Apple LaserWriter II NTX"
The problem is how to know what client drivers have been
uploaded for a printer. As astute reader will remember that
the Windows NT Printer Properties dialog only includes space
for one printer driver name. A quick look in the Windows NT
4 system registry at
HKLM\System\CurrentControlSet\Control\Print\Environment
will reveal that Windows NT always uses the NT driver name.
The is ok as Windows NT always requires that at least the Windows
NT version of the printer driver is present. However, Samba
does not have the requirement internally. Therefore, how can
you use the NT driver name if is has not already been installed?
The way of sidestepping this limitation is to require that all
Imprints printer driver packages include both the Intel Windows
NT and 95/98 printer drivers and that NT driver is installed
first.
Migration to 2.2.x
=============================
Given that printer driver management has changed
(we hope improved :) ) in 2.2.0 over prior releases,
migration from an existing setup to 2.2.0 can follow
several paths.
<WARNING>
The following smb.conf parameters are considered to be
depreciated and will be removed soon. Do not use them
in new installations
'printer driver file' (G)
'printer driver' (S)
'printer driver location' (S)
</WARNING>
Here are the possible scenarios for supporting migration:
o If you does not desire the new Windows NT
print driver support, nothing needs to be done.
All existing parameters work the same.
o If you want to take advantage of NT printer
driver support but does not want to migrate the
9x drivers to the new setup, the leave the existing
printers.def file. When smbd attempts to locate a
9x driver for the printer in the TDB and fails it
will drop down to using the printers.def (and all
associated parameters). The make_printerdef tool
will also remain for backwards compatibility but will
be moved to the "this tool is the old way of doing it"
pile.
o If you instal a Windows 9x driver for a printer on
your Samba host (in the printing TDB), this information will
take precedence and the three old printing parameters
will be ignored (including print driver location).
o If you want to migrate an existing printers.def file into
the new setup, the current only solution is to use the
Windows NT APW to install the NT drivers and the 9x
drivers. (comment: this could possibly be scripted using
smbclient and rpcclient, but I haven't had time --jerry)
!== end of PRINTER_DRIVER2.txt =======================================
!=====================================================================

332
docs/textdocs/UNIX_INSTALL.txt
View File

@ -1,332 +0,0 @@
HOW TO INSTALL AND TEST SAMBA
=============================
STEP 0. Read the man pages. They contain lots of useful info that will
help to get you started. If you don't know how to read man pages then
try something like:
nroff -man smbd.8 | more
Other sources of information are pointed to by the Samba web
site, http://samba.org/samba.
STEP 1. Building the binaries
To do this, first run the program ./configure in the source
directory. This should automatically configure Samba for your
operating system. If you have unusual needs then you may wish to run
"./configure --help" first to see what special options you can enable.
Then type "make". This will create the binaries.
Once it's successfully compiled you can use "make install" to install
the binaries and manual pages. You can separately install the binaries
and/or man pages using "make installbin" and "make installman".
Note that if you are upgrading for a previous version of Samba you
might like to know that the old versions of the binaries will be
renamed with a ".old" extension. You can go back to the previous
version with "make revert" if you find this version a disaster!
STEP 2. The all important step
At this stage you must fetch yourself a coffee or other drink you find
stimulating. Getting the rest of the install right can sometimes be
tricky, so you will probably need it.
If you have installed samba before then you can skip this step.
STEP 3. Create the smb configuration file.
There are sample configuration files in the examples subdirectory in
the distribution. I suggest you read them carefully so you can see how
the options go together in practice. See the man page for all the
options.
The simplest useful configuration file would be something like this:
workgroup = MYGROUP
[homes]
guest ok = no
read only = no
which would allow connections by anyone with an account on the server,
using either their login name or "homes" as the service name. (Note
that I also set the workgroup that Samba is part of. See BROWSING.txt
for defails)
Note that "make install" will not install a smb.conf file. You need to
create it yourself. You will also need to create the path you specify
in the Makefile for the logs etc, such as /usr/local/samba.
Make sure you put the smb.conf file in the same place you specified in
the Makefile.
For more information about security settings for the [homes] share please
refer to the document UNIX_SECURITY.txt
STEP 4. Test your config file with testparm
It's important that you test the validity of your smb.conf file using
the testparm program. If testparm runs OK then it will list the loaded
services. If not it will give an error message.
Make sure it runs OK and that the services look resonable before
proceeding.
STEP 5. Starting the smbd and nmbd.
You must choose to start smbd and nmbd either as daemons or from
inetd. Don't try to do both! Either you can put them in inetd.conf
and have them started on demand by inetd, or you can start them as
daemons either from the command line or in /etc/rc.local. See the man
pages for details on the command line options. Take particular care
to read the bit about what user you need to be in order to start Samba.
In many cases you must be root.
The main advantage of starting smbd and nmbd as a daemon is that they
will respond slightly more quickly to an initial connection
request. This is, however, unlilkely to be a problem.
Step 5a. Starting from inetd.conf
NOTE; The following will be different if you use NIS or NIS+ to
distributed services maps.
Look at your /etc/services. What is defined at port 139/tcp. If
nothing is defined then add a line like this:
netbios-ssn 139/tcp
similarly for 137/udp you should have an entry like:
netbios-ns 137/udp
Next edit your /etc/inetd.conf and add two lines something like this:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd
netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
The exact syntax of /etc/inetd.conf varies between unixes. Look at the
other entries in inetd.conf for a guide.
NOTE: Some unixes already have entries like netbios_ns (note the
underscore) in /etc/services. You must either edit /etc/services or
/etc/inetd.conf to make them consistant.
NOTE: On many systems you may need to use the "interfaces" option in
smb.conf to specify the IP address and netmask of your interfaces. Run
ifconfig as root if you don't know what the broadcast is for your
net. nmbd tries to determine it at run time, but fails on some
unixes. See the section on "testing nmbd" for a method of finding if
you need to do this.
!!!WARNING!!! Many unixes only accept around 5 parameters on the
command line in inetd. This means you shouldn't use spaces between the
options and arguments, or you should use a script, and start the
script from inetd.
Restart inetd, perhaps just send it a HUP. If you have installed an
earlier version of nmbd then you may need to kill nmbd as well.
Step 5b. Alternative: starting it as a daemon
To start the server as a daemon you should create a script something
like this one, perhaps calling it "startsmb"
#!/bin/sh
/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/nmbd -D
then make it executable with "chmod +x startsmb"
You can then run startsmb by hand or execute it from /etc/rc.local
To kill it send a kill signal to the processes nmbd and smbd.
NOTE: If you use the SVR4 style init system then you may like to look
at the examples/svr4-startup script to make Samba fit into that system.
STEP 6. Try listing the shares available on your server
smbclient -L yourhostname
Your should get back a list of shares available on your server. If you
don't then something is incorrectly setup. Note that this method can
also be used to see what shares are available on other LanManager
clients (such as WfWg).
If you choose user level security then you may find that Samba requests
a password before it will list the shares. See the smbclient docs for
details. (you can force it to list the shares without a password by
adding the option -U% to the command line. This will not work with
non-Samba servers)
STEP 7. try connecting with the unix client. eg:
smbclient //yourhostname/aservice
Typically the "yourhostname" would be the name of the host where you
installed smbd. The "aservice" is any service you have defined in the
smb.conf file. Try your user name if you just have a [homes] section
in smb.conf.
For example if your unix host is bambi and your login name is fred you
would type:
smbclient //bambi/fred
STEP 8. Try connecting from a dos/WfWg/Win95/NT/os-2 client. Try
mounting disks. eg:
net use d: \\servername\service
Try printing. eg:
net use lpt1: \\servername\spoolservice
print filename
Celebrate, or send me a bug report!
WHAT IF IT DOESN'T WORK?
========================
If nothing works and you start to think "who wrote this pile of trash"
then I suggest you do step 2 again (and again) till you calm down.
Then you might read the file DIAGNOSIS.txt and the FAQ. If you are
still stuck then try the mailing list or newsgroup (look in the README
for details). Samba has been successfully installed at thousands of
sites worldwide, so maybe someone else has hit your problem and has
overcome it. You could also use the WWW site to scan back issues of
the samba-digest.
When you fix the problem PLEASE send me some updates to the
documentation (or source code) so that the next person will find it
easier.
DIAGNOSING PROBLEMS
===================
If you have instalation problems then go to DIAGNOSIS.txt to try to
find the problem.
SCOPE IDs
=========
By default Samba uses a blank scope ID. This means all your windows
boxes must also have a blank scope ID. If you really want to use a
non-blank scope ID then you will need to use the -i <scope> option to
nmbd, smbd, and smbclient. All your PCs will need to have the same
setting for this to work. I do not recommend scope IDs.
CHOOSING THE PROTOCOL LEVEL
===========================
The SMB protocol has many dialects. Currently Samba supports 5, called
CORE, COREPLUS, LANMAN1, LANMAN2 and NT1.
You can choose what maximum protocol to support in the smb.conf
file. The default is NT1 and that is the best for the vast majority of
sites.
In older versions of Samba you may have found it necessary to use
COREPLUS. The limitations that led to this have mostly been fixed. It
is now less likely that you will want to use less than LANMAN1. The
only remaining advantage of COREPLUS is that for some obscure reason
WfWg preserves the case of passwords in this protocol, whereas under
LANMAN1, LANMAN2 or NT1 it uppercases all passwords before sending them,
forcing you to use the "password level=" option in some cases.
The main advantage of LANMAN2 and NT1 is support for long filenames with some
clients (eg: smbclient, Windows NT or Win95).
See the smb.conf manual page for more details.
Note: To support print queue reporting you may find that you have to
use TCP/IP as the default protocol under WfWg. For some reason if you
leave Netbeui as the default it may break the print queue reporting on
some systems. It is presumably a WfWg bug.
PRINTING FROM UNIX TO A CLIENT PC
=================================
To use a printer that is available via a smb-based server from a unix
host you will need to compile the smbclient program. You then need to
install the script "smbprint". Read the instruction in smbprint for
more details.
There is also a SYSV style script that does much the same thing called
smbprint.sysv. It contains instructions.
LOCKING
=======
One area which sometimes causes trouble is locking.
There are two types of locking which need to be performed by a SMB
server. The first is "record locking" which allows a client to lock a
range of bytes in a open file. The second is the "deny modes" that are
specified when a file is open.
Samba supports "record locking" using the fcntl() unix system
call. This is often implemented using rpc calls to a rpc.lockd process
running on the system that owns the filesystem. Unfortunately many
rpc.lockd implementations are very buggy, particularly when made to
talk to versions from other vendors. It is not uncommon for the
rpc.lockd to crash.
There is also a problem translating the 32 bit lock requests generated
by PC clients to 31 bit requests supported by most
unixes. Unfortunately many PC applications (typically OLE2
applications) use byte ranges with the top bit set as semaphore
sets. Samba attempts translation to support these types of
applications, and the translation has proved to be quite successful.
Strictly a SMB server should check for locks before every read and
write call on a file. Unfortunately with the way fcntl() works this
can be slow and may overstress the rpc.lockd. It is also almost always
unnecessary as clients are supposed to independently make locking
calls before reads and writes anyway if locking is important to
them. By default Samba only makes locking calls when explicitly asked
to by a client, but if you set "strict locking = yes" then it will
make lock checking calls on every read and write.
You can also disable by range locking completely using "locking =
no". This is useful for those shares that don't support locking or
don't need it (such as cdroms). In this case Samba fakes the return
codes of locking calls to tell clients that everything is OK.
The second class of locking is the "deny modes". These are set by an
application when it opens a file to determine what types of access
should be allowed simultaneously with its open. A client may ask for
DENY_NONE, DENY_READ, DENY_WRITE or DENY_ALL. There are also special
compatability modes called DENY_FCB and DENY_DOS.
You can disable share modes using "share modes = no". This may be
useful on a heavily loaded server as the share modes code is very
slow. See also the FAST_SHARE_MODES option in the Makefile for a way
to do full share modes very fast using shared memory (if your OS
supports it).
MAPPING USERNAMES
=================
If you have different usernames on the PCs and the unix server then
take a look at the "username map" option. See the smb.conf man page
for details.
OTHER CHARACTER SETS
====================
If you have problems using filenames with accented characters in them
(like the German, French or Scandinavian character sets) then I
recommmend you look at the "valid chars" option in smb.conf and also
take a look at the validchars package in the examples directory.

939
docs/textdocs/samba-pdc-faq.txt
View File

@ -1,939 +0,0 @@
The Samba 2.2 PDC FAQ
David Bannon
La Trobe University
_________________________________________________________________
_________________________________________________________________
Comments, corrections and additions to <D.Bannon@latrobe.edu.au>
This is the FAQ for Samba 2.2 as an NTDomain controller. This document
is derived from the origional FAQ that was built and maintained by
Gerald Carter from the early days of Samba NTDomain development up
until recently. It is now being updated as significent changes are
made to 2.2.0.
Please note it does not apply to Samba2.2alpha0, Samba2.2alpha1, Samba
2.0.7, TNG nor HEAD branch.
I'll repeat, it does not apply to the current snapshot [ftp
mirror]:/pub/samba/alpha/samba-2.2.0-alpha1.tar.gz, only to the to the
current cvs.
Also available is a Samba 2.2 PDC HowTo that takes you, step by step,
over the process of setting up a very basic Samba 2.2 Primary Domain
Controller
Note: Please read the Introduction for the current state of play.
Table of Contents
1. Introduction
State of Play
Introduction
2. General Information
What can we do ?
What can Samba Primary Domain Controller (PDC) do ?
Can I have a Windows 2000 client logon to a Samba
controlled domain?
What's the status of print spool (spoolss) support in the
NTDOM code?
CVS
What are the different Samba branches available in CVS ?
What are the CVS commands ?
3. Establishing Connections
How do I get my NT4 or W2000 Workstation to login to the
Samba controlled Domain?
What is a 'machine account' ?
"The machine account for this computer either does not
exist or is not accessable."
How do I create machine accounts manually ?
I cannot include a '$' in a machine name.
I get told "You already have a connection to the
Domain...." when creating a machine account.
I get told "Cannot join domain, the credentials supplied
conflict with an existing set.."
"The system can not log you on (C000019B)...."
4. User Account Management
Domain Admins
How do I configure an account as a domain administrator?
Profiles
Why is it bad to set "logon path = \\%N\%U\profile" in
smb.conf? ?
Why are all the users listed in the "domain admin users"
using the same profile?
The roaming profiles do not seem to be updating on the
server.
Policies
What are 'Policies' ?.
I can't get system policies to work.
What about Windows NT Policy Editor ?
Can Win95 do Policies ?
Passwords
What is password sync and should I use it ?
How do I get remote password (unix and SMB) changing
working ?
5. Miscellaneous
What editor can I use in DOS/Windows that won't mess with
my unix EOF
How do I get 'User Manager' and 'Server Manager'
The time setting from a Samba server does not work.
"trust account xxx should be in DOMAIN_GROUP_RID_USERS"
How do I get my samba server to become a member ( not PDC )
of an NT domain?
6. Troubleshooting and Bug Reporting
Diagnostic tools
What are some diagnostics tools I can use to debug the
domain logon process and where can I find them?
How do I install 'Network Monitor' on an NT Workstation or
a Windows 9x box?
What other help can I get ?
URLs and similar
How do I get help from the mailing lists ?
How do I get off the mailing lists ?
_________________________________________________________________
Chapter 1. Introduction
State of Play
It should be noted that 2.2.0 in its pre-release form still has a few
problems, I'll try and keep this section current while things are
still dynamic. At the time of this update (December 15, 2000) the
current state of play is :
Comments here about W2K joining the domain apply only to Samba 2.2
from the CVS after November 27th. The 'snapshot' release
Samba2.2alpha1 does not work !!! See below on how to get a CVS tree.
Known Bug !W2K machines will not successfully join a domain with a
name that is made up from an even number of characters. Yep, thats
right ! BIOTEST is OK as is MYDOMAI but MYDOMAIN will not work until
this bug is fixed. Hmm.., we believe that this bug is fixed, but see
below.
Known Bug !After some bugs were fixed just before Christmas, W2K SP1
machines cannot join the domain. Expected to be fixed early in the new
year. Whats that ? yeah, samba developers have a Christmas break too !
Know Bug !NTs (and possibly W2K ?) are not told the logged on user is
a domain admin if the parameter "domain admin users = user" is used.
The alternative, "domain admin group" does work. See the HowTo.
Client Side creation of Machine accounts does work but is not
complete. Firstly, the add user script runs as the user who's name was
entered, not as root. Secondly, the machine name passed to the script
(%U) has an underscore at the end, not a '$'. One alternative is to
use %m and add the $. This method is documented in the HowTo. And
thirdly, it does not work with NT4ws.
A W2K machine can join the domain. See the HowTo which explains the
process. The methods described are 'work arounds' and should be
regarded as temporary. Although I (drb) have tested these procedures a
number of people have had difficulty so there may be other issues at
work. JFM is aware of these problems and will attend to them when he
can.
A Domain Admin account is required and at present it appears that only
root is a suitable candidate.
Much of the related code does work. For example, if an NT is removed
from the domain and then rejoins, the Create a Computer Account in the
Domain dialog will let you reset the smbpasswd. That is you don't need
to do it from the unix box. However, at the present, you do need to
have root as an administrator and use the root user name and password.
Actually I'm not sure that last paragraph is correct ....
Policies do work on a W2K machine. MS says that recent builds of W2K
dont observe an NT policy but it appears it does in 'legacy' mode.
_________________________________________________________________
Introduction
This FAQ was origionally compiled by Jerry Carter (gc) chiefly dealing
with the 'old head' version of Samba and its NTDomain facilities. It
is being rewritten by David Bannon (drb) so that it addresses more
accurately the Samba 2.2 planned for release late 2000.
This document probably still contains some material that does not
apply to Samba 2.2 but most (all?) of the really misleading stuff has
been removed. Some issues are not dealt with or are dealt with badly.
Please send corrections and additions to David Bannon at
D.Bannon@latrobe.edu.au
Hopefully, as we all become familiar with the Samba 2.2 as a PDC this
document will become much more usefull.
_________________________________________________________________
Chapter 2. General Information
What can we do ?
What can Samba Primary Domain Controller (PDC) do ?
If you wish to have Samba act as a PDC for Windows NT 3.51.and 4.0 or
W2000 client, then you will need to obtain the 2.2.0 version,
currently in pre-release. Release of a stable, full featured Samba PDC
is currently slated for version 3.0.
The following is a list of included features currently in Samba 2.2:
* The ability to act as a limited PDC for Windows NT and W2000
clients. This includes adding NT and W2K machines to the domain
and authenticating users logging into the domain.
* Domain account can be viewed using the User Manager for Domains
????
* Viewing resources on the Samba PDC via the Server Manager for
Domains from the NT client. ??
* Windows 95 clients will allow user level security to be set but
will not currently allow browsing of accounts.
* Machine account password updates.
* Changing of user passwords from an NT client.
* Partial support for Windows NT group and username mapping.
* Support for a LDAP password database backend.
* Printing.
These things are note expected to work in the forseeable future
* Trust relationships
* PDC and BDC integration
* Windows NT ACLs (on the Samba shares)
* Offer a list of domain users to User Manager for Domains (or the
Security Tab etc).
_________________________________________________________________
Can I have a Windows 2000 client logon to a Samba controlled domain?
The 2.2 release branch of Samba supports Windows 2000 domain clients
in legacy mode, ie as if the PDC is a NTServer, not a W2K server.
_________________________________________________________________
What's the status of print spool (spoolss) support in the NTDOM code?
The implementation of support for SPOOLSS pipe is complete and it will
be available in the 2.2.0 release. This means that Samba will support
the automatic downloading of printer drivers for Windows NT clients
just as it currently does for Windows 9x clients.
_________________________________________________________________
CVS
CVS is a programme (publically available) that the Samba developers
use to maintain the central source code. Non developers can get access
to the source in a read only capacity. Many flavours of unix now
arrive with cvs installed.
_________________________________________________________________
What are the different Samba branches available in CVS ?
You can find out more about obtaining Samba's via anonymous CVS from
http://pserver.samba.org/samba/cvs.html".
There are basically four branches to watch at the moment :
HEAD
Samba 3.0 ? This code boasts all the main development work in
Samba. Two things that most people are not aware of which live
in the HEAD branch code are winbind NSS module and Tim Potter's
VFS implementation. Due to its developmental nature, its not
really suitable for production work.
SAMBA_2_0
This branch contains the current stable release release. At the
moment it contains 2.0.7, a version that will do some limited
PDC stuff. If you are really going to do PDC things then I
(drb) suggest that you consider 2.2 instead.
SAMBA_2_2
The next stable release, currently in a 'alpha' form. It
provides the Samba developers, testers and interested people
with an approximation of what is to come. This document
addresses only SAMBA_2_2.
SAMBA_TNG
This branch is no longer maintained from the Samba sites.
Please see http://www.samba-tng.org/. It has been requested
that questions about TNG are not posted to the regular Samba
mailing lists including samba-ntdom and samba-technical.
_________________________________________________________________
What are the CVS commands ?
See http://pserver.samba.org/samba/cvs.html
To get the Samba 2.2 version, tag SAMBA_2_2 you would do :
* For example : cd /usr/local/src/
* cvs -d :pserver:cvs@pserver.samba.org:/cvsroot login
* When prompted enter a password of cvs
* cvs -d :pserver:cvs@pserver.samba.org:/cvsroot co -r SAMBA_2_2
samba
Then to update that directory at some later time,
* cd /usr/local/src/samba
* cvs -d :pserver:cvs@pserver.samba.org:/cvsroot login
* When prompted enter a password of 'cvs'.
* cvs update -d -P
_________________________________________________________________
Chapter 3. Establishing Connections
How do I get my NT4 or W2000 Workstation to login to the Samba controlled
Domain?
There is a comprehensive Samba PDC HowTo accessable from the samba web
site under 'Documentation'. Its currently located at
http://bioserve.latrobe.edu.au/samba. Read it.
_________________________________________________________________
What is a 'machine account' ?
Every NT, W2K or Samba machine that joins a Samba controlled domain
must be known to the Samba PDC. There are two entries required, one in
(typically) /etc/passwd and the other in (typically)
/usr/local/samba/private/smbpasswd. Under some circumstances these
entries are made manually, the HowTo discusses ways of creating them
automatically.
_________________________________________________________________
"The machine account for this computer either does not exist or is not
accessable."
When I try to join the domain I get the message "The machine account
for this computer either does not exist or is not accessable". Whats
wrong ?
This problem is caused by the PDC not having a suitable machine
account. If you are using the add user script = method to create
accounts then this would indicate that it has not worked. Ensure the
domain admin user system is working.
Alternatively if you are creating account entries manually then they
have not been created correctly. Make sure that you have the entry
correct for the machine account in smbpasswd file on the Samba PDC. If
you added the account using an editor rather than using the smbpasswd
utility, make sure that the account name is the machine netbios name
with a '$' appended to it ( ie. computer_name$ ). There must be an
entry in both /etc/passwd and the smbpasswd file. Some people have
reported that inconsistent subnet masks between the Samba server and
the NT client have caused this problem. Make sure that these are
consistent for both client and server.
_________________________________________________________________
How do I create machine accounts manually ?
This was the only option until recently, now in version 2.2 better
means are available. You might still need to do it manually for a
couple of reasons. A machine account consists of two entries (assuming
a standard install and /etc/passwd use), one in /etc/passwd and the
other in /usr/local/samba/private/smbpasswd. The /etc/passwd entry
will list the machine name with a $ appended, won't have a passwd,
will have a null shell and no home directory. For example a machine
called 'doppy' would have an /etc/passwd entry like this :
doppy$:x:505:501:NTMachine:/dev/null:/bin/false
On a linux system for example, you would typically add it like this :
adduser -g machines -c NTMachine -d /dev/null -s /bin/false -n doppy$
Then you need to add that entry to smbpasswd, assuming you have a
suitable path to the smbpasswd programme, do this :
smbpasswd -a -m doppy$
The entry will be created with a well known password, so any machine
that says its doppy could join the domain as long as it gets in first.
So don't create the accounts any earlier than you need them.
_________________________________________________________________
I cannot include a '$' in a machine name.
A 'machine name' in (typically) /etc/passwd consists of the machine
name with a '$' appended. FreeBSD (and other BSD systems ?) won't
create a user with a '$' in their name.
The problem is only in the program used to make the entry, once made,
it works perfectly. So create a user without the '$' and use vipw to
edit the entry, adding the '$'. Or create the whole entry with vipw if
you like, make sure you use a unique uid !
_________________________________________________________________
I get told "You already have a connection to the Domain...." when creating a
machine account.
This happens if you try to create a machine account from the machine
itself and use a user name that does not work (for whatever reason)
and then try another (possibly valid) user name. Exit out of the
network applet to close the initial connection and try again.
Further, if the machine is a already a 'member of a workgroup' that is
the same name as the domain you are joining (bad idea) you will get
this message. Change the workgroup name to something else, it does not
matter what, reboot, and try again.
_________________________________________________________________
I get told "Cannot join domain, the credentials supplied conflict with an
existing set.."
This is the same basic problem as mentioned above, "You already have a
connection..."
_________________________________________________________________
"The system can not log you on (C000019B)...."
I joined the domain successfully but after upgrading to a newer
version of the Samba code I get the message, "The system can not log
you on (C000019B), Please try a gain or consult your system
administrator" when attempting to logon.
This occurs when the domain SID stored in private/WORKGROUP.SID is
changed. For example, you remove the file and smbd automatically
creates a new one. Or you are swapping back and forth between versions
2.0.7, TNG and the HEAD branch code (not recommended). The only way to
correct the problem is to restore the original domain SID or remove
the domain client from the domain and rejoin.
_________________________________________________________________
Chapter 4. User Account Management
Domain Admins
How do I configure an account as a domain administrator?
See the NTDom HowTo.
_________________________________________________________________
Profiles
Why is it bad to set "logon path = \\%N\%U\profile" in smb.conf? ?
Sometimes Windows clients will maintain a connection to the \\homes\ (
or [%U] ) share even after the user has logged out. Consider the
following scenario.
* user1 logs into the Windows NT machine. Therefore the [homes]
share is set to \\server\user1.
* user1 works for a while and then logs out.
* user2 logs into the same Windows NT machine.
However, since the NT box has maintained a connection to [homes] which
was previously set to \\server\user1, when the operating system
attempts to get the profile and if it can read users1's profile, will
get it otherwise it will return an error. You get the picture.
A better solution is to use a separate [profiles] share and set the
"logon path = \\%N\profiles\%U"
Note: Is this still a problem ????
_________________________________________________________________
Why are all the users listed in the "domain admin users" using the same
profile?
You are using a very very old development version of Samba. Upgrade.
_________________________________________________________________
The roaming profiles do not seem to be updating on the server.
There can be several reasons for this.
Make sure that the time on the client and the PDC are synchronized.
You can accomplish this by executing a net time \\server /set /yes
replacing server with the name of your PDC (or another synchronized
SMB server). See about Setting Time
Make sure that the logon path is writeable by the user and make sure
that the connection to the logon path location is by the current user.
Sometimes Windows client do not drop the connection immediately upon
logoff.
Some people have reported that the logon path location should also be
browseable. I (GC) have yet to emperically verify this, but you can
try.
_________________________________________________________________
Policies
What are 'Policies' ?.
When a user logs onto the domain via a client machine, the PDC sends
the client machine a list of things contained in the 'policy' (if it
exists). This list may do things like suppress a splach screen, format
the dates the way you like them or perhaps remove locally stored
profiles.
On a samba PDC this list is obtained from a file called ntconfig.pol
and located in the [netlogon]share. The file is created with a policy
editor and must be readable by anyone and writeable by only root. See
below for how to get a suitable editor.
_________________________________________________________________
I can't get system policies to work.
There are two possible reasons for system policies not functioning
correctly. Make sure that you have the following parameters set in
smb.conf
[netlogon]
....
locking = no
public = no
browseable = yes
....
A policy file must be in the [netlogon] share and must be readable by
everyone and writeable by only root. The file must be created by an
NTServer Policy Editor.
Last time I (drb) looked in the source, it was looking for
ntconfig.pol first then several other combinations of upper and lower
case. People have reported success using NTconfig.pol, NTconfig.POL
and ntconfig.pol. These are the case settings that I (GC) use with the
filename ntconfig.pol
case sensitive = no
case preserve = yes
default case = yes
_________________________________________________________________
What about Windows NT Policy Editor ?
To create or edit ntconfig.pol you must use the NT Server Policy
Editor, poledit.exe which is included with NT Server but not NT
Workstation. There is a Policy Editor on a NTws but it is not suitable
for creating Domain Policies. Further, although the Windows 95 Policy
Editor can be installed on an NT Workstation/Server, it will not work
with NT policies because the registry key that are set by the policy
templates. However, the files from the NT Server will run happily
enough on an NTws. You need poledit.exe, common.adm and winnt.adm. It
is convenient to put the two *.adm files in c:\winnt\inf which is
where the binary will look for them unless told otherwise. Note also
that that directory is 'hidden'.
The Windows NT policy editor is also included with the Service Pack 3
(and later) for Windows NT 4.0. Extract the files using
servicepackname /x, ie thats Nt4sp6ai.exe /x for service pack 6a. The
policy editor, poledt.exe and the associated template files (*.adm)
should be extracted as well. It is also possible to downloaded the
policy template files for Office97 and get a copy of the policy
editor. Another possible location is with the Zero Administration Kit
available for download from Microsoft.
_________________________________________________________________
Can Win95 do Policies ?
Install the group policy handler for Win9x to pick up group policies.
Look on the Win98 CD in \tools\reskit\netadmin\poledit. Install group
policies on a Win9x client by double-clicking grouppol.inf. Log off
and on again a couple of times and see if Win98 picks up group
policies. Unfortunately this needs to be done on every Win9x machine
that uses group policies....
If group policies don't work one reports suggests getting the updated
(read: working) grouppol.dll for Windows 9x. The group list is grabbed
from /etc/group.
_________________________________________________________________
Passwords
What is password sync and should I use it ?
NTws users can change their domain password by pressing Ctrl-Alt-Del
and choosing 'Change Password'. By default however, this does not
change the unix password (typically in /etc/passwd or /etc/shadow). In
lots of situations thats OK, for example :
* The server is only accessible to the user via samba.
* Pam_smb or similar is installed so other applications still refer
to the samba password.
But sometimes you really do need to maintain two seperate password
databases and there are good reasons to keep then in sync. Trying to
explain to users that they need to change their passwords in two
seperate places or use two seperate passwords is not fun.
However do understand that setting up password sync is not without
problems either. The chief difficulty is the interface between Samba
and the passwd command, it can be a fiddle to set up and if the
password the user has entered fails, the resulting errors are
ambiguously reported and the user is confused. Further, you need to
take steps to ensure that users only ever change their passwords via
samba (or use smbpasswd), otherwise they will only be changing the
unix password.
_________________________________________________________________
How do I get remote password (unix and SMB) changing working ?
Have a practice changing a user's password (as root) to see what
discussion takes place and change the text in the 'passwd chat' line
below as necessary. The line as shown works for recent RH Linux but
most other systems seem to like to do something different. The '*' is
a wild card and will match anything (or nothing).
Add these lines to smb.conf under [Global]
unix password sync = true
passwd program = /usr/bin/passwd %u
passwd chat = *password* %n\n *password* %n\n *successful*
As mentioned above, the change to the unix password happens as root,
not as the user, as is indicated in ~/smbd/chgpasswd.c If you are
using NIS, the Samba server must be running on the NIS master machine.
_________________________________________________________________
Chapter 5. Miscellaneous
What editor can I use in DOS/Windows that won't mess with my unix EOF
There are a number of Windows or DOS based editors that will
understand, and leave intact, the unix eof (as opposed to a DOS
CL/LF). List members suggested :
* UltraEdit at www.ultraedit.com
* VI for windows at home.snafu.de/ramo/WinViEn.htm
* The author prefers PFE at www.lancs.ac.uk/people/cpaap/pfe/ but
its no longer being developed...
_________________________________________________________________
How do I get 'User Manager' and 'Server Manager'
Since I don't need to buy an NT Server CD now, how do I get the 'User
Manager for Domains', the 'Server Manager' ?
Microsoft distributes a version of these tools called nexus for
installation on Windows 95 systems. The tools set includes
* Server Manager
* User Manager for Domains
* Event Viewer
Click here to download the archived file
ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE
The Windows NT 4.0 version of the 'User Manager for Domains' and
'Server Manager' are available from Microsoft via ftp from
ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE
_________________________________________________________________
The time setting from a Samba server does not work.
If it works OK when you log on as Domain Admin then the problem is
that ordinary users don't have permission to change the time. (The
system is running with their permission at logon time.) This is not a
Samba problem, you will have the same problem where ever you connect.
You can give 'everyone' permission to change the time from the User
Manager.
Anyone know what the registry settings are so this could be done with
a Policy ?
_________________________________________________________________
"trust account xxx should be in DOMAIN_GROUP_RID_USERS"
I keep getting the message "trust account xxx should be in
DOMAIN_GROUP_RID_USERS." in the logs. What do I need to do?
You are using one of the old development versions. Upgrade. (The
message is unimportant, was a reminder to a developer)
_________________________________________________________________
How do I get my samba server to become a member ( not PDC ) of an NT domain?
In a domain that has a number of servers you only need one password
database. The machines that don't have their own ask the PDC to check
for them. This will work fine for a domain controlled by either a
Samba or NT machine. The following lines in smb.conf are typical,
'password server' points to the samba machine (or an NT) that has the
password list :
[global]
...
security = domain
workgroup = { Put your domain name here }
password server = { Put the ip of the PDC here }
encrypt passwords = yes
...
The samba server in question will have to 'join the domain', that
requires the domain controller to have a machine account for it. This
is no different to the machine account requirements to allow a NTws to
join the domain. For example, if we want a unix box called sleepy to
ask the PDC called grumpy to do its authentication then grumpy will
need an entry in its smbpasswd (assuming it's also samba) that starts
with sleepy$. It would have to be created manually.
If the domain is controlled by an NTServer then the "Server Manager
for Domains" tool must be used to add 'sleepy' to the domain list.
In either case we then join the domain. If the domain is called forest
then on sleepy we would join the domain by typing :
smbpasswd -j forest
Note that the directory where the smbpasswd file would be located
should exist as this is where smbd will generate the MACHINE.SID file.
This might be /usr/local/samba/private/FOREST.SLEEPY.SID and it
contains the trust account password for the domain member. The
permissions are (and should remain) "rw-------
Note the Samba Servers without the password list will most likely
still need an account for each user, this means a line in its
/etc/passwd. Because authentication is being handled at the domain
level the /etc/passwd line does not need a password. If the shares
being offered are not user specific, ie a common (read only ?) area or
perhaps just printing then the user's /etc/passwd does not need a home
directory. A typical line in /etc/passwd for a server that allows
domain users to connect to the samba shares but does not offer a home
share ('cos that's on the PDC) and does not allow logon to the unix
prompt would be like this :
jblow:x:542:100:Joe Blow:/dev/null:/bin/false
* When removing those 'dummy' users, watch the 'remove user'
scripts, some OS think they should remove a users directory even
when its not owned by the user !
* The username map = parameter might help you to avoid having all
those accounts created.
* You should investigate the smb.conf parameter 'add user script',
it will be used to create accounts on secondary servers when that
account already exists on the PDC. Very nice. Something like :
[Global]
....
add user script = /usr/sbin/adduser -n -g users -c User -d /dev/null -s /bi
n/false %U
....
_________________________________________________________________
Chapter 6. Troubleshooting and Bug Reporting
Diagnostic tools
What are some diagnostics tools I can use to debug the domain logon process
and where can I find them?
One of the best diagnostic tools for debugging problems is Samba
itself. You can use the -d option for both smbd and nmbd to specifiy
what 'debug level' at which to run. See the man pages on smbd, nmbd
and smb.conf for more information on debugging options. The debug
level can range from 1 (the default) to around 100 but a debug level
of about 20 will normally help you find any errors that samba is
encountering. Another helpful method of debugging is to compile samba
using the gcc -g flag. This will include debug information in the
binaries and allow you to attch gdb to the running smbd / nmbd
process. In order to attach gdb to an smbd process for an NT
workstation, first get the workstation to make the connection.
Pressing ctrl-alt-delete and going down to the domain box is
sufficient (at least, on the first time you join the domain) to
generate a 'LsaEnumTrustedDomains'. Thereafter, the workstation
maintains an open connection, and therefore there will be an smbd
process running (assuming that you haven't set a really short smbd
idle timeout) So, in between pressing ctrl alt delete, and actually
typing in your password, you can gdb attach and continue.
Some usefull samba commands worth investigating:
* testparam | more
* smbclient -L //{netbios name of server}
An SMB enabled version of tcpdump is available from
ftp://samba.org/pub/samba/tcpdump-smb/
Capconvert is a small C program for translating output from
tcpdump-smb to CAP format that can be read by netmon. You will need to
use the raw output from tcp dump ( ie. tcpdump -w output.dump ). Good
news! Now you can convert Solaris' snoop output as well. The C source
code for snoop2cap is available for download.
For tracing things on the Microsoft Windows NT, Network Monitor (aka.
netmon) is available on the Microsoft Developer Network CD's, the
Windows NT Server install CD and the SMS CD's. The version of netmon
that ships with SMS allows for dumping packets between any two
computers (ie. placing the network interface in promiscuous mode). The
version on the NT Server install CD will only allow monitoring of
network traffic directed to the local NT box and broadcasts on the
local subnet.
_________________________________________________________________
How do I install 'Network Monitor' on an NT Workstation or a Windows 9x box?
Installing netmon on an NT workstation requires a couple of steps. The
following are for installing Netmon V4.00.349, which comes with
Microsoft Windows NT Server 4.0, on Microsoft Windows NT Workstation
4.0. The process should be similar for other version of Windows NT /
Netmon. You will need both the Microsoft Windows NT Server 4.0 Install
CD and the Workstation 4.0 Install CD.
Initially you will need to install 'Network Monitor Tools and Agent'
on the NT Server. To do this
* Goto Start - Settings - Control Panel - Network - Services - Add
* Select the 'Network Monitor Tools and Agent' and click on 'OK'.
* Click 'OK' on the Network Control Panel.
* Insert the Windows NT Server 4.0 install CD when prompted.
At this point the Netmon files should exist in
%SYSTEMROOT%\System32\netmon\*.*. Two subdirectories exist as well,
parsers\ which contains the necessary DLL's for parsing the netmon
packet dump, and captures\.
In order to install the Netmon tools on an NT Workstation, you will
first need to install the 'Network Monitor Agent' from the Workstation
install CD.
* Goto Start - Settings - Control Panel - Network - Services - Add
* Select the 'Network Monitor Agent' and click on 'OK'.
* Click 'OK' on the Network Control Panel.
* Insert the Windows NT Workstation 4.0 install CD when prompted.
Now copy the files from the NT Server in
%SYSTEMROOT%\System32\netmon\*.* to %SYSTEMROOT%\System32\netmon\*.*
on the Workstation and set permissions as you deem appropriate for
your site. You will need administrative rights on the NT box to run
netmon.
To install Netmon on a Windows 9x box install the network monitor
agent from the Windows 9x CD (\admin\nettools\netmon). There is a
readme file located with the netmon driver files on the CD if you need
information on how to do this. Copy the files from a working Netmon
installation.
_________________________________________________________________
What other help can I get ?
There are many sources of information available in the form of mailing
lists, RFC's and documentation. The docs that come with the samba
distribution contain very good explanations of general SMB topics such
as browsing.
_________________________________________________________________
URLs and similar
* Home of Samba site http://samba.org. We have a mirror near you !
* The Development document on the Samba mirrors might mention your
problem. If so, it might mean that the developers are working on
it.
* Ignacio Coupeau has a very comprehesive look at LDAP with Samba at
http://www.unav.es/cti/ldap-smb-howto.html Be a little carefull
however, I suspect that it does not specificly address samba
2.2.x. The HEAD pre-2.1 may possibly be the best stream to look
at.
* Lars Kneschke's site covers Samba-TNG at
http://www.kneschke.de/projekte/samba_tng, but again, a lot of it
does not apply to the main stream Samba.
* See how Scott Merrill simulates a BDC behaviour at
http://www.skippy.net/linux/smb-howto.html.
* Although 2.0.7 has almost had its day as a PDC, I (drb) will keep
the 2.0.7 PDC pages at http://bioserve.latrobe.edu.au/samba going
for a while yet.
* Misc links to CIFS information http://samba.org/cifs/
* NT Domains for Unix http://mailhost.cb1.com/~lkcl/ntdom/
* FTP site for older SMB specs:
ftp://ftp.microsoft.com/developr/drg/CIFS/
There are a number of documents that no longer appear to live at their
origional home. Any one know where the following may be found ?
* CIFS/E Browser Protocol draft-leach-cifs-browser-spec-00.txt
* CIFS Remote Administration Protocol
draft-leach-cifs-rap-spec-00.txt
* CIFS Logon and Pass Through Authentication
draft-leach-cifs-logon-spec-00.txt
* A Common Internet File System (CIFS/1.0) Protocol
draft-leach-cifs-v1-spec-01.txt
* CIFS Printing Specification draft-leach-cifs-print-spec-00.txt
* RFC1001 (March '87) Protocol standard for a NetBIOS service on a
TCP/UDP transport: Concepts and methods.
http://ds.internic.net/rfc/rfc1001.txt
* RFC1002 (March '87) Protocol standard for a NetBIOS service on a
TCP/UDP transport: Detailed specifications.
http://ds.internic.net/rfc/rfc1002.txt
* Microsoft's main CIFS page:
http://www.microsoft.com/workshop/networking/cifs/
_________________________________________________________________
How do I get help from the mailing lists ?
There are a number of Samba related mailing lists. Go to
http://samba.org, click on your nearest mirror and then click on
Support and then click on Samba related mailing lists.
For questions relating to Samba TNG go to http://www.samba-tng.org/ It
has been requested that you don't post questions about Samba-TNG to
the main stream Samba lists.
If you post a message to one of the lists please observe the following
guide lines :
* Always remember that the developers are volunteers, they are not
paid and they never guarantee to produce a particular feature at a
particular time. Any time lines are 'best guess' and nothing more.
* Always mention what version of samba you are using and what
operating system its running under. You should probably list the
relevant sections of your smb.conf file, at least the options in
[global] that affect PDC support.
* In addition to the version, if you obtained Samba via CVS mention
the date when you last checked it out.
* Try and make your question clear and brief, lots of long,
convoluted questions get deleted before they are completely read !
Don't post html encoded messages (if you can select colour or font
size its html).
* If you run one of those niffy 'I'm on holidays' things when you
are away, make sure its configured to not answer mailing lists.
* Don't cross post. Work out which is the best list to post to and
see what happens, ie don't post to both samba-ntdom and
samba-technical. Many people active on the lists subscribe to more
than one list and get annoyed to see the same message two or more
times. Often someone will see a message and thinking it would be
better dealt with on another, will forward it on for you.
* You might include partial log files written at a debug level set
to as much as 20. Please don't send the entire log but enough to
give the context of the error messages.
* (Possibly) If you have a complete netmon trace ( from the opening
of the pipe to the error ) you can send the *.CAP file as well.
* Please think carefully before attaching a document to an email.
Consider pasting the relevant parts into the body of the message.
The samba mailing lists go to a huge number of people, do they all
need a copy of your smb.conf in their attach directory ?
_________________________________________________________________
How do I get off the mailing lists ?
To have your name removed from a samba mailing list, go to the same
place you went to to get on it. Go to http://samba.org, click on your
nearest mirror and then click on Support and then click on Samba
related mailing lists. Or perhaps see here
Please don't post messages to the list asking to be removed, you will
just be refered to the above address (unless that process failed in
some way...)

712
docs/textdocs/samba-pdc-howto.txt
View File

@ -1,712 +0,0 @@
The Samba 2.2 PDC HowTo
David Bannon
La Trobe University
_________________________________________________________________
_________________________________________________________________
Comments, corrections and additions to <dbannon@samba.org>
This document explains how to setup Samba as a Primary Domain
Controller and applies to version 2.2.0. Before using these functions
make sure you understand what the controller can and cannot do. Please
read the sections below in the Introduction. As 2.2.0 is incrementally
updated this document will change or become out of date very quickly,
make sure you are reading the most current version.
Please note this document does not apply to Samba2.2alpha0,
Samba2.2alpha1, Samba 2.0.7, TNG nor HEAD branch.
It does apply to the current (post November 27th) cvs.
Also available is an updated version of Jerry Carter's NTDom FAQ that
will answer lots of the special 'tuning' questions that are not
covered here. Over the next couple of weeks some of the items here
will be moved to the FAQ.
Table of Contents
1. Introduction
What can we do ?
What can't we do ?
2. Installing
Start Up Script
Config File
A sample conf file
PDC Config Parameters
Special directories
3. User and Machine Accounts
Logon Accounts
Machine Accounts
Joining the Domain
User Accounts
Domain Admin Accounts
4. Profiles, Policies and Logon Scripts
Profiles
Policies
Logon Scripts
5. Passwords and Authentication
Syncing Passwords
Using PAM
Authenticating other Samba Servers
6. Background
History
The Future
Getting further help
_________________________________________________________________
Chapter 1. Introduction
This document will show you one way of making Version 2.2.0 of Samba
perform some of the tasks of a NT Primary Domain Controller. The
facilities described are built into Samba as a result of development
work done over a number of years by a large number of people. These
facilities are only just beginning to be officially supported and
although they do appear to work reliably, if you use them then you
take the risks upon your self. This document does not cover the
developmental versions of Samba, particularly Samba-TNG
Note that Samba 2.0.7 supports significently less of the NT Domain
facilities compared with 2.2.0
This document does not replace the text files DOMAIN_CONTROL.txt,
DOMAIN.txt (by John H Terpstra) or NTDOMAIN.txt (by Luke Kenneth
Casson Leighton). Those documents provide more detail and an insight
to the development cycle and should be considered 'further reading'.
_________________________________________________________________
What can we do ?
* Permit 'domain logons' for Win95/98, NT4 and W2K workstations from
one central password database. WRT W2K, please see the section
about adding machine accounts and the Intro in the FAQ.
* Grant Administrator privileges to particular domain users on an NT
or W2K workstation.
* Apply policies from a domain policy file to NT and W2K (?)
workstation.
* Run the appropriate logon script when a user logs on to the domain
.
* Maintain a user's local profile on the server.
* Validate a user using another system via smb (such as smb_pam) and
soon winbind (?).
_________________________________________________________________
What can't we do ?
* Become or work with a Backup Domain Controller (a BDC).
* Participate in any sort of trust relationship (with either Samba
or NT Servers).
* Offer a list of domain users to User Manager for Domains on the
Security Tab etc).
* Be a W2K type of Domain Controller. Samba PDC will behave like an
NT PDC, W2K workstations connect in legacy mode.
_________________________________________________________________
Chapter 2. Installing
Installing consists of the usual download, configure, make and make
install process. These steps are well documented elsewhere. The FAQ
discusses getting pre-release versions via CVS. Then you need to
configure the server.
_________________________________________________________________
Start Up Script
Skip this section if you have a working Samba already. Everyone has
their own favourite startup script. Here is mine, offered with no
warrantee at all !
#!/bin/sh
# Script to control Samba server, David Bannon, 14-6-96
#
#
PATH=/bin:/usr/sbin:/usr/bin
export PATH
case "$1" in
'start')
if [ -f /usr/local/samba/bin/smbd ]
then
/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/nmbd -D
echo "Starting Samba Server"
fi
;;
'conf')
if [ -f /usr/local/samba/lib/smb.conf ]
then
vi /usr/local/samba/lib/smb.conf
fi
;;
'pw')
if [ -f /usr/local/samba/private/smbpasswd ]
then
vi /usr/local/samba/private/smbpasswd
fi
;;
'who')
/usr/local/samba/bin/smbstatus -b
;;
'restart')
psline=`/bin/ps x | grep smbd | grep -v grep`
if [ "$psline" != "" ]
then
while [ "$psline" != "" ]
do
psline=`/bin/ps x | fgrep smbd | grep -v grep`
if [ "$psline" ]
then
set -- $psline
pid=$1
/bin/kill -HUP $pid
echo "Stopped $pid line = $psline"
sleep 2
fi
done
fi
echo "Stopped Samba servers"
;;
'stop')
psline=`/bin/ps x | grep smbd | grep -v grep`
if [ "$psline" != "" ]
then
while [ "$psline" != "" ]
do
psline=`/bin/ps x | fgrep smbd | grep -v grep`
if [ "$psline" ]
then
set -- $psline
pid=$1
/bin/kill -9 $pid
echo "Stopped $pid line = $psline"
sleep 2
fi
done
fi
echo "Stopped Samba servers"
psline=`/bin/ps x | grep nmbd | grep -v grep`
if [ "$psline" ]
then
set -- $psline
pid=$1
/bin/kill -9 $pid
echo "Stopped Name Server "
fi
echo "Stopped Name Servers"
;;
*)
echo "usage: samba {start | restart |stop | conf | pw | who}"
;;
esac
Use this script, or some other one, you will need to ensure its used
while the machine is booting. (This typically involves /etc/rc.d,
we'll be assuming that there is a script called samba in
/etc/rc.d/init.d further down in this document.)
_________________________________________________________________
Config File
A sample conf file
Here is a fairly minimal config file to do PDC. It will also make the
server become the browse master for the specified domain (not
necessary but usually desirable). You will need to change only two
parameters to make this file work, wins server and workgroup, plus you
will need to put your own name (not mine!) in the domain admin users
fields. Some of the parameters are discussed further down this
document.
Assuming you have used the default install directories, this file
should appear as /usr/local/samba/lib/smb.conf. It should not be
writable by anyone except root.
Note: The 'add user script' parameter is a work-around, watch for
changes !
[global]
security = user
status = yes
workgroup = { Your domain name here }
wins server = { ip of a wins server if you have one }
encrypt passwords = yes
domain logons =yes
logon script = scripts\%U.bat
domain admin group = @adm
add user script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/n
ull -s /bin/false %m$
guest account = ftp
share modes=no
os level=65
[homes]
guest ok = no
read only = no
create mask = 0700
directory mask = 0700
oplocks = false
locking = no
[netlogon]
path = /usr/local/samba/netlogon
writeable = no
guest ok = no
_________________________________________________________________
PDC Config Parameters
There are a huge range of parameters that may appear in a smb.conf
file. Some that may be of interest to a PDC are :
add user script
This parameter specifies a script (or program) that will be run
to add a user to the system. Here it is being used to add a
machine, not a user. This is probably not very nice and may
change. But it does work !
For this example, I have a group called 'machines', entries can
be added to /etc/passwd using a programme called /usr/adduser
and the other parameters are chosen as suitable for a machine
account. Works for RH Linux, your system may require changes.
domain admin group = @adm
This parameter specifies a unix group whose members will be
granted admin privileges on a NT workstation when logged onto
that workstation. See the section called Domain Admin Accounts.
domain admin users = user1 users2
It appears that this parameter does not funtion correctly at
present. Use the 'domain admin group' instread. This parameter
specifies a unix user who will be granted admin privileges on a
NT workstation when logged onto that workstation. See the
section called Domain Admin Accounts.
encrypt passwords = yes
This parameter must be 'yes' to allow any of the recent service
pack NTs to logon. There are some reg hacks that turn off
encrypted passwords on the NTws itself but if you are going to
use the smbpasswd system (and you should) you must use
encrypted passwords.
logon script = scripts\%U.bat
This will make samba look for a logon script named after the
user (eg joeblow.bat). See the section further on called Logon
Scripts
Note: Note that the slash is like this '\', not like this '/'. NT
is happy with both, win95 is not !
logon path
Lets you specify where you would like users profiles kept. The
default, that is in the users home directory, does encourage a
bit of fiddling.
_________________________________________________________________
Special directories
You need to create a couple of special files and directories. Its nice
to have some of the binaries handy too, so I create links to them.
Assuming you have used the default samba location and have not changed
the locations mentioned in the sample config file, do the following :
mkdir /usr/local/samba/netlogon
mkdir /usr/local/samba/netlogon/scripts
mkdir /usr/local/samba/private
touch /usr/local/samba/private/smbpasswd
chmod go-rwx /usr/local/samba/private/smbpasswd
cd /usr/local/sbin
ln -s /usr/local/samba/bin/smbpasswd
ln -s /usr/local/samba/bin/smbclient
ln -s /etc/rc.d/init.d/samba
Make sure permissions are appropriate !
OK, if you have used the scripts above and have a path to where the
links are do this to start up the Samba Server :
samba start
Instead, you might like to reboot the machine to make sure that you
got the init stuff right. Any way, a quick look in the logs
/usr/local/samba/var/log.smbd and /usr/local/samba/var/log/nmbd will
give you an idea of what's happening. Assuming all is well, lets
create some accounts...
_________________________________________________________________
Chapter 3. User and Machine Accounts
Logon Accounts
This section is very nearly out of date already ! It appears that
while you are reading it, Jean Francois Micou is making it redundant !
Jean Francois is adding facilities to add users (via User Manager) and
machines (when joining the domain) and it looks like these facilities
will make it into the official release of 2.2.
Every user and NTws (and other samba servers) that will be on the
domain must have its own passwd entry in both /etc/passwd and
/usr/local/samba/private/smbpasswd . The /etc/passwd entry is really
only to reserve a user ID. The NT encrypted password is stored in
/usr/local/samba/private/smbpasswd. (Note that win95/98 machines don't
need an account as they don't do any security aware things.)
Samba 2.2 will now create these entries for us. Carefull set up is
required and there may well be some changes to this system before its
released.
_________________________________________________________________
Machine Accounts
Note: There is an entry in the ntdom FAQ explaining how to create
machine entries manually.
At present to have the machine accounts created when a machine joins
the domain a number of conditions must be met :
Only root can do it !
There must be an entry in /usr/local/samba/private/smbpasswd
for root and root must be mentioned in domain admins. This may
be fixed some time in the future so any 'domain admin' can do
it. If you don't like having root as a windows logon account,
make the machine entries manually (both of them).
Use the add user script
Again, this looks a bit like a 'work around'. Use a suitable
command line to add a machine account see above, and pass it
%m$, that is %m to get machine name plus the '$'. Now, this
means you cannot use the add user script to really add users
....
Only for W2K
This automatic creation of machine accounts does not work for
NT4ws at present. Watch this space.
_________________________________________________________________
Joining the Domain
You must have either added the machine account entries manually (NT4
ws) or set up the automatic system (W2K), see Machine Accounts before
proceeding.
Windows NT
+ (this step may not be necessary some time in the near
future). On the samba server that is the PDC, add a machine
account manually as per the instructions in the FAQ Then give
the command smbpasswd -a -m {machine} substituting in the
client machine name.
+ Logon to the NTws in question as a local admin, go to the
Control Panel, Network IdentificationTag.
+ Press the Change button.
+ Enter the Domain name (from the 'Workgroup' parameter,
smb.conf) in the Domain Field.
+ Press OK and after a few seconds you will get a 'Welcome to
Whatever Domain'. Allow to reboot.
Windows 2000
+ Logon to the W2k machine as Administrator, go to the Control
Panel and double click on Network and Dialup Connections.
+ Pull down the Advanced menu and choose Network
Identification. Press Properties .
+ Choose Domain and enter the domain name. Press 'OK'.
+ Now enter a user name and password for a Domain Admin (Who
must be root until a pre-release bug is fixed) and press
'OK'.
+ Wait for the confirmation, reboot when prompted.
To remove a W2K machine from the domain, follow the first two
steps then choose Workgroup, enter a work group name (or just
WORKGROUP) and follow the prompts.
_________________________________________________________________
User Accounts
Again, doing it manually (cos' the auto way is not working
pre-release). In our simple case every domain user should have an
account on the PDC. The account may have a null shell if they are not
allowed to log on to the unix prompt. Again they need an entry in both
the /etc/passwd and /usr/local/samba/private/smbpasswd. Again a
password is not necessary in /etc/passwd but the location of the home
directory is honoured. To make an entry for a user called Joe Blow you
would typically do the following :
adduser -g users -c 'Joe Blow' -s /bin/false -n joeblow
smbpasswd -a joeblow
And you will prompted to enter a password for Joe. Ideally he will be
hovering over your shoulder and will, when asked, type in a password
of his choice. There are a number of scripts and systems to ease the
migration of users from somewhere to samba. Better start looking !
_________________________________________________________________
Domain Admin Accounts
Certain operations demand that the logged on user has Administrator
privileges, typically installing software and doing maintenance tasks.
It is very simple to appoint some users as Domain Admins, most likely
yourself. Make sure you trust the appointee !
Samba 2.2 recognizes particular users as being domain admins and tells
the NTws when it thinks that it has got one logged on. In the smb.conf
file we declare that the Domain Admin group = @adm. Any user who is a
menber of the unix group 'adm' is treated as a Domain Admin by a NTws
when logged onto the Domain. They will have full Administrator rights
including the rights to change permissions on files and run the system
utilities such as Disk Administrator. Add users to the group by
editing /etc/group/. You do not need to use the 'adm' group, choose
any one you like.
Further, and this is very new, they will be allowed to create a new
machine account when first connecting a new NT or W2K machine to the
domain. However, at present, ie pre-release, only a Domain Admin who
also happens to be root can do so.
_________________________________________________________________
Chapter 4. Profiles, Policies and Logon Scripts
Profiles
NT Profiles should work if you have followed the setup so far. A
user's profile contains a whole lot of their personal settings, the
contents of their desktop, personal 'My Documents' and so on. When
they log off, all of the profile is copied to their directory on the
server and is downloaded again when they logon on again, possibly on
another client machine.
Sounds great but can be a bit of a bug bear sometimes. Users let their
profiles get too big and then complain about how long it takes to log
on each time. This sample setup only supports NT profiles, rumor has
it that it is also possible to do the same on Win95, my users don't
know and I'm not telling them.
Note: There is more info about Profiles (including for W95/98) in
the FAQ.
_________________________________________________________________
Policies
Policies are an easy way to make or enforce specific characteristics
across your network. You create a ntconfig.pol file and every time
someone logs on with their NTws, the settings you put in ntconfig.pol
are applied to the NTws. Typical setting are things like making the
date appear the way you want it (none of these 2 figure years here) or
maybe suppressing one of the splash screens. Perhaps you want to set
the NTws so it does not keep users profiles on the local machine.
Cool. The only problem is making the ntconfig.pol file itself. You
cannot use the policy editor that comes with NTws.
Note: See the FAQ for pointers on how to get a suitable Policy
Editor.
The Policy Editor (and associated files) will create a ntconfig.pol
file using the parameters Microsoft thought of and parameters you
specify by making your own template file.
In our example configuration here, Samba will expect to find the
ntconfig.pol file in /usr/local/samba/netlogon. Needless to say (I
hope !), it is vitally important that ordinary users don't have write
permission to the Policy files.
_________________________________________________________________
Logon Scripts
In the sample config file above there is a line logon script =
scripts\%U.bat
Note: Note that the slash is like this '\' not like this '/'. NT is
happy with both, win95 is not !
This allows you to run a dos batch file every time someone logs on.
The batch file is located on the server, in the sample install
mentioned here, its in /usr/local/samba/netlogon/scripts and is named
after the user with .bat appended, eg Joe Blow's script is called
/usr/local/samba/netlogon/scripts/joeblow.bat.
Note: There is a suggestion that user names longer than 8
characters may cause problems with some systems being unable to run
logon scripts. This is confirmed in earlier versions when
connecting using W95, comments about other combinations ??
You could use a line like this logon script = default.bat and samba
will supply /usr/local/samba/netlogon/default.bat for any client and
every user. Maybe you could use %m and get a client machine dependant
logon script. You get the idea...
Note that the file is a dos batch file not a Unix script. It runs dos
commands on the client computer with the logon user's permissions. It
must be a dos file with each line ending with the dos cr/lf not a nice
clean newline. Generally, its best to create the initial file on a DOS
system and copy it across.
There is lots of very clever uses of the Samba replaceable variables
such ( %U = user, %G = primary group, %H = client machine, see the
'man 5 smb.conf') to give you control over which script runs when a
particular person logs on. (Gee, it would be nice to have a
default.bat run when nothing else is available.)
Again, it is vitally important that ordinary users don't have write
permission to other peoples, or even probably their own, logon script
files.
A typical logon script is reproduced below. Note that it runs separate
commands for win95 and NT, that's because NT has slightly different
behaviour when using the net use .. command. Its useful for lots of
other situations too. I don't know what syntax to use for win98, I
don't use it here.
rem Default logon script, create links to this file.
net time \\bioserve /set /yes
@echo off
if %OS%.==Windows_NT. goto WinNT
:Win95
net use k: \\trillion\bio_prog
net use p: \\bcfile\homes
goto end
:WinNT
net use k: \\trillion\bio_prog /persistent:no
net use p: \\bcfile\homes /persistent:no
:end
_________________________________________________________________
Chapter 5. Passwords and Authentication
So far our configuration assumes that ordinary users don't have unix
logon access. A change to the adduser line above would allow unix
logon but it would be with passwords that may be different from the NT
logon. Clearly that won't suit everyone. Trying to explain to users
that they need to change their passwords in two seperate places is not
fun. Further, even if they cannot do a unix logon there are other
processes that might require authentication. We have a nice securely
encrypted password in /usr/local/samba/private/smbpasswd, why not use
it ?
_________________________________________________________________
Syncing Passwords
Yes, its possible and seems the easiest way (initially anyway). The
FAQ details how to do so in the sections What is password sync and
should I use it ? and How do I get remote password (unix and SMB)
changing working ?
_________________________________________________________________
Using PAM
Pam enabled systems have a much better solution available. The Samba
PDC server will offer to authenticate domain users to other processes
(either on this server or on the domain). With a suitable pam stack
such as Pam_smb you can get any pam aware application looking to the
samba password and can leave the password field in /etc/shadow or
/etc/passwd invalid.
_________________________________________________________________
Authenticating other Samba Servers
In a domain that has a number of servers you only need one password
database. The machines that don't have their own ask the PDC to check
for them. This will work fine for a domain controlled by either a
Samba or NT machine.
To do so the Samba machine must be told to refer to the PDC and where
the PDC is. See the section in the NTDom FAQ called How do I get my
samba server to become a member ( not PDC ) of an NT domain?
_________________________________________________________________
Chapter 6. Background
History
It might help you understand the limitations of the PDC in Samba if
you read something of its history. Well, the history as I understand
it anyway.
For many years the Samba team have been developing Samba, some time
ago a number of people, possibly lead by Luke Leighton started
contributing NT PDC stuff. This was added to the 'head' stream (that
would eventually become the next version) and later to a seperate
stream (NTDom). They did so much that eventually this development
stream was so mutated that it could not be merged back into the main
stream and was abandoned towards the end of 1999. And that was very
sad because many users, myself include had become heavily dependant on
the NTController facilities it offered. Oh well...
The NTDom team continued on with their new found knowledge however and
built the TNG stream. Intended to be carefully controlled so that it
can be merged back into the main stream and benefiting from what they
learnt, it is a very different product to the origional NTDom product.
However, for a number of reasons, the merge did not take place and now
TNG is being developed at http://www.samba-tng.org.
Now, the NTDom things that the main strean 2.0.x version does is based
more on the old (initial version) abandoned code than on the TNG
ideas. It appears that version 2.2.0 will also include an improved
version of the 2.0.7 domain controller charactistics, not the TNG
ways. The developers have indicated that 2.2.0 will be further
developed incrementally and the ideas from TNG incorporated into it.
One more little wriggle is worth mentioning. At one stage the NTDom
stream was called Samba 2.1.0-prealpha and similar names. This is most
unfortunate because at least one book published advises people who
want to use NTDom Samba to get version 2.1.0 or later. As main stream
Samba will soon be called 2.2.0 and NOT officially supporting NTDom
Controlling functions, the potential for confusion is certainly there.
_________________________________________________________________
The Future
There is a document on the Samba mirrors called 'Development' . It
offers the 'best guess' of what is planned for future releases of
Samba.
The future of Samba as a Primary Domain Controller appears rosie,
however be aware that its the future, not the present. The developers
are strongly committed to building a full featured PDC into Samba but
it will take time. If this version does not meet your requirements
then you should consider (in no particular order) :
* Wait. No, we don't know how long. Repeated asking won't help.
* Investigate the development versions, TNG perhaps or HEAD where
new code is being added all the time. Realise that development
code is often unstable, poorly documented and subject to change.
You will need to use cvs to download development versions.
* Join one of the Samba mailing lists so that you can find out what
is happening on the 'bleeding edge'.
_________________________________________________________________
Getting further help
This document cannot possibly answer all your questions. Please
understand that its very likely that someone has been confrounted by
the same problem that you have. The FAQ discusses a number of possible
paths to take to get further help :
* Documents on the Samba Sites.
* Other web sites.
* Mailing list.
There is some discussion about guide lines for using the Mailing Lists
on the accompanying FAQ, please read them before posting.