diff options
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-PDC.xml')
| -rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-PDC.xml | 178 |
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> |