Single Sign-On and Domain Security
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
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
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.