Password Synchronization

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.

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.