Progress update.

(This used to be commit 86f20eacb8f5e707b07e6d7aced55c3d2b2d9d6a)

1 files changed, 147 insertions, 31 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-PDC.xml b/docs/Samba3-HOWTO/TOSHARG-PDC.xml
index a82d36e9dd..99014eba01 100644
--- a/docs/Samba3-HOWTO/TOSHARG-PDC.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-PDC.xml
@@ -243,55 +243,171 @@ Information Databases</link>.
 </sect1>
 
 <sect1>
-<title>Comparison of Single Sign-on and Domain Security</title>
+<title>Single Sign-On and Domain Security</title>
 
 <para>
+<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+<indexterm><primary>active directory</primary></indexterm>
+<indexterm><primary>authentication</primary></indexterm>
+<indexterm><primary>validation</primary></indexterm>
+<indexterm><primary>password uniqueness</primary></indexterm>
+<indexterm><primary>password history</primary></indexterm>
 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.
+the most often mentioned feature is that of single sign-on (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. A company may have a wide variety of
+information systems, each of which requires a form of user authentication and validation, thus it is not
+uncommon that users may need to remember more than ten login IDs and passwords. This problem is 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>
+<indexterm><primary>management overheads</primary></indexterm>
+There is a broadly held perception that SSO is the answer to the problem of users having to deal with too many
+information system access credentials (username/password pairs). 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>
-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.
+<indexterm><primary>identity management</primary></indexterm>
+<indexterm><primary>authentication system</primary></indexterm>
+<indexterm><primary>SSO</primary></indexterm>
+SSO implementations utilize centralization of all user account information. Depending on environmental
+complexity and the age of the systems over which a SSO solution is implemented, it may not be possible to
+change the solution architecture so as to accomodate a new identity management and user authentication system.
+Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
+behalf of the user. The software that gets layered over the old system may simply implement a proxy
+authentication system. This means that the addition of SSO increases over-all information systems complexity.
+Ideally, the implementation of SSO should reduce complexity and reduce administative overheads.
+</para>
+
+<para>
+<indexterm><primary>centralized identity management</primary></indexterm>
+<indexterm><primary>identity management</primary><secondary>centralized</secondary></indexterm>
+<indexterm><primary>centralized</primary><secondary>authentication</secondary></indexterm>
+<indexterm><primary>legacy systems</primary></indexterm>
+<indexterm><primary>access control</primary></indexterm>
+The initial goal of many network administrators is often to create and use a centralized identity management
+system. It is often assumed that such a centralized system will use a single authentication infrastructure
+that can be used by all information systems. The Microsoft Windows NT4 security domain architecture and the
+Micrsoft active directory service are often put forward as the ideal foundation for such a system. It is
+conceptually simple to install an external authentication agent on each of the disparate infromation systems
+that can then use the Microsoft (NT4 domain or ads service) for user authentication and access control. The
+wonderful dream of a single centralized authentication service is commonly broken when realities are realized.
+The problem with legacy systems is often the inability to externalize the authentication and access control
+system it uses because its implementation will be excessively invasive from a re-engineering perspective, or
+because application software has built-in dependencies on particular elements of the way user authentication
+and access control were designed and built.
+</para>
+
+<para>
+<indexterm><primary>meta-directory</primary></indexterm>
+<indexterm><primary>credentials</primary></indexterm>
+<indexterm><primary>disparate information systems</primary></indexterm>
+<indexterm><primary>management procedures</primary></indexterm>
+<indexterm><primary>work-flow protocol</primary></indexterm>
+<indexterm><primary>rights</primary></indexterm>
+<indexterm><primary>privileges</primary></indexterm>
+<indexterm><primary>provisioned</primary></indexterm>
+Over the past decade an industry has been developed around the various methods that have been built to get
+around the key limitations of legacy information technology systems. One approach that is often used involves
+the use of a meta-directory. The meta-directory stores user credentials for all disparate information systems
+in the format that is particular to each system. An elaborate set of management procedures is coupled with a
+rigidly enforced work-flow protocol for managing user rights and privileges within the maze of systems that
+are provisioned by the new infrastructure makes possible user access to all systems using a single set of user
+credentials.
+</para>
+
+<para>
+<indexterm><primary>Organization for the Advancement of Structured Information Standards</primary><see>OASIS</see></indexterm>
+<indexterm><primary>Security Assertion Markup Language</primary><see>SAML</see></indexterm>
+<indexterm><primary>Federated Identity Management</primary><see>FIM</see></indexterm>
+<indexterm><primary>secure access</primary></indexterm>
+The Organization for the Advancement of Structured Information Standards (OASIS) has developed the Security
+Assertion Markup Language (SAML), a structured method for communication of authentication information. The
+over-all umbrella name for the technologies and methods that deploy SAML is called Federated Identity
+Management (FIM). FIM depends on each system in the complex maze of disparate information systems to
+authenticate their respective users and vouch for secure access to the services each provides.
+</para>
+
+<para>
+<indexterm><primary>Simple Object Access Protocol</primary><see>SOAP</see></indexterm>
+<indexterm><primary>federated organizations</primary></indexterm>
+<indexterm><primary>Liberty Alliance</primary></indexterm>
+<indexterm><primary>federated-identity</primary></indexterm>
+<indexterm><primary></primary></indexterm>
+<indexterm><primary></primary></indexterm>
+SAML documents can be wrapped in a Simple Object Access Protocol (SOAP) message for the computer-to-computer
+communications needed for Web services. Or they may be passed between Web servers of federated organizations
+that share live services. The Liberty Alliance, an industry group formed to promote federated-identity
+standards, has adopted SAML 1.1 as part of its application framework. Microsoft and IBM have proposed an
+alternative specification called WS-Security. Some believe that the competing technologies and methods may
+converge when the SAML 2.0 standard is introduced. A few Web access-management products support SAML today,
+but implemention of the technology mostly requires customization to integrate applications and develop user
+interfaces. In a nust-shell, that is why FIM is a big and growing industry.
+</para>
+
+<para>
+<indexterm><primary>interoperability</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>GSSAPI</primary></indexterm>
+<indexterm><primary>general security service application programming interface</primary><see>GSSAPI</see></indexterm>
+Ignoring the bigger picture, which is beyond the scope of this book, the migration of all user and group
+management to a centralized system is a step in the right direction. It is essential for interoperability
+reasons to locate the identity management system data in a directory such as Microsoft Active Directory
+Service (ADS), or any proprietary or open source system that provides a standard protocol for information
+access (such as LDAP) and that can be coupled with a flexible array of authentication mechanisms (such as
+kerberos) that use the protocols that are defined by the various general security service application
+programming interface (GSSAPI) services.
 </para>
 
 <para>
-SSO implementations may involve centralization of all user account information in one repository. Depending on
-environmental complexity and the age of the systems over which a SSO solution is implemented, it may not be
-possible to change the solution architecture so as to accomodate a new identity management and user
-authentication system. Many SSO solutions involving legacy systems consist of a new super-structure that
-handles authentication on behalf of the user. The software that gets layered over the old system may simply
-implement a proxy authentication system. This means that the addition of SSO increases over-all information
-systems complexity. Ideally, the implementation of SSO should reduce complexity and reduce administative
-overheads.
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>authentication agents</primary></indexterm>
+A growing number of companies provide authentication agents for disparate legacy platforms to permit the use
+of LDAP systems. Thus the use of OpenLDAP, the dominant open source software implementation of the light
+weight directory access protocol standard. This fact, means that by providing support in Samba for the use of
+LDAP and Microsoft ADS make Samba a highly scalable and forward reaching organizational networking technology.
 </para>
 
 <para>
-JJJ More Info HERE!
+<indexterm><primary>ADS</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>authentication architecture</primary></indexterm>
+<indexterm><primary>ntlm_auth</primary></indexterm>
+<indexterm><primary>SQUID</primary></indexterm>
+<indexterm><primary>FIM</primary></indexterm>
+Microsoft ADS provides purely proprietary services that, with limitation, can be extended to provide a
+centralized authentication infrastructure. Samba plus LDAP provides a similar opportunity for extension of a
+centralized authentication architecture, but it is the fact that the Samba Team are pro-active in introducing
+the extension of authentication services, using LDAP or otherwise, to applications such as SQUID (the open
+source proxy server) through tools such as the <command>ntlm_auth</command> utility, that does much to create
+sustainable choice and competition in the FIM market place.
 </para>
 
 <para>
-Briefly describe:	1. New auth system that uses external auth.
-					2. SSO system that stores info about all IT systems, and provides front-end
-						app. that hides the IT systems beneath a veneer of its own.
-					3. Meta-directories and distribution if ID info.
-					4. The significance of Samba in the context of SSO
-					5. Implications of domain security
-						a) with NT4 domain
-						b) with ADS
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>OpenLDAP</primary></indexterm>
+<indexterm><primary>identity information</primary></indexterm>
+Primary domain control, if it is to be scalable to meet the needs of large sites, must therefore be capable of
+using LDAP. The rapid adoption of OpenLDAP, and Samba configurations that use it, is ample proof that the era
+of the directoy has started. Samba-3 does not demand the use of LDAP, but the demand for a mechanism by which
+user and group identity information can be distributed makes it an an unavoidable option.
 </para>
 
 <para>
-Other considerations: Should this stuff go elsewhere? Should it be dropped? Should this chapter be revamped?
+<indexterm><primary>BDC</primary></indexterm>
+<indexterm><primary>LDAP</primary></indexterm>
+<indexterm><primary>e-Directory</primary></indexterm>
+At this time, the use of Samba based BDCs, necessitates the use of LDAP. The most commonly used LDAP
+implementation used by Samba sites is OpenLDAP. It is possible to use any standards compliant LDAP server.
+Those known to work includes those manufactured by: IBM, CA, Novell (e-Directory), and others.
 </para>
 
 </sect1>