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

Typos and fixes resulting from VL feedback.

Browse Source 
(This used to be commit ab1ff35187924c31a8fa503c0d02c6b54605da4f)
This commit is contained in:
John Terpstra 2003-05-10 05:26:05 +00:00
parent 1263c6e36c
commit 05bc989ae8
3 changed files with 120 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
docs/docbook/projdoc/Samba-BDC-HOWTO.xml
View File

@ -31,34 +31,92 @@ and / or question and we will do our best to provide a solution.
<para>
Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain
Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can
operate with a slave LDAP server for the Account backend. This effectively gives samba a high
operate with a slave LDAP server for the Account backend. This effectively gives samba a high
degree of scalability. This is a very sweet (nice) solution for large organisations.
</para>
<para>
While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will
need to figure out precisely what is the best way to replicate (copy / distribute) the
user and machine Accounts backend. Again, Samba-3 provides a number of possibilities:
user and machine Accounts backend.
</para>
<para>
The use of a non-LDAP backend SAM database is particularly problematic because Domain member
servers and workstations periodically change the machine trust account password. The new
password is then stored only locally. This means that in the absence of a centrally stored
accounts database (such as that provided with an LDAP based solution) if Samba-3 is running
as a BDC, the PDC instance of the Domain member trust account password will not reach the
PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs this results in
overwriting of the SAM that contains the updated (changed) trust account password with resulting
breakage of the domain trust.
</para>
<para>
Considering the number of comments and questions raised concerning how to configure a BDC
lets consider each possible option and look at the pro's and con's for each theoretical solution:
</para>
<itemizedlist>
<title>Backup Domain Backend Account Distribution Options</title>
<listitem><para>
Passwd Backend is LDAP based, BDCs use a slave LDAP server
</para></listitem>
Solution: Passwd Backend is LDAP based, BDCs use a slave LDAP server
</para>
<para>
Arguments For: This is a neat and manageable solution. The LDAP based SAM (ldapsam)
is constantly kept up to date.
</para>
<para>
Arguments Against: Complexity
</para>
</listitem>
<listitem><para>
Passdb Backend is tdbsam based, BDCs use cron based "net rcp vampire" to
suck down the Accounts database from the PDC
</para></listitem>
</para>
<para>
Arguments For: It would be a nice solution
</para>
<para>
Arguments Against: It does not work because Samba-3 does not support the required
protocols. This may become a later feature but is not available today.
</para>
</listitem>
<listitem><para>
Make use of rsync to replicate (pull down) copies of the essential account files
</para></listitem>
</para>
<para>
Arguments For: It is a simple solution, easy to set up as a scheduled job
</para>
<para>
Arguments Against: This will over-write the locally changed machine trust account
passwords. This is a broken and flawed solution. Do NOT do this.
</para>
</listitem>
<listitem><para>
Operate with an entirely local accounts database (not recommended)
</para></listitem>
</para>
<para>
Arguments For: Simple, easy to maintain
</para>
<para>
Arguments Against: All machine trust accounts and user accounts will be locally
maintained. Domain users will NOT be able to roam from office to office. This is
a broken and flawed solution. Do NOT do this.
</para>
</listitem>
</itemizedlist>
</sect1>
@ -227,22 +285,8 @@ password) to the local Domain Controller, for valdation.
</sect2>
<sect2>
<title>When is the PDC needed?</title>
<para>
Whenever a user wants to change his password, this has to be done on the PDC. To find
the PDC, the workstation does a NetBIOS name query for SAMBA&lt;#1b&gt;, assuming this
machine maintains the master copy of the SAM. The workstation contacts the PDC, both
mutually authenticate and the password change is done.
</para>
</sect2>
</sect1>
<sect1>
<title>Backup Domain Controller Configuration</title>
@ -329,10 +373,13 @@ watching for updates to this section.
<title>Machine Accounts keep expiring, what can I do?</title>
<para>
This problem will occur when occur when the account files are replicated from a central
server but the local Domain Controllers are not forwarding machine account password updates
back to the central server, or where there is an excessive delay in replication of the centrally
changed machine account password to the local Domain Controller.
This problem will occur when occur when the passdb (SAM) files are copied from a central
server but the local Backup Domain Controllers. Local machine trust account password updates
are not copied back to the central server. The newer machine account password is then over
written when the SAM is copied from the PDC. The result is that the Domain member machine
on start up will find that it's passwords does not match the one now in the database and
since the startup security check will now fail, this machine will not allow logon attempts
to procede and the account expiry error will be reported.
</para>
</sect2>

34
docs/docbook/projdoc/Samba-PDC-HOWTO.xml
View File

@ -86,6 +86,14 @@ security protocols.
The benefits of Domain security are fully available to those sites that deploy a Samba PDC.
</para>
<note><para>
Network clients of an MS Windows Domain security environment must be Domain members to be
able to gain access to the advanced features provided. Domain membership involves more than just
setting the workgroup name to the Domain name. It requires the creation of a Domain trust account
for the workstation (called a machine account). Please refer to the chapter on Domain Membership
for more information.
</para></note>
<para>
The following functionalities are new to the Samba-3 release:
</para>
@ -96,8 +104,10 @@ The following functionalities are new to the Samba-3 release:
</para></listitem>
<listitem><para>
Adding users via the User Manager for Domains or via the Windows 200x Microsoft
Management Console.
Adding users via the User Manager for Domains. This can be done on any MS Windows
client using the Nexus toolkit that is available from Microsoft's web site.
At some later date Samba-3 may get support for the use of the Microsoft Manangement
Console for user management.
</para></listitem>
<listitem><para>
@ -294,10 +304,11 @@ MS Windows 200x domain control protcols also.
</para>
<para>
At this time Samba-3 is capable of acting as an <emphasis>ADS Domain Controller</emphasis> but
in only a limited and experimental manner. This functionality should not be depended upon
until the samba-team offers formal support for it. At such a time, the documentation will
be revised to duely reflect all configuration and management requirements.
At this time any appearance that Samba-3 is capable of acting as an
<emphasis>ADS Domain Controller</emphasis> is limited and experimental in nature.
This functionality should not be used until the samba-team offers formal support for it.
At such a time, the documentation will be revised to duely reflect all configuration and
management requirements.
</para>
</sect2>
@ -493,7 +504,7 @@ Here is an example &smb.conf; for acting as a PDC:
; security settings (must user security = user)
<ulink url="smb.conf.5.html#SECURITYEQUALSUSER">security</ulink> = user
; encrypted passwords are a requirement for a PDC
; encrypted passwords are a requirement for a PDC (default = Yes)
<ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">encrypt passwords</ulink> = yes
; support domain logons
@ -568,9 +579,12 @@ There are a couple of points to emphasize in the above configuration.
<title>Samba ADS Domain Control</title>
<para>
Samba-3 can behave and appear to MS Windows 200x and XP clients as an Active Directory Server.
The problem with doing this is that samba-3 is NOT an Active Directory server and does NOT yet
support all protocols needed to make this a possibility.
Samba-3 is not and can not act as an Active Directory Server. It can not truely function as
an Active Directory Primary Domain Controller. The protocols for some of the functionality
the Active Directory Domain Controllers is have been partially implemented on an experiemental
only basis. Please do NOT expect Samba-3 to support these protocols - nor should you depend
on any such functionality either now or in the future. The Samba-Team may well remove such
experiemental features or may change their behaviour.
</para>
</sect1>

31
docs/docbook/projdoc/ServerType.xml
View File

@ -134,9 +134,9 @@ reduce user complaints and administrator heartache.
<para>
There are in the SMB/CIFS networking world only two types of security: <emphasis>USER Level</emphasis>
and <emphasis>SHARE Level</emphasis>. We refer to these collectively as <emphasis>security levels</emphasis>. In implementing these two <emphasis>security levels</emphasis> samba provides flexibilities
that are not available with Microsoft Windows NT4 / 200x servers. Samba knows of fice (5)
that are not available with Microsoft Windows NT4 / 200x servers. Samba knows of five (5)
ways that allow the security levels to be implemented. In actual fact, Samba implements
<emphasis>SHARE Levl</emphasis> security only one way, but has for ways of implementing
<emphasis>SHARE Level</emphasis> security only one way, but has for ways of implementing
<emphasis>USER Level</emphasis> security. Collectively, we call the samba implementations
<emphasis>Security Modes</emphasis>. These are: <emphasis>SHARE, USER, DOMAIN, ADS, and SERVER</emphasis>
modes. They are documented in this chapter.
@ -306,6 +306,21 @@ security domain. This is done as follows:
</listitem>
</itemizedlist>
<note><para>
As of Samba-2.2.4 the Samba 2.2.x series can auto-join a Windows NT4 style Domain just
by executing:
<programlisting>
smbpasswd -j DOMAIN_NAME -r PDC_NAME -U Administrator%password
</programlisting>
As of Samba-3 the same can be done by executing:
<programlisting>
net join -U Administrator%password
</programlisting>
It is not necessary with Samba-3 to specify the DOMAIN_NAME or the PDC_NAME as it figures this
out from the smb.conf file settings.
</para></note>
<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
@ -418,10 +433,12 @@ workgroup mode.
</para></note>
<note><para>
<emphasis>Server level</emphasis> security is incompatible with what is known as
<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
if you want to use <emphasis>server</emphasis> level security you must disable the use of
<emphasis>sign and seal</emphasis> on all machines on your network.
<emphasis>Server level</emphasis> security is incompatible with the newer security features
in recent MS Windows networking protocols. In particular it is incompatible with NTLMv2.
Server Mode security also breaks Sign and Seal interoperability because only a domain member
can sign packets in the manner in which it is currently implemented in Samba-3.
If you chose to use Server Mode security this means it is necessary to disable Sign and Seal
on all workstations.
</para></note>
<sect3>
@ -470,7 +487,7 @@ for the user, this account can be blocked to prevent logons by other than MS Win
<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
authentication model (a.k.a. NTLMv1 and NTLMv2) 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 request.