Password Synchronization

Passwords have become a necessary evil to many users and administrators. Although passwords are a cheap solution for securing access to an IT infrastructure and its resources, poorly chosen or managed passwords can lead to insecure environments and the compromise of corporate data or resources. In addition, because different applications and environments have specific password requirements, most users end up with several passwords. Average users who must deal with different passwords often choose identical or easy-to-remember passwords. If a user's passwords aren't easy to remember, the user might record the passwords on a handy notepad. These practices make password compromise more likely than ever.

Several approaches exist for makingpasswords more secure and easier to manage. Options include enforcement of strongpassword policies, employment of credentialmapping solutions, and use of password synchronization.

Strong password policies can ensure that passwords are changed at regular intervals and that they adhere to certain complexity rules—both of which lower the chances of successful password guessing or brute force cracking-based attacks on password hashes. Credential mapping solutions map a user's credentials that are needed to access different resources to a set of primary user credentials. Successful authentication using the primary credentials transparently unlocks the other user credentials and provides single sign-on (SSO) for that particular user to the other resources.

The third approach—password synchronization—specifically targets the user and administrator problem of having to deal with different passwords. Password synchronization can significantly ease users' and administrators' lives because it reduces the problem of multiple passwords to the management and maintenance of just one password. In this article I focus on Microsoft solutions for synchronizing passwords between Active Directory (AD) and other repositories. To start with, I define password synchronization and discuss the challenges you might face when architecting a password synchronization solution.

Definition and Challenges
A password synchronization solution ensures that a user's passwords that are stored in different repositories are kept synchronized. A single synchronized password is easier to remember than multiple passwords, and users are far less prone to having problems and calling the Help desk. Users also tend to write down their single synchronized passwords less often.

Password synchronization solutions come in two flavors: one-way and bidirectional. Table 1 lists four Microsoft password synchronization solutions and their characteristics (including one-way or bidirectional). (For more information about these solutions, see the Learning Path.) One-way password synchronization solutions push password changes from a central "master" repository to a set of connected repositories—these solutions are also referred to as "password push" solutions. In bidirectional password synchronization solutions, password changes can occur in any of the connected repositories. Even though both solutions sound like simple copy operations, they pose a few interesting challenges.

One challenge arises from the fact that passwords are stored in a secure format. For example, in AD, passwords are always stored in a hashed format. Hash functions are one-way cryptographic ciphers: You can't derive the original password from a password hash. As a result, accessing a user's plaintext password under normal AD operations is impossible. Plaintext passwords are available only when the password is set (i.e., when the associated user account is created), reset by an administrator, or changed by the user. This also means that passwords can—unlike other user attributes— be synchronized only when a password set, reset, or change event occurs. Also, unless users communicate with the password synchronization solution only when they set or change their password, password synchronization solutions require special software logic that can intercept plaintext passwords when users set or change their password on an AD domain controller (DC) or a Novell NetWare directory server.

Another challenge is password complexity rules. Different repositories typically have different rules regarding password complexity. When you set up password synchronization between repositories, you must define the least common denominator set of password complexity rules for each of the connected repositories. If you don't align the password complexity rules, synchronization will fail. For security experts, this alignment of the password complexity rules is a valid reason to argue against the security of password synchronization solutions. Moreover, security experts typically aren't fond of password synchronization solutions because they think that synchronizing password credentials between the databases of different authentication authorities is dangerous. Their objections are based on the "key to the kingdom" argument: If you know a user's password, you can access other resources that are secured with the same password (as long as you know the correct user account on the target system). However, this problem shouldn't be overemphasized. Even with password synchronization, a significant barrier still exists for a malicious person to access information that's secured using a user ID/password-based authentication scheme. The user must know the single synchronized password and the correct user ID on the target system. Nevertheless, when you implement password synchronization you need to educate your users about their single synchronized password's crucial role. In addition, you must constantly remind users of the dangers of social engineering and of sharing their password with others.

Finally, bidirectional password synchronization solutions require a synchronization loopdetection mechanism. Without loop detection,password synchronization would go on foreverbetween the different repositories. This problem doesn't occur with one-way passwordsynchronization solutions.

Using ILM or IIFP
Microsoft Identity Lifecycle Manager (ILM, formerly known as Microsoft Identity Integration Server—MIIS) is Microsoft's provisioning or identity lifecycle management software. Besides directory synchronization, account provisioning, and deprovisioning services, ILM can also provide password synchronization and management services. ILM can provide these services between a wide range of connected repositories, including AD, Active Directory Application Mode (ADAM), Exchange 2000 Server or Exchange Server 2003, and Windows NT 4.0, as well as Lotus Notes, Sun ONE Directory Server, and Novell eDirectory. The latest ILM version is ILM 2007. For more information about ILM, go to the Microsoft Identity Lifecycle Manager 2007 Web site at http://www.microsoft.com/windowsserver/ilm2007/default.mspx

Microsoft's Identity Integration Feature Pack (IIFP) can provide identity directory synchronization, account provisioning and deprovisioning, and password synchronization services—but only between AD, ADAM, and Exchange 2000 or Exchange 2003 instances. You can download this free software package from http://www.microsoft.com/downloads/details.aspx?familyid=d9143610-c04d-41c4b7ea-6f56819769d5&displaylang=en

ILM and IIFP connectivity to other repositories is based on the existence of a set of connectors or Management Agents (MAs)—as Microsoft refers to them—that are installed on the ILM or IIFP server. ILM and IIFP password synchronization doesn't require the installation of special agents on the target systems. This means that users or administrators must always interact directly with ILM or IIFP when setting or changing passwords. Two notable exceptions to this rule that don't require any explicit interaction between a user and ILM for setting passwords are when the Password Change Notification Service (PCNS) is used and when ILM creates a new user account. In the first case users can directly interact with a Windows DC for setting or changing their passwords. (I explain PCNS in more detail later in the article.) In the latter case ILM initializes a user's password to a predefined value when the associated user account is created as part of ILM's user account provisioning process.

Password set and change operations are supported by the AD, ADAM, and NT 4.0 MAs. The Lotus Notes, Sun ONE Directory Server, and eDirectory MAs support only password set operations. ILM and IIFP can also be extended to provide password synchronization services to other repositories through the creation of custom password extensions. If you don't mind coding and getting your hands dirty, the Developer Reference that comes with ILM and IIFP describes in detail how to create these password extensions.

As I explained previously, passwords can only be synchronized when they're available in plaintext (i.e., when a password set, reset, or change operation occurs). ILM and IIFP support the following interfaces for intercepting password sets or changes and initiating a password synchronization operation to a set of connected repositories: the Helpdesk Password Reset and the Self-Service Password Reset Web applications, and the Change Password option in the Windows Ctrl+Alt+Del dialog box.

When using the Helpdesk Password Reset or the Self-Service Password Reset Web applications, users or administrators interact directly with the ILM or IIFP server through a Web interface. Both Web applications are free add-ons to ILM and IIFP that are included in the MIIS 2003 scenarios. You can download these scenarios, including the necessary code and deployment instructions, from http://www.microsoft.com/downloads/details.aspx?familyid=15032653-d78e-4d9d-9e486cf0ae0c369c&displaylang=en. Microsoft's "User-Based, Self-Service Password Change Solution Guide for MIIS 2003" (http://www.microsoft.com/downloads/details.aspx?familyid=7e90b216-6cfd-4ccd-bdb9-2cc6be00 4bc4&displaylang=en) describes the Self-Service Password Reset Web application.

When using the Change Password option in the Ctrl+Alt+Del dialog box, users interact with ILM or IIFP indirectly through their authenticating Windows DC. This password change mechanism requires the installation of the PCNS on all DCs in the domain where user password changes must be intercepted. The PCNS logic is included in ILM and IIFP1a. The PCNS can be installed on Windows 2000 and Windows Server 2003 DCs.

The PCNS is a Windows service that monitors AD password changes and notifies other servers (e.g., ILM servers) of these password changes. The PCNS consists of three pieces of software: a password filter DLL, the PCNS, and the PCNS configuration utility. The password filter DLL obtains a clear-text copy of the changed password from a DC's Local Security Authority (LSA—lsass.exe). The PCNS receives the password-change notifications from the password filter, queues them, and sends them to the target systems. The PCNS configuration utility is used to set the PCNS configuration data. This information is stored in AD and includes the PCNS notification targets.

ILM and IIFP can support only one-directional or "password push"–based password synchronization in mixed environments (i.e., Windows and non-Windows). Neither ILM nor IIFP can replicate password sets or changes originating on the non-Windows side of the synchronization channel to the Windows side.

Using SFU or Windows 2003 R2
Microsoft's Services for UNIX (SFU) 3.5 is a software package that Microsoft provides to Win2K and Windows 2003 customers at no additional cost and that includes tools and services for integrating Windows and UNIX/ Linux platforms. SFU also includes a password synchronization service. Windows 2003 R2 includes part of the SFU services, including the password synchronization service. For more information about SFU and its services, go to Microsoft's Windows Services for UNIX Web site (http://www.microsoft.com/technet/ interopmigration/unix/sfu/default.mspx).

The SFU 3.5 and Windows 2003 R2 password synchronization service can synchronize passwords between Windows 2003 R2, Windows 2003, Windows XP, Win2K Server, Win2K Pro, NT Server 4.0, and NT Workstation platforms on the Windows side, and HP-UX 11, Red Hat Linux 7.0, Solaris 7, and AIX 4.3.3 platforms on the UNIX side. The service can synchronize passwords between domains and standalone machines on the Windows side, and between Network Information Service (NIS) databases and standalone machines on the UNIX/Linux-side.

You can set SFU and Windows 2003 R2 password synchronization to work in both directions (i.e., from Windows to UNIX or from UNIX to Windows) for all the UNIX platforms I mentioned, with the exception of AIX. The SFU and Windows 2003 R2 password synchronization service triggers a password synchronization action each time a user updates his or her password on a Windows machine (for Windows-to-UNIX synchronization) or on a UNIX/Linux host (for UNIX-to-Windows synchronization).

To support this bidirectional password synchronization, SFU and Windows 2003 R2 password synchronization require the deployment of special password synchronization software. If passwords are to be synchronized between a Windows domain and UNIX/Linux environment, the SFU and Windows 2003 R2 password synchronization service must be installed on all Windows DCs. This requirement is necessary because password updates can occur on any server in a multi-master model. The password synchronization service must also be installed on a Windows standalone machine if passwords are to be synchronized between the standalone machine and UNIX/Linux. Windows-to-UNIX/Linux password synchronization requires the ssod daemon on the UNIX/Linux platform. UNIX/ Linux-to-Windows password synchronization requires the pam_sso module on the UNIX/ Linux side.

Using HIS
Host Integration Server 2006 (HIS 2006; http://www.microsoft.com/hiserver) is the most recent version of Microsoft's mainframe gateway server software. Earlier Microsoft HIS versions were referred to as SNA Server. HIS 2006 helps enterprises integrate their missioncritical host-based applications, data sources, messaging, and security systems within a Microsoft .NET-oriented architecture, enabling the reuse of IBM mainframe and midrange (IBM AS/400) data and applications across distributed environments.

HIS comes with an optional component called Enterprise Single Sign-On (ENTSSO) that can provide single sign-on (SSO) services between Windows and mainframe or midrange system environments. ENTSSO is a good example of a server-side credential caching-based SSO solution. In addition to server-side credential caching-based SSO, ENTSSO can also be used for bidirectional password synchronization between Windows and nonWindows environments. ENTSSO includes password synchronization interfaces and the PCNS. This is the same PCNS as for ILM and IIFP, which I explained previously. The PCNS can also send password change notifications to an HIS ENTSSO server.

Finally, HIS includes an agent that can make ENTSSO password synchronization bidirectional when synchronizing with AS/400 systems. For mainframes, a third-party software agent is required to achieve complete bidirectional synchronization with the security systems of IBM's Resource Access Control Facility (RACF) and ACF2, and CA's Top Secret. An example of a software vendor that provides an additional HIS ENTSSO password synchronization agent is Proginet (http://eps.proginet.com).

Using Services for NetWare
Services for NetWare is a software package that Microsoft provides at no additional cost and that simplifies the integration of AD and Novell Directory Services (NDS), eDirectory, or bindery-based environments. Services for NetWare can also provide one-way password synchronization from AD to a bindery, NDS, or eDirectory. The latest version is Services for NetWare 5.03; for more information, go to the Microsoft Windows Services for NetWare 5.03 Overview Web site (http://www.microsoft.com/windowsserver2003/techinfo/overview/sfncd.mspx).

Services for NetWare lets you use one of the following methods for password synchronization:

Or Using Third-Party Solutions?
The password synchronization solutions I discuss in this article each have unique characteristics and target specific synchronization scenarios. Obviously many other password synchronization solutions exist. Password synchronization logic is included in all of today's identity provisioning software (e.g., IBM Tivoli Identity Manager, HP OpenView Select Identity). In addition, specialized password synchronization products are available (e.g., M-Tech's P-Synch, Courion's PasswordCourier). Comparing the non-Microsoft provisioning solutions with ILM is difficult; the products have equivalent features and their differences are minor. However, the specialized password synchronization products stand out because they support a much wider range of connected repositories. These solutions also include a self-service password reset Web site (where end users can reset their passwords or unlock their accounts if they get locked out), a Help desk password reset portal (where Help desk personnel can reset passwords and unlock accounts), and several other key features such as a phone interface for password resets, automated password expiration emails, and logon script password expiration notifications. Of course, these extra features aren't free—so you need to decide whether your needs justify their cost. Microsoft's password synchronization solutions might well be your best bet.