svn commit: samba-docs r657 - in trunk/Samba3-HOWTO: .

[jht at samba.org]

Author: jht
Date: 2005-06-19 05:37:39 +0000 (Sun, 19 Jun 2005)
New Revision: 657

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba-docs&rev=657

Log:
Another partial update. More to follow.
Modified:
   trunk/Samba3-HOWTO/TOSHARG-BDC.xml
   trunk/Samba3-HOWTO/TOSHARG-PDC.xml


Changeset:
Modified: trunk/Samba3-HOWTO/TOSHARG-BDC.xml
===================================================================
--- trunk/Samba3-HOWTO/TOSHARG-BDC.xml	2005-06-19 03:40:21 UTC (rev 656)
+++ trunk/Samba3-HOWTO/TOSHARG-BDC.xml	2005-06-19 05:37:39 UTC (rev 657)
@@ -29,26 +29,36 @@
 
 <para>
 <indexterm><primary>SAM backend</primary><secondary>LDAP</secondary></indexterm>
-Samba-3 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain
-Controller (PDC). A Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be
-either a common master LDAP server or a slave server. The use of a slave LDAP server has the
-benefit that when the master is down, clients may still be able to log onto the network.
-This effectively gives Samba a high degree of scalability and is an effective solution
-for large organizations. If you use an LDAP slave server for a PDC,
-you will need to ensure the master's continued availability &smbmdash; if the
-slave finds its master down at the wrong time, you will have 
-stability and operational problems.
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm>
+<indexterm><primary>scalability</primary></indexterm>
+Samba-3 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A
+Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP
+server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients
+may still be able to log onto the network.  This effectively gives Samba a high degree of scalability and is
+an effective solution for large organizations. If you use an LDAP slave server for a PDC, you will need to
+ensure the master's continued availability &smbmdash; if the slave finds its master down at the wrong time,
+you will have stability and operational problems.
 </para>
 
 <para>
+<indexterm><primary>two-way</primary><secondary>propagation</secondary></indexterm>
 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
+<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
 While it is possible to run a Samba-3 BDC with a non-LDAP backend, that
 backend must allow some form of "two-way" propagation of changes
 from the BDC to the master.  Only LDAP has such capability at this stage.
 </para>
 
 <para>
+<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
 <indexterm><primary>SAM backend</primary><secondary>non-LDAP</secondary></indexterm>
+<indexterm><primary>domain</primary><secondary>member</secondary><tertiary>server</tertiary></indexterm>
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>PDC</primary></indexterm>
+<indexterm><primary>trust account password</primary></indexterm>
+<indexterm><primary>domain trust</primary></indexterm>
 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
@@ -60,14 +70,14 @@
 </para>
 
 <para>
+<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
+<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
+<indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
+<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
 Considering the number of comments and questions raised concerning how to configure a BDC,
 let's consider each possible option and look at the pros and cons for each possible solution.
 <link linkend="pdc-bdc-table">The Domain Backend Account Distribution Options table below</link> lists 
 possible design configurations for a PDC/BDC infrastructure.
-<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
-<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
-<indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
-<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
 </para>
 
 <table frame="all" id="pdc-bdc-table"><title>Domain Backend Account Distribution Options</title>

Modified: trunk/Samba3-HOWTO/TOSHARG-PDC.xml
===================================================================
--- trunk/Samba3-HOWTO/TOSHARG-PDC.xml	2005-06-19 03:40:21 UTC (rev 656)
+++ trunk/Samba3-HOWTO/TOSHARG-PDC.xml	2005-06-19 05:37:39 UTC (rev 657)
@@ -243,13 +243,41 @@
 </sect1>
 
 <sect1>
+<title>Comparison of Single Sign-on and Domain Security</title>
+
+<para>
+When network administrators  are asked to describe the benefits of Windows NT4 and active directory networking
+the most often mentioned feature is that of SSO. Many companies have implemented SSO solutions. The mode of
+implementation of a single sign-on solution is an important factor in the practice of networking in general,
+and is critical in respect of Windows networking. Where a company may have a wide variety of information
+systems, each of which require some form of user authentication and validation it is not uncommon that users
+may need to remember more than a dozen login IDs and passwords. The problem will be compounded when the
+password for each system must be changed at regular intervals, and particularly so where password uniqueness
+and history limits are applied.
+</para>
+
+<para>
+There is a wide perception that SSO is the answer to the problem of users having to deal with too many
+information system access credentials. Many elaborate schemes have been devised to make it possible to deliver
+a user-friendly SSO solution. The trouble is that if this implementation is not done correctly, the site may
+end up paying dearly by way of complexity and management overheads. Simply put, many SSO solutions are an
+administrative nightmare.
+</para>
+
+<para>
+SSO implementations may involve centralization of all user account information in one repository. Depending on
+... add stuff here JHT!
+</para>
+
+</sect1>
+
+<sect1>
 <title>Basics of Domain Control</title>
 
 <para>
 <indexterm><primary>domain control</primary></indexterm>
-Over the years, public perceptions of what domain control really is has taken on an
-almost mystical nature. Before we branch into a brief overview of domain control,
-there are three basic types of domain controllers.
+Over the years, public perceptions of what domain control really is has taken on an almost mystical nature.
+Before we branch into a brief overview of domain control, there are three basic types of domain controllers.
 </para>
 
 <sect2>