diff options
| -rw-r--r-- | docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 97 | ||||
| -rw-r--r-- | docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 34 | ||||
| -rw-r--r-- | docs/docbook/projdoc/ServerType.xml | 31 |
3 files changed, 120 insertions, 42 deletions
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 5d62902487..552834e929 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -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<#1b>, 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> diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 552a95c878..e8c60c8d6d 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -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> diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml index 13377b1d5a..8b567ca16f 100644 --- a/docs/docbook/projdoc/ServerType.xml +++ b/docs/docbook/projdoc/ServerType.xml @@ -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. |