Password Management Walkthrough

Article
10/05/2010

Applies To: Windows Server 2003 with SP1

Download Instructions

This document is available for download as a Windows Installer package at https://go.microsoft.com/fwlink/?LinkId=34336.

Introduction to Password Management

This document describes the approach and features involved in setting up and using Microsoft® Identity Integration Server 2003 to accomplish basic password management. Before you begin the exercise, become familiar with the series of exercises included with the Microsoft Identity Integration Server 2003, Enterprise Edition installation media, an introduction to the password management solution, and guidelines for installing password management files.

Studies have shown that one of the highest cost generators for help desks is resetting user passwords. The cost to the IT staff is measurable in time per user call. Lost employee productivity also incurs costs. The complexity of user passwords increases as organizations acquire more systems for which users have accounts. When employees can’t remember all of their passwords, they might resort to non-secure practices like taping notes to their monitors, for example. Minimizing the number of passwords that a user is required to remember, therefore, can reduce the IT costs of resetting passwords and can make your organization more secure. There are two approaches for efficient password management: automatic password synchronization and password management applications.

Because passwords in most modern systems are stored in an encrypted format, synchronizing passwords is not as simple as copying the password attribute from data source to data source. To work around this problem, automatic password synchronization solutions must install agents on system servers or domain controllers in order to capture the user’s password change event. This change is then sent to the password synchronization application which then sets the password for the user in all necessary systems. Typically, one or more systems are designated master systems, where users can initiate password changes, and those changes are then propagated to other systems of interest. The primary advantage of password synchronization is that the impact to the user is low, because they can change their password through the native interface, such as using CTRL+ALT+DEL in Windows.

The disadvantage of this method is high deployment costs. Software must be installed on all of the system servers, and in some cases on the client machines as well. Additionally, another password store is introduced which must be secured, along with the communication between the remote agents and the password synchronization server. All systems that can be “masters” for passwords must have the same password policies.

With password management applications, users must use a separate application to change their password. This application changes or sets the password for the user in all of the appropriate systems, thereby allowing the user’s password to be synchronized in all systems of interest when the user uses the application to manages the password. Advantages of this method include low deployment costs. Remote agents are not required on system servers, and if Web-based applications are used, no client software installs are required. The password policy for all systems can be centrally enforced.

One disadvantage of using password management applications is that user education is required. The end user must be trained to use a separate application in order to change their password. A password management application that allows IT administrators to set a user’s password in all relevant systems, however, can reduce help desk costs.

It is important to note that synchronizing passwords does not provide a single sign-on solution (SSO), which allows a user to access multiple systems with only a single log in operation. Also, even with a password solution, end users may have multiple, different, log-in account names to remember for the different systems.

Password Management in Microsoft Identity Integration Server 2003

Microsoft Identity Integration Server 2003 offers several password management capabilities designed to reduce administration costs. In addition to setting initial passwords during automatic account provisioning, Microsoft Identity Integration Server 2003 exposes password set and change interfaces via Windows Management Interface (WMI). These WMI interfaces provide a platform in which applications can locate user accounts based on Windows NT or Active Directory credentials and return any accounts that are linked to a user’s metaverse object. Password set or change operations can be applied to these accounts.

By using password management in Microsoft Identity Integration Server 2003, you can accomplish the following goals:

Reduce the number of different passwords users have to remember, and reduce the chances of having different passwords in their accounts.
Enable help desk operators or administrators to set user passwords (through a help desk password set Web application).
Perform simple password management by simultaneously setting or changing passwords in a user’s accounts (that is, different user accounts that all belong to the same user) to the same password.
Eliminate the risk of building an additional password or credential store.
Prioritize password management traffic as higher priority than other Microsoft Identity Integration Server 2003 export traffic by sending the password operations to the connected data sources in real time.

The solution implementation uses Web-based password management applications. Microsoft Identity Integration Server 2003 Identity Manager and the application programming interface (API) that is exposed through the WMI are used to implement these solutions. For the connected data sources that manage passwords in their store, you can activate password management when you configure the management agent in the Identity Manager Management Agent Designer. When you activate password management on a management agent, there is a system name attribute that is returned by using the WMI interface for each connector space object.

Management agents for the following data sources support password management in Microsoft Identity Integration Server 2003:

Active Directory® directory service
Active Directory Application Mode (ADAM)
Lotus Notes Releases 4.6 and 5.0
Sun and Netscape directory servers (formerly iPlanet Directory Server)
NT Windows® 4.0
Novell eDirectory 8.6.2 and 8.7

The following Microsoft Identity Integration Server 2003 security groups specifically support password management operations:

MIISBrowse —Members of this group have permission to gather information about a user’s accounts when doing search operations with WMI queries.
MIISPasswordSet —Members of this group have permission to perform account search, password set, and password change operations by using the password management interfaces with WMI.

All password set and change operations are written to the connector space objects on which the operations are attempted. To specify the number of events that you want to save in the connector space password history, in Identity Manager, on the Tools menu, click Configure Extensions, and then, under Configure Number of Password Events to Log, specify the number of events that you want to log.

Microsoft Identity Integration Server 2003 performs password operations in real time. This means that Microsoft Identity Integration Server 2003 does not require the use of encrypted metaverse attributes, it does not save passwords in the connector space, and it does not wait for currently running management agent operations to finish before performing a password operation. Passwords are set or changed in real time, regardless of when the next synchronization cycle is scheduled to run, or how long it will take. The password operations are performed in the connected data source with the management agent’s credentials

The password management application described here serves the purpose of simultaneously setting or changing a user’s password in multiple systems to the same password. Without using the password management application, if users change their passwords natively in the connected data source, their passwords in the native data source will no longer be synchronized with the rest of their passwords. The password management application prevents this problem by performing these operations for the selected systems simultaneously based on the user’s accounts that have been linked to their Microsoft Identity Integration Server 2003 identity data.

The Microsoft Identity Integration Server 2003 Password Management model is not based on import attribute flows from connected data sources. Microsoft Identity Integration Server 2003 does not read passwords from connected data sources. Information from the connected data source is one-way hashed data, and as a result, is of no importance to other connected data sources (for example, a Lotus Notes password is meaningless to Active Directory). By contrast, other password management systems use hashing or a similar encoding method to store passwords. This method is a greater security risk because after the password is changed in these systems, typically you cannot retrieve the password and push it back out to other systems without compromising the security of the system’s password storage facility.

Installing Password Management Files

In order to follow along with the examples presented in this document, you have to install the Password Management files from the Microsoft Identity Integration Server 2003 installation media. For directions, read PasswordManagementInstall.htm, in the Password Management folder on the installation media.

WMI Interface for Password Management

You can use the WMI interfaces available with Microsoft Identity Integration Server 2003 to search for user accounts that are related to a specific user’s identity (a critical component of any password management solution). In the Microsoft Identity Integration Server 2003 WMI interface for password management, you can search for related user accounts by using the MA configuration to determine which connector space and metaverse objects are joined.

Once the accounts have been located, these interfaces can be used to change or set the password for the accounts. The following management agent types support both password set and change operations:

Active Directory
Active Directory Application Mode
Windows NT 4.0

The following management agents support password set operations:

Lotus Notes Releases 4.6 and 5.0
Sun and Netscape directory servers (formerly iPlanet Directory Server)
Novell eDirectory 8.6.2 and 8.7

WMI MIIS_CSObject Class

The WMI interface exposes a class called MIIS_CSObject, which represents an instance of each connector space object. Complete information about the WMI MIIS_CSObject Class is available in "Microsoft Identity Integration Server 2003 Developer Reference".

Password Management Web Applications

Microsoft Identity Integration Server 2003 includes two Web applications: a help desk password management reset application, and an end user self-service password change application.

You can customize and extend the applications by changing the sample code when you install it, and you can configure application behavior by using the XML file that is provided with this scenario. You can extend the applications by using a module named Callbacks.vb, which is included with the password management files on the Microsoft Identity Integration Server 2003 installation media.

Help Desk Password Reset Application

In order to reset passwords with this application, help desk operators must be added to the MIISPasswordSet security group.

The user must supply the help desk operator with valid Active Directory or Windows NT user name and domain information. Microsoft Identity Integration Server 2003 validates these credentials against the directory (Active Directory or NT as appropriate) and locate the connector space object for the directory as well as the linked metaverse object representing this user. Microsoft Identity Integration Server 2003 then returns a list of all of the linked accounts representing this user in the systems of interest back to the application.

The account that corresponds to the supplied Active Directory or NT credentials is referred to as the “special connector.” The password set or change operation is always attempted on the special connector first, to verify that the password meets the minimum requirements of your password policy. Therefore, the Active Directory or NT directory should be configured to have the strictest password policy of all of the systems included in the password management operations. By default, if the password operation fails for the special connector, the application will not attempt to reset the passwords for the remaining accounts.

In addition to returning the displaying the list of accounts, the help desk Web application verifies the systems are available and the connection is secure. Depending on the configuration options, Microsoft Identity Integration Server 2003 can allow or disallow password operations to systems without secure connections.

The operator can then select all or only a sub-set of the accounts returned and then specify the new password. Microsoft Identity Integration Server 2003 will then perform the set operation for all of the selected accounts immediately and return the status.

The following is a more detailed walkthrough of how the help desk reset application works:

Using the Web application, the help desk operator uses the caller’s user name and domain name to search for the credentials and retrieve a list of the connector space objects that are joined to the user’s metaverse object. The following figure shows the user interface for a finding a user account.

Figure 1: Desk User Search Page
The Web application displays the list of connector space objects that belong to the user. The Web application uses the WMI interface to obtain this information. If a management agent does not support password management, objects in its connector space do not appear in the list. The list itself, or the accounts found, appear only if the settings in the configuration XML file allow it.
The help desk operator selects the accounts on which to set the password, and types a new password. Figure 5.2 illustrates the resulting display of accounts. In this example, the application has discovered four accounts associated with this user. For this example, the password is set in four systems named Corporate Forest, Corporate White Pages, Resource Forest, and Partner Forest. These system names are configured in Management Agent Designer.

Figure 2: Help Desk Account Selection Page
Note that the first account in the list has a check box to its left that cannot be cleared. That is because the account entered is known as the special connector. If the attempt to set the password on this connector is not successful and the application is configured to disallow partial processing, the other requests are not processed. This makes it possible to use the most restrictive password policy as the policy checking method.
The Web application makes a WMI call to Microsoft Identity Integration Server 2003 requesting that the password be set for each selected account. Each call to set a password for an account is processed individually.
The Web service application displays the status of each operation as well as an overall status for the request.

Self-Service Password Change Application

The application itself runs in the context of an account that must be a member of the MIISPasswordSet security group. The application uses these credentials to communicate with Microsoft Identity Integration Server 2003 to request password change and set operations.

The user must be logged on to a Windows system, because the application uses these credentials to perform the search operation.

Microsoft Identity Integration Server 2003 validates these credentials against the directory (Active Directory or NT as appropriate) and locate the connector space object for this directory and the linked metaverse object representing this user. Microsoft Identity Integration Server 2003 then returns back a list of all of the linked accounts representing this user in the systems of interest to the application.

The account that corresponds to the supplied Active Directory or NT credentials is referred to as the “special connector.” The password set or change operation is always attempted on the special connector first, to verify that the password meets the minimum requirements of your password policy, and to verify that the old password supplied is correct. If the old password is incorrect, the operation will not proceed for the remaining accounts.

In addition to returning and displaying the list of accounts, the help desk Web application verifies the systems are available and the connection is secure.

The user can then select all or only a sub-set of their accounts returned and specify the old and new password. Microsoft Identity Integration Server 2003 then attempts to change the password for the special connector. If this succeeds, the passwords for the remaining accounts are changed or set, depending on what operations are supported for the system.

The following is a more detailed walkthrough of how the self service application works:

When the user navigates to the Web application, it determines their user and domain name, and then retrieves a list of the connector space objects that are joined to the metaverse entry for this user.
The Web application displays the list of accounts for the user. The Web application uses the WMI interface to get this information. If a management agent does not support password management, objects in its connector space do not appear in the list. The list itself, or the accounts found, will only appear if the settings in the configuration XML file allow it.

Figure 3: Self-Service Password Change User Accounts
Note that the account shown has a check box to its left that cannot be cleared. That is because the account entered is known as the special connector. If the attempt to set the password on this connector is not successful, and the application is configured to disallow partial processing, none of the other requests will be processed. This makes it possible to use the most restrictive password policy as the policy-checking method.
If multiple accounts are returned, the user selects the accounts on which to change the password. Then the user enters their old password, and then a new password.
The Web application makes a WMI call to Microsoft Identity Integration Server 2003 requesting that the password be set for each selected account. Each call to set a password for an account is processed individually.
The Web application displays the status of each operation as well as an overall status for the request.

Web Application Configuration

Many of the behaviors of the Web applications are configurable through settings in the PasswordWebAppOptions.xml file. This file is located in C:\WINDOWS\system32\inetsrv\Microsoft Identity Integration Server. There are three sections in the configuration file that contain settings for Web applications, described in the following sections.

Configuration XML

The following is an example of the configuration XML file. Note that the <admin-app> section is the only section that changes the behavior of Web applications in Microsoft Identity Integration Server 2003.

The Help Desk application configuration options are contained in the <admin-app> section:

  <admin-app>
  <allow-non-secure>0</allow-non-secure>
  <show-non-secure>0</show-non-secure>
  <show-server-down>0</show-server-down>
  <show-connectors>1</show-connectors>
  <allow-if-partial>0</allow-if-partial>
  </admin-app>

The Self Service application configuration options are contained in the <user-app> section:

  <user-app>
  <allow-non-secure>0</allow-non-secure>
  <show-non-secure>0</show-non-secure>
  <show-server-down>0</show-server-down>
  <show-connectors>0</show-connectors>
  <allow-if-partial>0</allow-if-partial>
  <allow-set-if-change-fails>0</allow-set-if-change-fails>
  </user-app>

The final section, <object-types>, contains information about which management agents support password management and which object types contain user principle accounts. It is not recommended to remove or change any of the default settings in this section.

- <object-types>
- <object-type>
  <ma-type>Active Directory</ma-type>
  <object>user</object>
  </object-type>
- <object-type>
  <ma-type>Active Directory Application Mode (ADAM)</ma-type>
  <object>iNetOrgPerson</object>  
  </object-type>
- <object-type>
  <ma-type> Active Directory Application Mode (ADAM)</ma-type>
  <object>user</object>
  </object-type>
- <object-type>
  <ma-type>Windows NT 4.0</ma-type>
  <object>user</object>
  </object-type>
- <object-type>
  <ma-type>Sun and Netscape directory servers</ma-type>
  <object>iNetOrgPerson</object>
  </object-type>
- <object-type>
  <ma-type>Lotus Notes</ma-type>
  <object>Person</object>
  </object-type>
- <object-type>
  <ma-type>Novell eDirectory</ma-type> 
  <object>person</object> 
  </object-type>
- <object-type>
  <ma-type>Novell eDirectory</ma-type> 
  <object>organizationalPerson</object> 
  </object-type>
- <object-type>
  <ma-type>Novell eDirectory</ma-type> 
  <object>inetOrgPerson</object> 
  </object-type>
  </object-types>

Configuration Options Reference

The tags in the XML file are used to define the behavior of the Web applications. There are two different sections for configuration options for the help desk and self-service Web applications. The following table defines these options.

Configuration Option Reference Table

Option	Description
Allow-non-secure	Allows an application to try setting passwords through a non-secure connection. If this is false and if any non-secure connections are shown, their check box is unavailable. If this option is true, and the option to show non-secure is false, then this option has no effect.
Show-non-secure	Determines whether or not to show non-secure connections in the list of accounts.
Show-server-down	Determines whether or not to show server-down connections in the list of accounts.
Show-connectors	Determines whether to show accounts in addition to the one that was found from the initial search credentials. If false, it shows only the special connector found and no others. This overrides the show-non-secure and show-server-down settings above.
Allow-if-partial	Continues updating passwords even if it fails on the special connector.
Allow-set-if-change-fails	This setting only applies to the self service application. For Active Directory and Windows NT 4.0, by default MIIS will attempt a password change operation. This requires the correct old password. If the user has multiple Active Directory or NT 4.0 accounts that do not already have the same password, the change operation will fail. With this option enabled, when this situation occurs, MIIS will attempt to set the password if the change operation fails. Note: the change operation must still succeed for the special connector.

The object types section contains a list of those objects that are valid password objects. For example, by not including Active Directory contact objects, if they are found as a connector object, they are not shown and no password operation will be attempted on them. The order of this list determines the order in which the passwords are updated and the order in which they appear in the Web application.

The following table defines the configuration settings for management agent and object types supported. It not recommended that any of the default settings be changed.

Configuration Option Reference Table

Option	Description
object-types	Starts the section where object types are listed.
object-type	Starts a section where the information for one object type is listed.
Object	Name of the object type for which password operations are provided (for example, user). Note that in the example above, there is no entry for Active Directory contact. This means the system does not try to perform password management operations on contact objects found in an Active Directory connector space.
ma-type	Text that represents the type of management agent (for example, Active Directory).

The next table lists the valid management agent types for use with the password management Web application.

Management Agent Types for Password Management

Value	Meaning
Active Directory	Management agent for Active Directory
Active Directory Application Mode (ADAM)	Management agent for Active Directory Application Mode (ADAM)
Novell eDirectory	Management agent for Novell eDirectory 8.6.2 and 8.7
Lotus Notes	Management agent for Lotus Notes 4.6 and 5.0
Sun and Netscape directory servers	Management agent for Sun and Netscape directory servers
NT 4.0 Windows	NT 4.0 Management agent for Windows

Customizing the Web Applications

The applications share a common module that you can use to extend function the functionality of the web applications. When certain events happen, for instance, a search fails, you can determine what action to take or what messages to display. For example, to set or change passwords for systems not covered by Microsoft Identity Integration Server 2003, you can write additional code that can be called after the Web application has completed the request.

The following table describes the functions for which you can modify the supplied code, or extend the functions of the applications by writing additional code.

Customization Functions Reference

Function	Description
ConnectorCompleted	Called after set or change of password for each connector on which an operation was attempted; allows additional processing after connector.
GetAccountDisplayString	Called on each connector found. Returns the string that is displayed for account name.
GetConnectionDisplayString	Called for each connector found. Returns the string that is displayed in the connection status column for each account.
GetOverallStatusString	Determines the overall status string that is shown.
GetStatusDisplayString	Called on each connector found. Returns the string that is displayed in the status column for each account.
RequestCompleted	Called after the set of connectors for which password management operations were performed; allows additional processing after the entire request is complete.
ShouldAccountBeChecked	Called on each connector found. Determines whether the connector status box is or is not in a checked state.
ShouldAccountBeDisabled	Called on each connector found. Determines whether the connector status box is or is not disabled.
ShouldShowOnTable	Called on each connector found. Determines whether the connector is or is not visible on the Select Accounts page.

Summary

This document highlighted the following points:

Password management with Microsoft Identity Integration Server 2003 is accomplished with a WMI interface that allows searching for information from the connector spaces and metaverse.
Password management with Microsoft Identity Integration Server 2003 is secured by using security groups that you configure when you install Microsoft Identity Integration Server 2003.
The list of management agents that you can use with the set or change methods from the WMI interface is defined by whether or not the connected data source allows password management natively.
Password management Web applications that perform help desk password resets and self-service password changes.
You configure the Web applications by using an XML file that specifies the desired application behavior.
You extend the functions of the Web applications by implementing or extending functions in a common module. This module contains the definitions of functions that the applications call to perform such things as setting display strings for accounts and systems. If you need to set passwords in additional systems, you can write additional logic to perform that function from the callback after the request has been completed.
Microsoft Identity Integration Server 2003 does not read passwords from connected data sources, but rather allows users and help desk operators to manage passwords from a central set of Web applications.
Password operations go out to connected data sources regardless of scheduling or duration of management agent operation. If a management agent for a connected data source is currently processing 1,200 out of 1,200,000 objects and a help desk password reset is performed, the user’s password is reset immediately, and does not have to wait for the next management agent to run after its current job is finished.

Additional Resources

Other Microsoft products that offer password management or synchronization features:

Microsoft Windows Services for Unix: Services for UNIX includes two-way, bi-directional Windows-to-UNIX and UNIX-to-Windows password synchronization. Services for UNIX Password Synchronization supports both local and domain account Windows password synchronization. Domain account synchronization requires that Password Synchronization be installed on Windows NT or Windows 2000-based domain controllers.

Services for Netware: Services for Netware includes Microsoft Directory Synchronization Services (MSDSS) that supports password synchronization between NDS and Active Directory. For more information, see https://go.microsoft.com/fwlink/?linkid=24824

Microsoft Host Integration Server: Supports password synchronization between Active Directory and AS/400 and other systems along with single sign on solutions. For more information, see https://go.microsoft.com/fwlink?linkid=99226.