When network administrators are asked to describe the benefits of Windows NT4 and active directory networking 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ntlm_auth utility, that does much to create sustainable choice and competition in the FIM market place.

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.

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.