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

More of the documentation overhaul. More to follow.

Browse Source
This commit is contained in:
John Terpstra -
parent 647a720cfb
commit 8333c4709e
8 changed files with 429 additions and 1210 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
docs/docbook/projdoc/Browsing-Quickguide.sgml
View File

@ -84,6 +84,81 @@ minutes to stabilise, particularly across network segments.
</sect1>
<sect1>
<title>How browsing functions and how to deploy stable and
dependable browsing using Samba</title>
<para>
As stated above, MS Windows machines register their NetBIOS names
(i.e.: the machine name for each service type in operation) on start
up. Also, as stated above, the exact method by which this name registration
takes place is determined by whether or not the MS Windows client/server
has been given a WINS server address, whether or not LMHOSTS lookup
is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
</para>
<para>
In the case where there is no WINS server all name registrations as
well as name lookups are done by UDP broadcast. This isolates name
resolution to the local subnet, unless LMHOSTS is used to list all
names and IP addresses. In such situations Samba provides a means by
which the samba server name may be forcibly injected into the browse
list of a remote MS Windows network (using the "remote announce" parameter).
</para>
<para>
Where a WINS server is used, the MS Windows client will use UDP
unicast to register with the WINS server. Such packets can be routed
and thus WINS allows name resolution to function across routed networks.
</para>
<para>
During the startup process an election will take place to create a
local master browser if one does not already exist. On each NetBIOS network
one machine will be elected to function as the domain master browser. This
domain browsing has nothing to do with MS security domain control.
Instead, the domain master browser serves the role of contacting each local
master browser (found by asking WINS or from LMHOSTS) and exchanging browse
list contents. This way every master browser will eventually obtain a complete
list of all machines that are on the network. Every 11-15 minutes an election
is held to determine which machine will be the master browser. By the nature of
the election criteria used, the machine with the highest uptime, or the
most senior protocol version, or other criteria, will win the election
as domain master browser.
</para>
<para>
Clients wishing to browse the network make use of this list, but also depend
on the availability of correct name resolution to the respective IP
address/addresses.
</para>
<para>
Any configuration that breaks name resolution and/or browsing intrinsics
will annoy users because they will have to put up with protracted
inability to use the network services.
</para>
<para>
Samba supports a feature that allows forced synchonisation
of browse lists across routed networks using the "remote
browse sync" parameter in the smb.conf file. This causes Samba
to contact the local master browser on a remote network and
to request browse list synchronisation. This effectively bridges
two networks that are separated by routers. The two remote
networks may use either broadcast based name resolution or WINS
based name resolution, but it should be noted that the "remote
browse sync" parameter provides browse list synchronisation - and
that is distinct from name to address resolution, in other
words, for cross subnet browsing to function correctly it is
essential that a name to address resolution mechanism be provided.
This mechanism could be via DNS, <filename>/etc/hosts</filename>,
and so on.
</para>
</sect1>
<sect1>
<title>Use of the "Remote Announce" parameter</title>
<para>

445
docs/docbook/projdoc/Integrating-with-Windows.sgml
View File

@ -18,48 +18,46 @@
<title>Integrating MS Windows networks with Samba</title>
<sect1>
<title>Agenda</title>
<para>
To identify the key functional mechanisms of MS Windows networking
to enable the deployment of Samba as a means of extending and/or
replacing MS Windows NT/2000 technology.
This section deals with NetBIOS over TCP/IP name to IP address resolution. If you
your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this
section does not apply to your installation. If your installation involves use of
NetBIOS over TCP/IP then this section may help you to resolve networking problems.
</para>
<note>
<para>
We will examine:
NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS
over Logical Link Control (LLC). On modern networks it is highly advised
to NOT run NetBEUI at all. Note also that there is NO such thing as
NetBEUI over TCP/IP - the existence of such a protocol is a complete
and utter mis-apprehension.
</para>
</note>
<para>
Since the introduction of MS Windows 2000 it is possible to run MS Windows networking
without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS
name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over
TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be
used and UDP port 137 and TCP port 139 will not.
</para>
<orderedlist>
<listitem><para>Name resolution in a pure Unix/Linux TCP/IP
environment
</para></listitem>
<note>
<para>
When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then
the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet
Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic).
</para>
</note>
<listitem><para>Name resolution as used within MS Windows
networking
</para></listitem>
<listitem><para>How browsing functions and how to deploy stable
and dependable browsing using Samba
</para></listitem>
<listitem><para>MS Windows security options and how to
configure Samba for seemless integration
</para></listitem>
<listitem><para>Configuration of Samba as:</para>
<orderedlist>
<listitem><para>A stand-alone server</para></listitem>
<listitem><para>An MS Windows NT 3.x/4.0 security domain member
</para></listitem>
<listitem><para>An alternative to an MS Windows NT 3.x/4.0 Domain Controller
</para></listitem>
</orderedlist>
</listitem>
</orderedlist>
</sect1>
<para>
When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that
disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires
Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR).
Use of DHCP with ADS is recommended as a further means of maintaining central control
over client workstation network configuration.
</para>
<sect1>
@ -555,381 +553,4 @@ of the WINS server.
</sect2>
</sect1>
<sect1>
<title>How browsing functions and how to deploy stable and
dependable browsing using Samba</title>
<para>
As stated above, MS Windows machines register their NetBIOS names
(i.e.: the machine name for each service type in operation) on start
up. Also, as stated above, the exact method by which this name registration
takes place is determined by whether or not the MS Windows client/server
has been given a WINS server address, whether or not LMHOSTS lookup
is enabled, or if DNS for NetBIOS name resolution is enabled, etc.
</para>
<para>
In the case where there is no WINS server all name registrations as
well as name lookups are done by UDP broadcast. This isolates name
resolution to the local subnet, unless LMHOSTS is used to list all
names and IP addresses. In such situations Samba provides a means by
which the samba server name may be forcibly injected into the browse
list of a remote MS Windows network (using the "remote announce" parameter).
</para>
<para>
Where a WINS server is used, the MS Windows client will use UDP
unicast to register with the WINS server. Such packets can be routed
and thus WINS allows name resolution to function across routed networks.
</para>
<para>
During the startup process an election will take place to create a
local master browser if one does not already exist. On each NetBIOS network
one machine will be elected to function as the domain master browser. This
domain browsing has nothing to do with MS security domain control.
Instead, the domain master browser serves the role of contacting each local
master browser (found by asking WINS or from LMHOSTS) and exchanging browse
list contents. This way every master browser will eventually obtain a complete
list of all machines that are on the network. Every 11-15 minutes an election
is held to determine which machine will be the master browser. By the nature of
the election criteria used, the machine with the highest uptime, or the
most senior protocol version, or other criteria, will win the election
as domain master browser.
</para>
<para>
Clients wishing to browse the network make use of this list, but also depend
on the availability of correct name resolution to the respective IP
address/addresses.
</para>
<para>
Any configuration that breaks name resolution and/or browsing intrinsics
will annoy users because they will have to put up with protracted
inability to use the network services.
</para>
<para>
Samba supports a feature that allows forced synchonisation
of browse lists across routed networks using the "remote
browse sync" parameter in the smb.conf file. This causes Samba
to contact the local master browser on a remote network and
to request browse list synchronisation. This effectively bridges
two networks that are separated by routers. The two remote
networks may use either broadcast based name resolution or WINS
based name resolution, but it should be noted that the "remote
browse sync" parameter provides browse list synchronisation - and
that is distinct from name to address resolution, in other
words, for cross subnet browsing to function correctly it is
essential that a name to address resolution mechanism be provided.
This mechanism could be via DNS, <filename>/etc/hosts</filename>,
and so on.
</para>
</sect1>
<sect1>
<title>MS Windows security options and how to configure
Samba for seemless integration</title>
<para>
MS Windows clients may use encrypted passwords as part of a
challenege/response authentication model (a.k.a. NTLMv1) or
alone, or clear text strings for simple password based
authentication. It should be realized that with the SMB
protocol the password is passed over the network either
in plain text or encrypted, but not both in the same
authentication requets.
</para>
<para>
When encrypted passwords are used a password that has been
entered by the user is encrypted in two ways:
</para>
<itemizedlist>
<listitem><para>An MD4 hash of the UNICODE of the password
string. This is known as the NT hash.
</para></listitem>
<listitem><para>The password is converted to upper case,
and then padded or trucated to 14 bytes. This string is
then appended with 5 bytes of NULL characters and split to
form two 56 bit DES keys to encrypt a "magic" 8 byte value.
The resulting 16 bytes for the LanMan hash.
</para></listitem>
</itemizedlist>
<para>
You should refer to the <ulink url="ENCRYPTION.html">
Password Encryption</ulink> chapter in this HOWTO collection
for more details on the inner workings
</para>
<para>
MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x
and version 4.0 pre-service pack 3 will use either mode of
password authentication. All versions of MS Windows that follow
these versions no longer support plain text passwords by default.
</para>
<para>
MS Windows clients have a habit of dropping network mappings that
have been idle for 10 minutes or longer. When the user attempts to
use the mapped drive connection that has been dropped, the client
re-establishes the connection using
a cached copy of the password.
</para>
<para>
When Microsoft changed the default password mode, they dropped support for
caching of the plain text password. This means that when the registry
parameter is changed to re-enable use of plain text passwords it appears to
work, but when a dropped mapping attempts to revalidate it will fail if
the remote authentication server does not support encrypted passwords.
This means that it is definitely not a good idea to re-enable plain text
password support in such clients.
</para>
<para>
The following parameters can be used to work around the
issue of Windows 9x client upper casing usernames and
password before transmitting them to the SMB server
when using clear text authentication.
</para>
<para><programlisting>
<ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
<ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
</programlisting></para>
<para>
By default Samba will lower case the username before attempting
to lookup the user in the database of local system accounts.
Because UNIX usernames conventionally only contain lower case
character, the <parameter>username level</parameter> parameter
is rarely even needed.
</para>
<para>
However, password on UNIX systems often make use of mixed case
characters. This means that in order for a user on a Windows 9x
client to connect to a Samba server using clear text authentication,
the <parameter>password level</parameter> must be set to the maximum
number of upper case letter which <emphasis>could</emphasis> appear
is a password. Note that is the server OS uses the traditional
DES version of crypt(), then a <parameter>password level</parameter>
of 8 will result in case insensitive passwords as seen from Windows
users. This will also result in longer login times as Samba
hash to compute the permutations of the password string and
try them one by one until a match is located (or all combinations fail).
</para>
<para>
The best option to adopt is to enable support for encrypted passwords
where ever Samba is used. There are three configuration possibilities
for support of encrypted passwords:
</para>
<sect2>
<title>Use MS Windows NT as an authentication server</title>
<para>
This method involves the additions of the following parameters
in the smb.conf file:
</para>
<para><programlisting>
encrypt passwords = Yes
security = server
password server = "NetBIOS_name_of_PDC"
</programlisting></para>
<para>
There are two ways of identifying whether or not a username and
password pair was valid or not. One uses the reply information provided
as part of the authentication messaging process, the other uses
just and error code.
</para>
<para>
The down-side of this mode of configuration is the fact that
for security reasons Samba will send the password server a bogus
username and a bogus password and if the remote server fails to
reject the username and password pair then an alternative mode
of identification of validation is used. Where a site uses password
lock out after a certain number of failed authentication attempts
this will result in user lockouts.
</para>
<para>
Use of this mode of authentication does require there to be
a standard Unix account for the user, this account can be blocked
to prevent logons by other than MS Windows clients.
</para>
</sect2>
<sect2>
<title>Make Samba a member of an MS Windows NT security domain</title>
<para>
This method involves additon of the following paramters in the smb.conf file:
</para>
<para><programlisting>
encrypt passwords = Yes
security = domain
workgroup = "name of NT domain"
password server = *
</programlisting></para>
<para>
The use of the "*" argument to "password server" will cause samba
to locate the domain controller in a way analogous to the way
this is done within MS Windows NT.
</para>
<para>
In order for this method to work the Samba server needs to join the
MS Windows NT security domain. This is done as follows:
</para>
<itemizedlist>
<listitem><para>On the MS Windows NT domain controller using
the Server Manager add a machine account for the Samba server.
</para></listitem>
<listitem><para>Next, on the Linux system execute:
<command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command>
</para></listitem>
</itemizedlist>
<para>
Use of this mode of authentication does require there to be
a standard Unix account for the user in order to assign
a uid once the account has been authenticated by the remote
Windows DC. This account can be blocked to prevent logons by
other than MS Windows clients by things such as setting an invalid
shell in the <filename>/etc/passwd</filename> entry.
</para>
<para>
An alternative to assigning UIDs to Windows users on a
Samba member server is presented in the <ulink
url="winbind.html">Winbind Overview</ulink> chapter in
this HOWTO collection.
</para>
</sect2>
<sect2>
<title>Configure Samba as an authentication server</title>
<para>
This mode of authentication demands that there be on the
Unix/Linux system both a Unix style account as well as an
smbpasswd entry for the user. The Unix system account can be
locked if required as only the encrypted password will be
used for SMB client authentication.
</para>
<para>
This method involves addition of the following parameters to
the smb.conf file:
</para>
<para><programlisting>
## please refer to the Samba PDC HOWTO chapter later in
## this collection for more details
[global]
encrypt passwords = Yes
security = user
domain logons = Yes
; an OS level of 33 or more is recommended
os level = 33
[NETLOGON]
path = /somewhare/in/file/system
read only = yes
</programlisting></para>
<para>
in order for this method to work a Unix system account needs
to be created for each user, as well as for each MS Windows NT/2000
machine. The following structure is required.
</para>
<sect3>
<title>Users</title>
<para>
A user account that may provide a home directory should be
created. The following Linux system commands are typical of
the procedure for creating an account.
</para>
<para><programlisting>
# useradd -s /bin/bash -d /home/"userid" -m "userid"
# passwd "userid"
Enter Password: &lt;pw&gt;
# smbpasswd -a "userid"
Enter Password: &lt;pw&gt;
</programlisting></para>
</sect3>
<sect3>
<title>MS Windows NT Machine Accounts</title>
<para>
These are required only when Samba is used as a domain
controller. Refer to the Samba-PDC-HOWTO for more details.
</para>
<para><programlisting>
# useradd -s /bin/false -d /dev/null "machine_name"\$
# passwd -l "machine_name"\$
# smbpasswd -a -m "machine_name"
</programlisting></para>
</sect3>
</sect2>
</sect1>
<sect1>
<title>Conclusions</title>
<para>
Samba provides a flexible means to operate as...
</para>
<itemizedlist>
<listitem><para>A Stand-alone server - No special action is needed
other than to create user accounts. Stand-alone servers do NOT
provide network logon services, meaning that machines that use this
server do NOT perform a domain logon but instead make use only of
the MS Windows logon which is local to the MS Windows
workstation/server.
</para></listitem>
<listitem><para>An MS Windows NT 3.x/4.0 security domain member.
</para></listitem>
<listitem><para>An alternative to an MS Windows NT 3.x/4.0
Domain Controller.
</para></listitem>
</itemizedlist>
</sect1>
</chapter>

111
docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml
View File

@ -11,8 +11,6 @@
</address>
</affiliation>
</author>
<pubdate> (Jun 21 2001) </pubdate>
</chapterinfo>
@ -42,6 +40,19 @@ PAM is configured either through one file <filename>/etc/pam.conf</filename> (So
or by editing individual files that are located in <filename>/etc/pam.d</filename>.
</para>
<note>
<para>
If the PAM authentication module (loadable link library file) is located in the
default location then it is not necessary to specify the path. In the case of
Linux, the default location is <filename>/lib/security</filename>. If the module
is located other than default then the path may be specified as:
<programlisting>
eg: "auth required /other_path/pam_strange_module.so"
</programlisting>
</para>
</note>
<para>
The following is an example <filename>/etc/pam.d/login</filename> configuration file.
This example had all options been uncommented is probably not usable
@ -51,20 +62,20 @@ by commenting them out except the calls to <filename>pam_pwdb.so</filename>.
</para>
<para><programlisting>
#%PAM-1.0
# The PAM configuration file for the `login' service
#
auth required pam_securetty.so
auth required pam_nologin.so
# auth required pam_dialup.so
# auth optional pam_mail.so
auth required pam_pwdb.so shadow md5
# account requisite pam_time.so
account required pam_pwdb.so
session required pam_pwdb.so
# session optional pam_lastlog.so
# password required pam_cracklib.so retry=3
password required pam_pwdb.so shadow md5
#%PAM-1.0
# The PAM configuration file for the `login' service
#
auth required pam_securetty.so
auth required pam_nologin.so
# auth required pam_dialup.so
# auth optional pam_mail.so
auth required pam_pwdb.so shadow md5
# account requisite pam_time.so
account required pam_pwdb.so
session required pam_pwdb.so
# session optional pam_lastlog.so
# password required pam_cracklib.so retry=3
password required pam_pwdb.so shadow md5
</programlisting></para>
<para>
@ -73,19 +84,19 @@ sample system include:
</para>
<para><programlisting>
$ /bin/ls /lib/security
pam_access.so pam_ftp.so pam_limits.so
pam_ncp_auth.so pam_rhosts_auth.so pam_stress.so
pam_cracklib.so pam_group.so pam_listfile.so
pam_nologin.so pam_rootok.so pam_tally.so
pam_deny.so pam_issue.so pam_mail.so
pam_permit.so pam_securetty.so pam_time.so
pam_dialup.so pam_lastlog.so pam_mkhomedir.so
pam_pwdb.so pam_shells.so pam_unix.so
pam_env.so pam_ldap.so pam_motd.so
pam_radius.so pam_smbpass.so pam_unix_acct.so
pam_wheel.so pam_unix_auth.so pam_unix_passwd.so
pam_userdb.so pam_warn.so pam_unix_session.so
$ /bin/ls /lib/security
pam_access.so pam_ftp.so pam_limits.so
pam_ncp_auth.so pam_rhosts_auth.so pam_stress.so
pam_cracklib.so pam_group.so pam_listfile.so
pam_nologin.so pam_rootok.so pam_tally.so
pam_deny.so pam_issue.so pam_mail.so
pam_permit.so pam_securetty.so pam_time.so
pam_dialup.so pam_lastlog.so pam_mkhomedir.so
pam_pwdb.so pam_shells.so pam_unix.so
pam_env.so pam_ldap.so pam_motd.so
pam_radius.so pam_smbpass.so pam_unix_acct.so
pam_wheel.so pam_unix_auth.so pam_unix_passwd.so
pam_userdb.so pam_warn.so pam_unix_session.so
</programlisting></para>
<para>
@ -110,13 +121,13 @@ source distribution.
</para>
<para><programlisting>
#%PAM-1.0
# The PAM configuration file for the `login' service
#
auth required pam_smbpass.so nodelay
account required pam_smbpass.so nodelay
session required pam_smbpass.so nodelay
password required pam_smbpass.so nodelay
#%PAM-1.0
# The PAM configuration file for the `login' service
#
auth required pam_smbpass.so nodelay
account required pam_smbpass.so nodelay
session required pam_smbpass.so nodelay
password required pam_smbpass.so nodelay
</programlisting></para>
<para>
@ -125,13 +136,13 @@ Linux system. The default condition uses <filename>pam_pwdb.so</filename>.
</para>
<para><programlisting>
#%PAM-1.0
# The PAM configuration file for the `samba' service
#
auth required /lib/security/pam_pwdb.so nullok nodelay shadow audit
account required /lib/security/pam_pwdb.so audit nodelay
session required /lib/security/pam_pwdb.so nodelay
password required /lib/security/pam_pwdb.so shadow md5
#%PAM-1.0
# The PAM configuration file for the `samba' service
#
auth required /lib/security/pam_pwdb.so nullok nodelay shadow audit
account required /lib/security/pam_pwdb.so audit nodelay
session required /lib/security/pam_pwdb.so nodelay
password required /lib/security/pam_pwdb.so shadow md5
</programlisting></para>
<para>
@ -143,13 +154,13 @@ program.
</para>
<para><programlisting>
#%PAM-1.0
# The PAM configuration file for the `samba' service
#
auth required /lib/security/pam_smbpass.so nodelay
account required /lib/security/pam_pwdb.so audit nodelay
session required /lib/security/pam_pwdb.so nodelay
password required /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
#%PAM-1.0
# The PAM configuration file for the `samba' service
#
auth required /lib/security/pam_smbpass.so nodelay
account required /lib/security/pam_pwdb.so audit nodelay
session required /lib/security/pam_pwdb.so nodelay
password required /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf
</programlisting></para>
<note><para>PAM allows stacking of authentication mechanisms. It is

2
docs/docbook/projdoc/Samba-BDC-HOWTO.sgml
View File

@ -13,7 +13,7 @@
</chapterinfo>
<title>
How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain
Samba Backup Domain Controller to Samba Domain Control
</title>
<sect1>

761
docs/docbook/projdoc/Samba-PDC-HOWTO.sgml
View File

@ -68,27 +68,32 @@ PDC functionality.
<itemizedlist>
<listitem><para>
domain logons for Windows NT 4.0 / 200x / XP Professional clients.
Domain logons for Windows NT 4.0 / 200x / XP Professional clients.
</para></listitem>
<listitem><para>
placing Windows 9x / Me clients in user level security
Placing Windows 9x / Me clients in user level security
</para></listitem>
<listitem><para>
retrieving a list of users and groups from a Samba PDC to
Retrieving a list of users and groups from a Samba PDC to
Windows 9x / Me / NT / 200x / XP Professional clients
</para></listitem>
<listitem><para>
roaming user profiles
Roaming Profiles
</para></listitem>
<listitem><para>
Windows NT 4.0-style system policies
Network/System Policies
</para></listitem>
</itemizedlist>
<note>
<para>
Roaming Profiles and System/Network policies are advanced network administration topics
that are covered separately in this document.
</para>
<para>
The following functionalities are new to the Samba 3.0 release:
@ -587,18 +592,17 @@ version of Windows.
<para>I joined the domain successfully but after upgrading
to a newer version of the Samba code I get the message, "The system
can not log you on (C000019B), Please try a gain or consult your
can not log you on (C000019B), Please try again or consult your
system administrator" when attempting to logon.
</para>
<para>
This occurs when the domain SID stored in
<filename>private/WORKGROUP.SID</filename> is
changed. For example, you remove the file and <command>smbd</command> automatically
creates a new one. Or you are swapping back and forth between
versions 2.0.7, TNG and the HEAD branch code (not recommended). The
only way to correct the problem is to restore the original domain
SID or remove the domain client from the domain and rejoin.
This occurs when the domain SID stored in the secrets.tdb database
is changed. The most common cause of a change in domain SID is when
the domain name and/or the server name (netbios name) is changed.
The only way to correct the problem is to restore the original domain
SID or remove the domain client from the domain and rejoin. The domain
SID may be reset using either the smbpasswd or rpcclient utilities.
</para>
</listitem>
@ -675,128 +679,6 @@ version of Windows.
</sect1>
<!-- **********************************************************
Policies and Profiles
*************************************************************** -->
<sect1>
<title>
System Policies and Profiles
</title>
<para>
Much of the information necessary to implement System Policies and
Roving User Profiles in a Samba domain is the same as that for
implementing these same items in a Windows NT 4.0 domain.
You should read the white paper <ulink url="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp">Implementing
Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft.
</para>
<para>
Here are some additional details:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>What about Windows NT Policy Editor?</emphasis>
</para>
<para>
To create or edit <filename>ntconfig.pol</filename> you must use
the NT Server Policy Editor, <command>poledit.exe</command> which
is included with NT Server but <emphasis>not NT Workstation</emphasis>.
There is a Policy Editor on a NTws
but it is not suitable for creating <emphasis>Domain Policies</emphasis>.
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 <filename>poledit.exe, common.adm</filename> and <filename>winnt.adm</filename>. It is convenient
to put the two *.adm files in <filename>c:\winnt\inf</filename> which is where
the binary will look for them unless told otherwise. Note also that that
directory is 'hidden'.
</para>
<para>
The Windows NT policy editor is also included with the Service Pack 3 (and
later) for Windows NT 4.0. Extract the files using <command>servicepackname /x</command>,
i.e. that's <command>Nt4sp6ai.exe /x</command> for service pack 6a. The policy editor,
<command>poledit.exe</command> 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.
</para>
</listitem>
<listitem>
<para>
<emphasis>Can Win95 do Policies?</emphasis>
</para>
<para>
Install the group policy handler for Win9x to pick up group
policies. Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>.
Install group policies on a Win9x client by double-clicking
<filename>grouppol.inf</filename>. 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....
</para>
<para>
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.
</para>
</listitem>
<listitem>
<para>
<emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis>
</para>
<para>
Since I don't need to buy an NT Server CD now, how do I get
the 'User Manager for Domains', the 'Server Manager'?
</para>
<para>
Microsoft distributes a version of these tools called nexus for
installation on Windows 95 systems. The tools set includes
</para>
<itemizedlist>
<listitem><para>Server Manager</para></listitem>
<listitem><para>User Manager for Domains</para></listitem>
<listitem><para>Event Viewer</para></listitem>
</itemizedlist>
<para>
Click here to download the archived file <ulink
url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink>
</para>
<para>
The Windows NT 4.0 version of the 'User Manager for
Domains' and 'Server Manager' are available from Microsoft via ftp
from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink>
</para>
</listitem>
</itemizedlist>
</sect1>
<!-- **********************************************************
Getting Help
@ -1095,37 +977,28 @@ general SMB topics such as browsing.</para>
<sect1>
<title>Domain Control for Windows 9x/ME</title>
<note>
<para>
The following section contains much of the original
DOMAIN.txt file previously included with Samba. Much of
the material is based on what went into the book <emphasis>Special
Edition, Using Samba</emphasis>, by Richard Sharpe.
</para>
</note>
<para>
A domain and a workgroup are exactly the same thing in terms of network
browsing. The difference is that a distributable authentication
database is associated with a domain, for secure login access to a
network. Also, different access rights can be granted to users if they
successfully authenticate against a domain logon server (NT server and
other systems based on NT server support this, as does at least Samba TNG now).
successfully authenticate against a domain logon server. Samba-3 does this
now in the same way that MS Windows NT/2K.
</para>
<para>
The SMB client logging on to a domain has an expectation that every other
server in the domain should accept the same authentication information.
Network browsing functionality of domains and workgroups is
identical and is explained in BROWSING.txt. It should be noted, that browsing
is totally orthogonal to logon support.
Network browsing functionality of domains and workgroups is identical and
is explained in this documentation under the browsing discussions.
It should be noted, that browsing is totally orthogonal to logon support.
</para>
<para>
Issues related to the single-logon network model are discussed in this
section. Samba supports domain logons, network logon scripts, and user
profiles for MS Windows for workgroups and MS Windows 9X/ME clients
which will be the focus of this section.
which are the focus of this section.
</para>
@ -1285,594 +1158,6 @@ for its domain.
</para>
</warning>
</sect2>
<sect2>
<title>Configuration Instructions: Setting up Roaming User Profiles</title>
<warning>
<para>
<emphasis>NOTE!</emphasis> Roaming profiles support is different
for Win9X and WinNT.
</para>
</warning>
<para>
Before discussing how to configure roaming profiles, it is useful to see how
Win9X and WinNT clients implement these features.
</para>
<para>
Win9X clients send a NetUserGetInfo request to the server to get the user's
profiles location. However, the response does not have room for a separate
profiles location field, only the user's home share. This means that Win9X
profiles are restricted to being in the user's home directory.
</para>
<para>
WinNT clients send a NetSAMLogon RPC request, which contains many fields,
including a separate field for the location of the user's profiles.
This means that support for profiles is different for Win9X and WinNT.
</para>
<sect3>
<title>Windows NT Configuration</title>
<para>
To support WinNT clients, in the [global] section of smb.conf set the
following (for example):
</para>
<para><programlisting>
logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath
</programlisting></para>
<para>
The default for this option is \\%N\%U\profile, namely
\\sambaserver\username\profile. The \\N%\%U service is created
automatically by the [homes] service.
If you are using a samba server for the profiles, you _must_ make the
share specified in the logon path browseable.
</para>
<note>
<para>
[lkcl 26aug96 - we have discovered a problem where Windows clients can
maintain a connection to the [homes] share in between logins. The
[homes] share must NOT therefore be used in a profile path.]
</para>
</note>
</sect3>
<sect3>
<title>Windows 9X Configuration</title>
<para>
To support Win9X clients, you must use the "logon home" parameter. Samba has
now been fixed so that "net use/home" now works as well, and it, too, relies
on the "logon home" parameter.
</para>
<para>
By using the logon home parameter, you are restricted to putting Win9X
profiles in the user's home directory. But wait! There is a trick you
can use. If you set the following in the [global] section of your
smb.conf file:
</para>
<para><programlisting>
logon home = \\%L\%U\.profiles
</programlisting></para>
<para>
then your Win9X clients will dutifully put their clients in a subdirectory
of your home directory called .profiles (thus making them hidden).
</para>
<para>
Not only that, but 'net use/home' will also work, because of a feature in
Win9X. It removes any directory stuff off the end of the home directory area
and only uses the server and share portion. That is, it looks like you
specified \\%L\%U for "logon home".
</para>
</sect3>
<sect3>
<title>Win9X and WinNT Configuration</title>
<para>
You can support profiles for both Win9X and WinNT clients by setting both the
"logon home" and "logon path" parameters. For example:
</para>
<para><programlisting>
logon home = \\%L\%U\.profiles
logon path = \\%L\profiles\%U
</programlisting></para>
<note>
<para>
I have not checked what 'net use /home' does on NT when "logon home" is
set as above.
</para>
</note>
</sect3>
<sect3>
<title>Windows 9X Profile Setup</title>
<para>
When a user first logs in on Windows 9X, the file user.DAT is created,
as are folders "Start Menu", "Desktop", "Programs" and "Nethood".
These directories and their contents will be merged with the local
versions stored in c:\windows\profiles\username on subsequent logins,
taking the most recent from each. You will need to use the [global]
options "preserve case = yes", "short preserve case = yes" and
"case sensitive = no" in order to maintain capital letters in shortcuts
in any of the profile folders.
</para>
<para>
The user.DAT file contains all the user's preferences. If you wish to
enforce a set of preferences, rename their user.DAT file to user.MAN,
and deny them write access to this file.
</para>
<orderedlist>
<listitem>
<para>
On the Windows 95 machine, go to Control Panel | Passwords and
select the User Profiles tab. Select the required level of
roaming preferences. Press OK, but do _not_ allow the computer
to reboot.
</para>
</listitem>
<listitem>
<para>
On the Windows 95 machine, go to Control Panel | Network |
Client for Microsoft Networks | Preferences. Select 'Log on to
NT Domain'. Then, ensure that the Primary Logon is 'Client for
Microsoft Networks'. Press OK, and this time allow the computer
to reboot.
</para>
</listitem>
</orderedlist>
<para>
Under Windows 95, Profiles are downloaded from the Primary Logon.
If you have the Primary Logon as 'Client for Novell Networks', then
the profiles and logon script will be downloaded from your Novell
Server. If you have the Primary Logon as 'Windows Logon', then the
profiles will be loaded from the local machine - a bit against the
concept of roaming profiles, if you ask me.
</para>
<para>
You will now find that the Microsoft Networks Login box contains
[user, password, domain] instead of just [user, password]. Type in
the samba server's domain name (or any other domain known to exist,
but bear in mind that the user will be authenticated against this
domain and profiles downloaded from it, if that domain logon server
supports it), user name and user's password.
</para>
<para>
Once the user has been successfully validated, the Windows 95 machine
will inform you that 'The user has not logged on before' and asks you
if you wish to save the user's preferences? Select 'yes'.
</para>
<para>
Once the Windows 95 client comes up with the desktop, you should be able
to examine the contents of the directory specified in the "logon path"
on the samba server and verify that the "Desktop", "Start Menu",
"Programs" and "Nethood" folders have been created.
</para>
<para>
These folders will be cached locally on the client, and updated when
the user logs off (if you haven't made them read-only by then :-).
You will find that if the user creates further folders or short-cuts,
that the client will merge the profile contents downloaded with the
contents of the profile directory already on the local client, taking
the newest folders and short-cuts from each set.
</para>
<para>
If you have made the folders / files read-only on the samba server,
then you will get errors from the w95 machine on logon and logout, as
it attempts to merge the local and the remote profile. Basically, if
you have any errors reported by the w95 machine, check the Unix file
permissions and ownership rights on the profile directory contents,
on the samba server.
</para>
<para>
If you have problems creating user profiles, you can reset the user's
local desktop cache, as shown below. When this user then next logs in,
they will be told that they are logging in "for the first time".
</para>
<orderedlist>
<listitem>
<para>
instead of logging in under the [user, password, domain] dialog,
press escape.
</para>
</listitem>
<listitem>
<para>
run the regedit.exe program, and look in:
</para>
<para>
HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList
</para>
<para>
you will find an entry, for each user, of ProfilePath. Note the
contents of this key (likely to be c:\windows\profiles\username),
then delete the key ProfilePath for the required user.
</para>
<para>
[Exit the registry editor].
</para>
</listitem>
<listitem>
<para>
<emphasis>WARNING</emphasis> - before deleting the contents of the
directory listed in
the ProfilePath (this is likely to be c:\windows\profiles\username),
ask them if they have any important files stored on their desktop
or in their start menu. delete the contents of the directory
ProfilePath (making a backup if any of the files are needed).
</para>
<para>
This will have the effect of removing the local (read-only hidden
system file) user.DAT in their profile directory, as well as the
local "desktop", "nethood", "start menu" and "programs" folders.
</para>
</listitem>
<listitem>
<para>
search for the user's .PWL password-caching file in the c:\windows
directory, and delete it.
</para>
</listitem>
<listitem>
<para>
log off the windows 95 client.
</para>
</listitem>
<listitem>
<para>
check the contents of the profile path (see "logon path" described
above), and delete the user.DAT or user.MAN file for the user,
making a backup if required.
</para>
</listitem>
</orderedlist>
<para>
If all else fails, increase samba's debug log levels to between 3 and 10,
and / or run a packet trace program such as tcpdump or netmon.exe, and
look for any error reports.
</para>
<para>
If you have access to an NT server, then first set up roaming profiles
and / or netlogons on the NT server. Make a packet trace, or examine
the example packet traces provided with NT server, and see what the
differences are with the equivalent samba trace.
</para>
</sect3>
<sect3>
<title>Windows NT Workstation 4.0</title>
<para>
When a user first logs in to a Windows NT Workstation, the profile
NTuser.DAT is created. The profile location can be now specified
through the "logon path" parameter.
</para>
<note>
<para>
[lkcl 10aug97 - i tried setting the path to
\\samba-server\homes\profile, and discovered that this fails because
a background process maintains the connection to the [homes] share
which does _not_ close down in between user logins. you have to
have \\samba-server\%L\profile, where user is the username created
from the [homes] share].
</para>
</note>
<para>
There is a parameter that is now available for use with NT Profiles:
"logon drive". This should be set to "h:" or any other drive, and
should be used in conjunction with the new "logon home" parameter.
</para>
<para>
The entry for the NT 4.0 profile is a _directory_ not a file. The NT
help on profiles mentions that a directory is also created with a .PDS
extension. The user, while logging in, must have write permission to
create the full profile path (and the folder with the .PDS extension)
[lkcl 10aug97 - i found that the creation of the .PDS directory failed,
and had to create these manually for each user, with a shell script.
also, i presume, but have not tested, that the full profile path must
be browseable just as it is for w95, due to the manner in which they
attempt to create the full profile path: test existence of each path
component; create path component].
</para>
<para>
In the profile directory, NT creates more folders than 95. It creates
"Application Data" and others, as well as "Desktop", "Nethood",
"Start Menu" and "Programs". The profile itself is stored in a file
NTuser.DAT. Nothing appears to be stored in the .PDS directory, and
its purpose is currently unknown.
</para>
<para>
You can use the System Control Panel to copy a local profile onto
a samba server (see NT Help on profiles: it is also capable of firing
up the correct location in the System Control Panel for you). The
NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN
turns a profile into a mandatory one.
</para>
<note>
<para>
[lkcl 10aug97 - i notice that NT Workstation tells me that it is
downloading a profile from a slow link. whether this is actually the
case, or whether there is some configuration issue, as yet unknown,
that makes NT Workstation _think_ that the link is a slow one is a
matter to be resolved].
</para>
<para>
[lkcl 20aug97 - after samba digest correspondence, one user found, and
another confirmed, that profiles cannot be loaded from a samba server
unless "security = user" and "encrypt passwords = yes" (see the file
ENCRYPTION.txt) or "security = server" and "password server = ip.address.
of.yourNTserver" are used. Either of these options will allow the NT
workstation to access the samba server using LAN manager encrypted
passwords, without the user intervention normally required by NT
workstation for clear-text passwords].
</para>
<para>
[lkcl 25aug97 - more comments received about NT profiles: the case of
the profile _matters_. the file _must_ be called NTuser.DAT or, for
a mandatory profile, NTuser.MAN].
</para>
</note>
</sect3>
<sect3>
<title>Windows NT Server</title>
<para>
There is nothing to stop you specifying any path that you like for the
location of users' profiles. Therefore, you could specify that the
profile be stored on a samba server, or any other SMB server, as long as
that SMB server supports encrypted passwords.
</para>
</sect3>
<sect3>
<title>Sharing Profiles between W95 and NT Workstation 4.0</title>
<warning>
<title>Potentially outdated or incorrect material follows</title>
<para>
I think this is all bogus, but have not deleted it. (Richard Sharpe)
</para>
</warning>
<para>
The default logon path is \\%N\%U. NT Workstation will attempt to create
a directory "\\samba-server\username.PDS" if you specify the logon path
as "\\samba-server\username" with the NT User Manager. Therefore, you
will need to specify (for example) "\\samba-server\username\profile".
NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which
is more likely to succeed.
</para>
<para>
If you then want to share the same Start Menu / Desktop with W95, you will
need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97
this has its drawbacks: i created a shortcut to telnet.exe, which attempts
to run from the c:\winnt\system32 directory. this directory is obviously
unlikely to exist on a Win95-only host].
</para>
<para>
If you have this set up correctly, you will find separate user.DAT and
NTuser.DAT files in the same profile directory.
</para>
<note>
<para>
[lkcl 25aug97 - there are some issues to resolve with downloading of
NT profiles, probably to do with time/date stamps. i have found that
NTuser.DAT is never updated on the workstation after the first time that
it is copied to the local workstation profile directory. this is in
contrast to w95, where it _does_ transfer / update profiles correctly].
</para>
</note>
</sect3>
</sect2>
</sect1>
<!-- **********************************************************
Appendix - DOMAIN_CONTROL.txt
*************************************************************** -->
<sect1>
<title>
DOMAIN_CONTROL.txt : Windows NT Domain Control &amp; Samba
</title>
<warning>
<title>Possibly Outdated Material</title>
<para>
This appendix was originally authored by John H Terpstra of
the Samba Team and is included here for posterity.
</para>
</warning>
<para>
<emphasis>NOTE :</emphasis>
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.
</para>
<para>
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.
</para>
<para>
To many people these terms can be confusing, so let's try to clear the air.
</para>
<para>
Every Windows NT system (workstation or server) has a registry database.
The registry contains entries that describe the initialization information
for all services (the equivalent of Unix Daemons) that run within the Windows
NT environment. The registry also contains entries that tell application
software where to find dynamically loadable libraries that they depend upon.
In fact, the registry contains entries that describes everything that anything
may need to know to interact with the rest of the system.
</para>
<para>
The registry files can be located on any Windows NT machine by opening a
command prompt and typing:
</para>
<para>
<prompt>C:\WINNT\></prompt> dir %SystemRoot%\System32\config
</para>
<para>
The environment variable %SystemRoot% value can be obtained by typing:
</para>
<para>
<prompt>C:\WINNT></prompt>echo %SystemRoot%
</para>
<para>
The active parts of the registry that you may want to be familiar with are
the files called: default, system, software, sam and security.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
The User database is called the SAM (Security Access Manager) database and
is used for all user authentication as well as for authentication of inter-
process authentication (i.e. to ensure that the service action a user has
requested is permitted within the limits of that user's privileges).
</para>
<para>
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.
</para>
<para>
Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers
can participate in a Domain security system that is controlled by Windows NT
servers that have been correctly configured. Almost every domain will have
ONE Primary Domain Controller (PDC). It is desirable that each domain will
have at least one Backup Domain Controller (BDC).
</para>
<para>
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.
</para>
</sect1>
</chapter>

7
docs/docbook/projdoc/ServerType.sgml
View File

@ -44,6 +44,13 @@ discussions regarding "security mode". The smb.conf configuration parameters
that control security mode are: "security = user" and "security = share".
</para>
<para>
No special action is needed other than to create user accounts. Stand-alone
servers do NOT provide network logon services, meaning that machines that
use this server do NOT perform a domain logon but instead make use only of
the MS Windows logon which is local to the MS Windows workstation/server.
</para>
<para>
Samba tends to blur the distinction a little in respect of what is
a stand alone server. This is because the authentication database may be

16
docs/docbook/projdoc/samba-doc.sgml
View File

@ -22,11 +22,11 @@
<!ENTITY ADS-HOWTO SYSTEM "ADS-HOWTO.sgml">
<!ENTITY Passdb SYSTEM "passdb.sgml">
<!ENTITY VFS SYSTEM "VFS.sgml">
<!ENTITY GroupProfiles SYSTEM "GroupProfiles.sgml">
<!ENTITY SecuringSamba SYSTEM "securing-samba.sgml">
<!ENTITY Compiling SYSTEM "Compiling.sgml">
<!ENTITY unicode SYSTEM "unicode.sgml">
<!ENTITY CUPS SYSTEM "CUPS-printing.sgml">
<!ENTITY AdvancedNetworkManagement SYSTEM "AdvancedNetworkAdmin.sgml">
]>
<book id="Samba-HOWTO-Collection">
@ -102,30 +102,30 @@ for various environments.
</part>
<part id="optional">
<title>Optional configuration</title>
<title>Advanced Configuration</title>
<partintro>
<title>Introduction</title>
<para>Samba has several features that you might want or might not want to use. The chapters in this
part each cover one specific feature.</para>
</partintro>
&IntegratingWithWindows;
&AdvancedNetworkManagment;
&NT-Security;
&GROUP-MAPPING-HOWTO;
&Samba-PAM;
&MS-Dfs-Setup;
&PRINTER-DRIVER2;
&CUPS;
&WINBIND;
&IntegratingWithWindows;
&BROWSING;
&MS-Dfs-Setup;
&VFS;
&GROUP-MAPPING-HOWTO;
&SPEED;
&GroupProfiles;
&SecuringSamba;
&unicode;
</part>
<part id="Appendixes">
<title>Appendixes</title>
&SPEED;
&Portability;
&Other-Clients;
&Compiling;
@ -133,4 +133,4 @@ part each cover one specific feature.</para>
&Diagnosis;
</part>
</book>

222
docs/docbook/projdoc/security_level.sgml
View File

@ -8,8 +8,15 @@
</affiliation>
</author>
</chapterinfo>
<title>Samba as Stand-Alone Server</title
<title>Samba as Stand-Alone server (User and Share security level)</title>
<para>
In this section the function and purpose of Samba's <emphasis>security</emphasis>
modes are described.
</para>
<sect1>
<Title>User and Share security level</title>
<para>
A SMB server tells the client at startup what "security level" it is
@ -23,6 +30,9 @@ can only tell the client what is available and whether an action is
allowed.
</para>
<sect2>
<title>User Level Security</title>
<para>
I'll describe user level security first, as its simpler. In user level
security the client will send a "session setup" command directly after
@ -53,6 +63,11 @@ maintain multiple authentication contexts in this way (WinDD is an
example of an application that does this)
</para>
</sect2>
<sect2>
<title>Share Level Security>
<para>
Ok, now for share level security. In share level security the client
authenticates itself separately for each share. It will send a
@ -79,6 +94,11 @@ usernames". If a match is found then the client is authenticated as
that user.
</para>
</sect2>
<sect2>
<title>Server Level Security</title>
<para>
Finally "server level" security. In server level security the samba
server reports to the client that it is in user level security. The
@ -113,4 +133,204 @@ That real authentication server can be another Samba server or can be a
Windows NT server, the later natively capable of encrypted password support.
</para>
<sect3>
<title>Configuring Samba for Seemless Windows Network Integration</title>
<para>
MS Windows clients may use encrypted passwords as part of a challenege/response
authentication model (a.k.a. NTLMv1) or alone, or clear text strings for simple
password based authentication. It should be realized that with the SMB protocol
the password is passed over the network either in plain text or encrypted, but
not both in the same authentication requests.
</para>
<para>
When encrypted passwords are used a password that has been entered by the user
is encrypted in two ways:
</para>
<itemizedlist>
<listitem><para>An MD4 hash of the UNICODE of the password
string. This is known as the NT hash.
</para></listitem>
<listitem><para>The password is converted to upper case,
and then padded or trucated to 14 bytes. This string is
then appended with 5 bytes of NULL characters and split to
form two 56 bit DES keys to encrypt a "magic" 8 byte value.
The resulting 16 bytes for the LanMan hash.
</para></listitem>
</itemizedlist>
<para>
MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0
pre-service pack 3 will use either mode of password authentication. All
versions of MS Windows that follow these versions no longer support plain
text passwords by default.
</para>
<para>
MS Windows clients have a habit of dropping network mappings that have been idle
for 10 minutes or longer. When the user attempts to use the mapped drive
connection that has been dropped, the client re-establishes the connection using
a cached copy of the password.
</para>
<para>
When Microsoft changed the default password mode, support was dropped for caching
of the plain text password. This means that when the registry parameter is changed
to re-enable use of plain text passwords it appears to work, but when a dropped
service connection mapping attempts to revalidate it will fail if the remote
authentication server does not support encrypted passwords. This means that it
is definitely not a good idea to re-enable plain text password support in such clients.
</para>
<para>
The following parameters can be used to work around the issue of Windows 9x client
upper casing usernames and password before transmitting them to the SMB server
when using clear text authentication.
</para>
<para><programlisting>
<ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable>
<ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable>
</programlisting></para>
<para>
By default Samba will lower case the username before attempting to lookup the user
in the database of local system accounts. Because UNIX usernames conventionally
only contain lower case character, the <parameter>username level</parameter> parameter
is rarely needed.
</para>
<para>
However, passwords on UNIX systems often make use of mixed case characters.
This means that in order for a user on a Windows 9x client to connect to a Samba
server using clear text authentication, the <parameter>password level</parameter>
must be set to the maximum number of upper case letter which <emphasis>could</emphasis>
appear is a password. Note that is the server OS uses the traditional DES version
of crypt(), then a <parameter>password level</parameter> of 8 will result in case
insensitive passwords as seen from Windows users. This will also result in longer
login times as Samba hash to compute the permutations of the password string and
try them one by one until a match is located (or all combinations fail).
</para>
<para>
The best option to adopt is to enable support for encrypted passwords
where ever Samba is used. There are three configuration possibilities
for support of encrypted passwords:
</para>
</sect3>
<sect3>
<title>Use MS Windows NT as an authentication server</title>
<para>
This method involves the additions of the following parameters in the smb.conf file:
</para>
<para><programlisting>
encrypt passwords = Yes
security = server
password server = "NetBIOS_name_of_PDC"
</programlisting></para>
<para>
There are two ways of identifying whether or not a username and
password pair was valid or not. One uses the reply information provided
as part of the authentication messaging process, the other uses
just and error code.
</para>
<para>
The down-side of this mode of configuration is the fact that
for security reasons Samba will send the password server a bogus
username and a bogus password and if the remote server fails to
reject the username and password pair then an alternative mode
of identification of validation is used. Where a site uses password
lock out after a certain number of failed authentication attempts
this will result in user lockouts.
</para>
<para>
Use of this mode of authentication does require there to be
a standard Unix account for the user, this account can be blocked
to prevent logons by other than MS Windows clients.
</para>
</sect3>
</sect2>
<sect2>
<title>Domain Level Security</title>
<para>
When samba is operating in <emphasis>security = domain</emphasis> mode this means that
the Samba server has a domain security trust account (a machine account) and will cause
all authentication requests to be passed through to the domain controllers.
</para>
<sect3>
<title>Samba as a member of an MS Windows NT security domain</title>
<para>
This method involves additon of the following paramters in the smb.conf file:
</para>
<para><programlisting>
encrypt passwords = Yes
security = domain
workgroup = "name of NT domain"
password server = *
</programlisting></para>
<para>
The use of the "*" argument to "password server" will cause samba to locate the
domain controller in a way analogous to the way this is done within MS Windows NT.
This is the default behaviour.
</para>
<para>
In order for this method to work the Samba server needs to join the
MS Windows NT security domain. This is done as follows:
</para>
<itemizedlist>
<listitem><para>On the MS Windows NT domain controller using
the Server Manager add a machine account for the Samba server.
</para></listitem>
<listitem><para>Next, on the Linux system execute:
<command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command>
</para></listitem>
</itemizedlist>
<para>
Use of this mode of authentication does require there to be a standard Unix account
for the user in order to assign a uid once the account has been authenticated by
the remote Windows DC. This account can be blocked to prevent logons by other than
MS Windows clients by things such as setting an invalid shell in the
<filename>/etc/passwd</filename> entry.
</para>
<para>
An alternative to assigning UIDs to Windows users on a Samba member server is
presented in the <ulink url="winbind.html">Winbind Overview</ulink> chapter
in this HOWTO collection.
</para>
</sect3>
</sect2>
<sect2>
<title>ADS Level Security</title>
<para>
For information about the configuration option please refer to the entire section entitled
<emphasis>Samba as an ADS Domain Member.</emphasis>
</para>
</sect2>
</sect1>
</chapter>