Microsoft Identity and Access Management - Password Management

Chapter 1: Introduction to the Password Management Paper

Executive Summary

This paper describes several password management approaches and includes guidance on password policies and how to enable password synchronization to multiple authentication stores by using Microsoft® Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1).

Password management is a significant part of any solution to improve security in an organization, because weak passwords are an open opportunity for anyone with access to those systems to authenticate themselves and mount an attack on other user accounts with weak passwords.

The Business Challenge

The effects of poor password management on both an organization's security and on its financial health are well known and well documented. Attackers often gain access to sensitive data through weak or stolen passwords. Alternatively, an attacker can use accounts as a foothold within a network to launch increasingly sophisticated and dangerous intrusions into an organization's IT systems.

One or more of the following issues is typically present in organizations with poor password management practices:

  • Weak and easily breakable passwords.
  • Passwords that users are not required to change frequently enough, which means that attackers can compromise the passwords through brute force and cryptographic attacks.
  • Users who each have several passwords.
  • Passwords that have been written down, which means they can be easily compromised.
  • Repeated passwords that are not synchronized, which causes confusion and lost productivity.
  • Numerous calls to the help desk for password resets, resulting in increased operational costs.
  • Strong passwords synchronized with systems that have inferior security characteristics, which limit the value and security that strong passwords provide.

To illustrate the size of the problem, the PricewaterhouseCoopers/Meta Group Survey 2002, titled "META Group White Paper: The Value of Identity Management" found that 45 percent of help desk calls are for password resets, and that automating password reset automation reduces this call volume by approximately one-third. For an organization with 10,000 users, the survey estimates a potential annual cost savings of $648,000.

Another business challenge is regulatory compliance. Many industries now have regulations in place that require specific security controls for passwords. These controls may be subject to independent audits, and noncompliance can result in dire consequences. Strong password security is required to meet many of these regulations.

The Business Benefits

Central to any password strategy is a focus on aggregation and integration of processes and technologies into a single comprehensive identity and access management solution. An effective solution will benefit an organization by:

  • Enabling a simple and cost-effective password change solution for extranet users.
  • Simplifying the end-user password management experience by reducing the number of places where users must change their passwords.
  • Improving the overall security of IT systems.
  • Enabling better integration with business partners' systems.

Who Should Read This Paper

The audience for this paper includes security professionals, architects, technology decision makers, consultants, and senior IT planners. The paper includes configuration files and code samples that IT professionals and developers can use on their own projects.

Reader Prerequisites

Readers who want to implement the guidance in this paper must have the following:

  • A working knowledge of MIIS 2003 with SP1.
  • A good understanding of the Active Directory® directory service.
  • The ability to program in the C# or C++ languages by using the Microsoft Visual Studio® .NET 2003 development environment (to work with the code samples).

Paper Overview

This chapter introduces the paper and describes the scenarios that the paper covers. The other chapters cover the following topics:

Chapter 1: Introduction to the Password Management Paper

The introduction provides an executive summary, describes the recommended audience for the paper, and gives an overview of each chapter in the paper.

Chapter 2: Approaches to Password Management

This chapter explores different approaches to password management. It examines the options available to increase security and improve manageability.

Chapter 3: Issues and Requirements

This chapter considers the Contoso Pharmaceuticals scenario. It expands on a few of the approaches that Chapter 2 outlines by describing technical issues and requirements in greater detail.

Chapter 4: Designing the Solution

This chapter covers the design of the Contoso scenario. Based on the information in Chapter 3, it shows the components of the password management solution.

Chapter 5: Implementing the Solution

This chapter takes the design from Chapter 4 and provides step-by-step prescriptive guidance on how to implement it. Use of the Contoso identity and access management platform demonstrates how you can implement password management to increase the security and usability of your information systems.

Chapter 6: Testing the Solution

This chapter details how to test the solution that you built in Chapter 5 and presents techniques that you can use to test an identity and access management solution in your own organization.

Chapter 7: Operating the Solution

This chapter completes the paper by detailing day-to-day operational procedures for the password management solution.

Solution Scenarios

The solution scenarios in this paper provide prescriptive guidance based on how the fictitious company Contoso Pharmaceuticals has decided to handle various password management approaches. The three scenarios are:

  • Enforcement of Strong Passwords.
  • Intranet Password Management.
  • Extranet Password Management.
Enforcement of Strong Passwords

A security audit at Contoso revealed that Active Directory user accounts were not protected by a strong password policy and were not changed on a regular basis. Forcing users to create strong passwords is a cornerstone of an effective password policy.

This solution scenario provides guidance on how to establish and configure a strong password policy with Active Directory and Group Policy.

Intranet Password Management

Many Contoso users have to remember separate passwords for the different internal Contoso systems that they use on a daily basis. This leads to security issues and numerous help desk calls. Password synchronization reduces the number of passwords that users must remember, as well as the associated help desk operating expenses.

This solution scenario provides guidance on how to implement the Password Change Notification Service (PCNS) feature of MIIS 2003 with SP1. This approach enables end users to change their passwords through a familiar mechanism, by using Microsoft Windows® XP or Windows 2000 clients and the CTRL+ALT+DEL Change Password dialog box.

Extranet Password Management

Partners and vendors for Contoso call the help desk regularly to change their passwords on one or more systems because they cannot currently change their passwords over the Internet. Password changes comprise a significant percentage of all help desk requests and, consequently, represent a significant cost to the company.

This solution scenario provides guidance on how to develop a Web page for password changes and build on the password synchronization capabilities of MIIS 2003 with SP1. The scenario also provides a method to notify extranet users when their passwords are about to expire. This approach enables users to change their passwords before expiration by using a single interface, significantly reducing support costs.

Chapter 2: Approaches to Password Management

As with most complex IT issues, there are many ways to approach password management. However, no single approach will solve all related problems for an organization. For each password management mechanism and process, either a security or operational tradeoff exists—and sometimes both. Most password management solutions require a combination of approaches to reach the intended goal.

This chapter discusses five approaches to password management:

  • Password policy
  • Password change
  • Password reset
  • Password synchronization
  • Credential mapping

Subsequent chapters describe how a subset of these approaches addresses the scenarios identified in Chapter 1, "Introduction to the Password Management Paper."

Password Policy

An important factor in working toward better password security is the creation and implementation of an organizational password policy. Microsoft recommends implementing a password policy that:

  • Enforces strong passwords.
  • Ensures that passwords are changed frequently.
  • Prevents immediate password reuse by maintaining password histories.
  • Incorporates a password lockout policy.

Password policies can vary not only between organizations, but also between different systems within an organization. Some identity stores might not support certain password strength or complexity requirements, so it might not be possible to enforce the same password policy throughout your organization.

The solution architect must first decide where the password policy should be applied. For most organizations, this will be the in the main directory service. However, the capabilities of the systems in your organization and the future direction of your IT infrastructure will influence this decision.

Note For more information about the security benefits that strong passwords provide, see the "Account Passwords and Policies" article on Microsoft® TechNet, and the Selecting Secure Passwords.

Password Policy Considerations

A successful password policy must consider many issues and tradeoffs. This section explores such aspects of password policy as:

  • How passwords are attacked.
  • Security and ease-of-use issues, such as:
    • Complexity.
    • Lockout policy.
  • Password reset approaches.
  • Password management on different kinds of accounts.
  • How to provision user account passwords.
  • Authentication without passwords.
How Passwords Are Attacked

Passwords can be attacked either while they are being used during an authentication exchange or while they are stored on a client, server, or identity store. It is important to consider how passwords are stored in identity stores. Identity stores such as the Active Directory® directory service do not store the user's plaintext password by default. Instead, Active Directory stores a cryptographic one-way hash of the password. This approach keeps privileged attackers (such as a domain admin) who can access users' password information from being able to see actual passwords that users have chosen.

The hash value of the password is often sufficient to masquerade as a user on the network. But as the following section discusses, keeping all forms of the password (including both plaintext and hashed) hidden from attackers still has important benefits.

Guessing a User's New Password

If a password is compromised, the only mitigation is to immediately change the password to a new value. However, knowledge of a user's previous password can often help the attacker guess the next value. Many users use iterative passwords in order to comply with password complexity policy while maintaining the ability to remember their passwords. While this is not strictly a subversion of an established password policy, it does weaken the strength of passwords.

For example, a user might create a clever password that consists of the first three letters of the names of his family members followed by a special character and a number, like BreConHar!22. This password value meets the complexity requirements of most systems today. Although this password would be difficult to crack, if an attacker ever did see the plaintext value then they could make a very good guess about what the next value of the user's password might be. For example the next password might be BreConHar!23, BreConHar!33, or BreConHar@22. Instead of requiring many millions of attempts to guess the password, an attacker might only have to try a few dozen variations on the original password to guess the new one.

Dictionary Attacks

Assuming that the plaintext password value is not available directly, an attacker can make educated guesses about the composition of a password. Most user-defined passwords are made up of whole words, in the user's native language. Users often find ways to simplify the requirements of password complexity. They will often replace numbers with similar-looking letters, such as replacing the letter "E" with a numeral "3," or the letter "a" with the ampersand (@) symbol—for example, spelling the word "meat" as "m3@t." Users will also prepend or append a word with a number or symbols, such as the previous BreConHar!23 example.

Current attacker tools take these behaviors into account when trying to guess passwords. Tools usually begin with common words and then expand the attack by using letter replacement and number prepending and appending. Attackers successfully compromise many passwords this way.

Brute Force Attacks

Usually the last resort of a determined attacker who really wants your passwords is to simply try all valid passwords until one works. This is called a brute force attack, because there is no elegance to it; an attacker throws all character combinations at the password until one of them works, a strategy that usually takes a very long time to complete because of its random nature and the large number of passwords that attackers must create and try.

Security and Ease-of-Use Issues

Security is always a tradeoff. The security tradeoff paradigm typically involves three factors:

  • Security. How secure must a solution be to achieve the desired goals? Ideally, the answer is based on the results of a risk analysis. For more information about how to conduct a risk analysis, see the Security Risk Management Guide.
  • Ease-of-use. Obviously, a system must be usable in order to provide desired functionality. Optimal usability occurs when users are not hindered in using the system to perform the desired tasks.
  • Cost. Designing a system that is both quite secure and easy to use is possible, but it usually costs much more than a simple system without those considerations.

Each of these factors should have some weight in system design decisions. But tradeoffs always exist. For example, you may receive feedback from management that the system must be as secure and as usable as possible. This is something that you can achieve, but only at greatly expanded cost. If cost is a limiting factor, you must design a system that trades cost for usability, security, or both.

Complexity and Length

The more complex a password is, the harder it is to use. Users can remember passwords that are their office numbers or children's names. But often these passwords are not strong enough, because a password's resistance to attack is a product of the password length and complexity. Organizations often implement password complexity to help improve security. When that happens, users are forced to memorize longer, more complex passwords. That increases the likelihood that they will forget the passwords and need to call the help desk for assistance. As a result, the cost of ownership for that system increases due to the increased help desk volume.

Password length presents a similar issue. Forcing a user to remember a 14-character password is, in many environments, unrealistic. Users typically do not remember passwords easily, especially when the passwords change frequently. This unfortunately can lead to bad habits such as writing the password down or telling a friend.

Lockout Policy

As mentioned previously, accounts can be locked out when a specified number of incorrect passwords have been used. This has the benefit of rendering an account that is under attack useless to the attacker for some length of time. Even if the attacker manages to obtain the correct password, the account is locked out, so the attack is unsuccessful.

But account lockout can also drive costs up. When users forget or repeatedly mistype their passwords, they can lock out their own accounts. They then have to unlock them, usually by calling the help desk. In addition, certain types of network-based attacks may lock out many accounts simultaneously when the attacks try to access network resources. So account lockout policy can be both good and bad, depending on your environment and the risk of online password attacks.

Password Reset Approaches

Organizations can take one of several approaches to address password reset requests. Obviously, the simplest solution is to avoid the need for password resets in the first place by educating users and ensuring that password policies are not too complex. However, there will always be some need for password resets. The common approaches to this problem include:

  • Self-service. A computer in a common location such as a lobby or mailroom is configured as a common-use kiosk with an application that asks users for authentication information and then resets their passwords. An alternative self-service implementation is a phone-based system in which the user calls a phone number to reset a password after proper authentication. This approach has a lower long-term cost because all expenses are related to initial development and deployment.
  • Help desk. Each time users want to reset their passwords, they must call the help desk. A representative must obtain the user's information and then use a tool to reset the password manually. The user receives the new password after some type of authentication or safeguard has occurred, such as a voicemail that includes the new password or a password verification request to the user's manager. The cost of this solution is high because of the labor involved, but the cost also remains flat over time.
  • Automation. A software-based system facilitates the automatic processing of account resets. The system monitors the accounts, and waits or a specific condition to occur, such as an account lockout or an account password expiration. At that time, the system generates a new password and provides it to the account holder through some secure means, such as an encrypted e-mail sent the user's manager or to a trusted help desk operator who then calls the user. This hybrid system is highly efficient in that it identifies and addresses the condition quickly. However, this solution results in high initial and ongoing (maintenance) costs.
Password Management on Different Kinds of Accounts

All accounts are not the same. Each account will most likely have access to different resources. Some will be highly restricted accounts, such as the ones that you provide for limited partner access or temporary employees. Others might be highly privileged and able to perform virtually any task within your enterprise. Because of this wide variance in account types, the password administration requirements will vary.

Note All accounts in a domain use the same domain-based Group Policy settings. You cannot administer password policy based on site or organizational unit containers. To implement more than one password policy, you must have more than one domain or you must implement specialized third-party software. For more information about this topic, see the "How to Configure Account Policies in Active Directory" white paper.

Generally, the different account types break down into four categories: user, administrative, service, and computer accounts. Each of these has special administrative needs and should be considered separately when planning an overall password management strategy.

User Account Passwords

In most cases, every user in an enterprise has a user account and a password. This is common practice. These are the vast majority of user accounts in any organization and are thus the primary concern of administrators. Password policies are usually built to address this category of accounts, and exceptions are made for other accounts.

User account passwords, more than those for any other account category, must represent a balance between usability and security. Service and administrator accounts can have very long and complex passwords because of their limited use, but user accounts are accessed daily by people with varying capabilities. You must determine how to balance password simplicity to ensure the productivity of your users with password security to help ensure unsuccessful password attacks.

Administrative Account Passwords

Administrative accounts on any kind of computer system are usually the most important kinds of accounts. Local administrator accounts have complete control over the local computer, while domain and enterprise administrator accounts have broad control over most computers within the domain or forest, respectively. An individual with an administrator user name and password has virtually unfettered access to the resources that recognize the account.

Administrator account passwords should be strong, changed frequently, and kept confidential. They should only be distributed as necessary to administrators who perform specific tasks. In addition, manual password changes should be required whenever IT personnel changes. At no time should a non-administrator without a specific need have access to such a password.

Service Account Passwords

Many services that run on Microsoft Windows Server™ 2003 run in a specific user context because of their specialized needs, such as administrative access to a database or network connectivity to similar servers. This is because all processes in Microsoft Windows® must have a user context to support Windows' discretionary access control security model. In many cases, services are configured to run as a specific user account, which is commonly called a service account. This account is no different than any other user account except for its specific security configuration.

Service account passwords are more difficult to manage than passwords for other account types. The main reason for this is that it can be quite difficult to change the password on each server that uses the service account. For example, if you have 20 servers that run a network-based service across your enterprise, you probably have one service account that the service uses on each server. When you change the password for that account, you must configure each server to use the new password. This can be difficult and expensive to manage, especially in the case of remote or headless servers.

Many administrators believe that a well-thought-out, lengthy, and complex password for a service account eliminates the need to change the password regularly. This is not the case. It is true that longer and better passwords reduce the frequency with which passwords must be changed. However, no password should ever remain static. All passwords must be changed periodically, and you must plan and manage that change.

Computer Account Passwords

The simplest account passwords to manage are computer accounts. These passwords are automatically generated and used when computers join a domain. Active Directory and the individual computer manage them automatically, and they require virtually no maintenance.

The only situation in which you need to worry about computer account passwords is when a domain controller is compromised. This event results in many security compromises, such as the attacker obtaining a copy of the hash for all computer account passwords. The attacker who controls the computer could easily make it a member of the domain without any further authentication, which would then make the computer a trusted entity on the network. However, if a domain controller is compromised, all accounts are similarly compromised, and this includes the service and administrator accounts. So when you consider that the attacker probably has an administrator password, the likelihood of a computer-account oriented attack is remote. For more information about recovering from such a breach, see the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.

Provisioning User Account Passwords

Accounts should have an initial password that is created during the account creation and distribution process. (This process is also called provisioning.) In some organizations, this initial password is blank or is a common, well-known password such as P@ssw0rd. Use of such common passwords presents a risk for all new accounts, because an attacker already has a known good password for the account. Even when the account is configured to change the password on first use, there is still a significant window of opportunity for an attacker to compromise that account.

A more secure practice is for the account administrator to create a pseudorandom password and securely distribute it to the user. There are numerous password generators available, and the Provisioning and Workflow solution in this series includes one. After the password is created, it is used as the initial account password and then discarded. The account name and password are then securely distributed to the user through a trusted third party, such as the employee's manager or administrator. This helps prevent the wrong user from obtaining the initial password to potentially conduct an attack while masquerading as an authentic user.

Authentication Without Passwords

Many people believe that passwords are an archaic leftover from early computing. In many ways, this is accurate. The concept of a user name and password for computer accounts comes from the early days of mainframe-based computing. It was the simplest and most cost-effective method available at the time to create separate user workspaces. But while the paradigm still remains sound today, there are alternatives to using passwords for initial user logon.

Some organizations rely on smart cards for authentication. A smart card has its own password, called a personal identification number (PIN), which unlocks the strong password on the card that is used for authentication. This combination removes the need to remember a long, complex password and instead uses the strength of multifactor authentication, because the user must have both factors (the card and the PIN) in order to authenticate.

Security can be greater in environments that use smart cards than in ones that use only passwords. The cost of smart card solutions has decreased significantly in the last few years. This combination of lower cost and increased security means that a smart card solution is quite feasible for many organizations.

Like any technology, though, smart cards have their drawbacks. The biggest disadvantage to smart cards is cost. The up-front cost of purchasing hardware and software is considerable. But even higher is the deployment cost, because an IT department must provision and distribute the cards to all users in a trustworthy manner. The long-term cost of ownership for smart card authentication is also high, because each incident of a lost, stolen, or failed card can represent a considerable cost. Even a smart card left at home by a forgetful employee results in significant help desk costs.

The use of biometric factors for authentication is also becoming more popular. Among these devices that attempt to identify users physically are retina scanners, thumbprint scanners, and hand scanners. These devices are all designed to eliminate the need for passwords by authenticating the user with data derived from physical attributes instead of user knowledge. This type of authentication also serves to prohibit users from sharing logon information, because users cannot share identical physical attributes. However, these devices can be quite costly to implement and maintain. You should also consult legal counsel before you deploy these devices.

Password Threats and Countermeasures

When you enforce the use of strong passwords, you help protect your organization against two primary threats: physical access and network authentication.

Preventing Physical Access

The threat of physical access is from internal trusted individuals, such as domain administrators. The potential threat from these individuals is based on their level of physical access to the domain controllers that store the passwords for all domain users. It is important to protect your domain controllers against physical access because anyone with access to a domain controller can compromise it. However, domain administrators are more likely to have access to domain controllers in secure locations.

Commonly available tools make it possible to extract the hashed values of user passwords from a compromised domain controller and attempt to retrieve the plaintext user password by performing a dictionary or a brute force attack. A hash is text (such as a password string) that has been transformed by a hash function, or algorithm, that takes a variable length string and creates a fixed-length binary output. A one-way hash is not reversible; the only way to discover the password is to guess the password, hash it, and then compare the value with the one stored in Active Directory. One-way hashes are not the same thing as encryption. Encrypted text can also be decrypted with the encryption key to retrieve the original plaintext.

Caution Active Directory user accounts include the account configuration option Store password using reversible encryption to store user passwords as encrypted plaintext. This setting is off by default but is required when you use protocols that require plaintext knowledge of a user's password for authentication purposes, such as Digest Authentication with Microsoft Internet Information Services version 5.0 (IIS 5.0) and later. However, enabling this option makes it possible for an administrator or other individual with physical access to the domain controller to derive the plaintext value of user passwords without having to mount a brute force or dictionary attack on the values stored in Active Directory. For this reason, Microsoft recommends not using this option unless absolutely necessary.

Securing Network Authentication

The second threat that strong passwords help mitigate is attacks against user passwords for network authentication. Authentication protocols such as Digest and NTLM use a one-way hash of the password to encrypt data during the challenge/response phase of the authentication handshake.

By comparing an observed handshake with all the possible permutations of the same challenge/response encrypted with values computed from a dictionary of possible passwords, an attacker could find a match. You can mitigate this threat in the same way as the previous one, by ensuring that passwords in your organization are complex enough to make dictionary attacks unlikely to discover them.

Even with very strong passwords, a dedicated attacker could still discover a user's password by using a sophisticated dictionary or, much more likely, through a social engineering attack. Social engineering attacks use surreptitious means to extract user names and passwords, such as when an attacker telephones a user to ask for the person's password while the attacker pretends to be someone from the help desk.

You might not be aware when an attacker discovers and begins using a password. Very often, a successful intrusion based on a compromised password looks just like any other user logon. Even the audit of account login activity, which is usually a good way to detect password-based attacks, will not help if the login event appears normal. In that situation, the only way to mitigate the compromised user account is to ensure that the password is changed on a regular basis, which limits the exposure of any compromised account. For these reasons, most organizations force password changes every 30 to 90 days.

Enforcing Password Strength

A central component of an effective password policy is the enforcement of strong passwords for users with access to critical systems. There are two main ways to increase password strength:

  • Increase password length.
  • Implement password complexity requirements.

Most password policies use a combination of both approaches to increase security.

Increasing Password Length

The length of a password is directly related to the amount of time that it takes an attacker to guess the password. For example, a brute force attack on a randomly-selected, six-character, all uppercase, alphabetical password could involve up to 266 (26x26x26x26x26x26, or 308,915,776) guesses to crack it.

Raising the number of characters in the password to 12 increases the number of possible guesses to 2612, or 9.5x1015 combinations. A system capable of trying 1,000,000 combinations a second could guess a six-character password in five minutes or less, but it would take more than 3,000 years to guess a 12-character password by using the brute force technique.

Implementing Password Complexity

For greater security, Microsoft recommends implementing a password policy that enforces complex passwords that use a combination of uppercase and lowercase letters, numbers, and special characters. Complex passwords, by definition, are not found in a dictionary, which makes a dictionary attack unlikely to succeed.

Complex passwords also help protect against brute force attacks. Using complex passwords increases the number of options to 82 (the number of standard characters on a US English keyboard) for each character in the password, which multiplies the number of permutations by nearly 1,000 for a six-character password and by nearly 100,000 for a 12-character password.

The following table provides examples of relative password strength for specific uses. This table assumes the same password-checking rate of 1,000,000 combinations per second.

Table 2.1. Password Length and Strength Ratings for Complex Passwords

Password length (characters)

Security rating

Average time to crack

Usage

1 to 7

Low

Very short

Insecure—not recommended.

8 to 9

Medium

32 years

Adequate for network logons in organizations with low risk profiles.

10 to 11

High

217,000 years

Network logons, external application logons, and virtual private networking (VPN) logons.

12 to 23

Very high

1,400,000,000 years

Network logons for high-security environments, VPN logons, and service account passwords.

24 or more

Extreme

Greater than the anticipated life span of the universe

One-time cryptographic key exchanges, highly valuable accounts.

The Average time to crack values in this table are provided only to help illustrate the relative strengths of different password lengths. Well-funded agencies, organizations, and other possible attackers might use powerful (possibly custom) hardware and sophisticated parallel processing techniques that reduce the time to crack by orders of magnitude. In addition, these values are based on a brute force attack of the key space and assume that the attacker will succeed after half of the keys are tried. Attacks based on knowledge of the user, knowledge of password composition, and so on may take less time.

Active Directory enforces password complexity through Group Policy settings, which allow you to select a password that must include three of the following four character groups:

  • Uppercase alphabetical
  • Lowercase alphabetical
  • Numbers
  • Special characters, such as &,*( or )

Chapter 5, "Implementing the Solution," in this paper includes guidance on how to implement strong passwords in Active Directory. In addition, several third-party software packages are available that allow greater control over password composition and enforcement than Active Directory does. If the available Active Directory and Microsoft Identity Integration Server 2003 with Service Pack 1 (MIIS 2003 with SP1) features do not meet your password needs, these packages may provide you with an alternate solution.

Using Pass Phrases

When implementing strong passwords, you must consider your users. For example, the password J2!yiu#9o would most likely defeat a dictionary attack and take a large amount of computational resources to derive by brute force. Although this password is relatively secure, password policy designers should consider how hard it will be for a user to remember it. A password policy that causes a significant increase in password reset calls to the help desk will not be considered favorably.

A more user-friendly option is to train and encourage users to employ a pass phrase as their password, for example Weak passwords can get Mike hacked. This phrase consists of six discrete words, each of which would likely exist in an attacker's dictionary. However, assuming that the average attacker dictionary contains 50,000 unique entries, the attacker would have to try an average of 500006/2, or 7.8x1027 word combinations to guess the pass phrase. In addition, this pass phrase is 35 characters long, putting it well above the Extreme security rating shown in Table 2.1. The following table shows the complexity of this pass phrase.

Table 2.2. Pass Phrase Length and Strength Rating

Pass phrase length (words)

Security rating

Average time to crack

Usage

6

Beyond Extreme

247 trillion years

All accounts as appropriate

The Average time to crack value in this table is based on a 50,000-word English dictionary and 1,000,000 attacks per second and assumes success after half of the key space has been attacked. The brute force attack might not be as effective as a social engineering or knowledge-based attack in this type of scenario. It would be far more effective — though certainly illegal and immoral — to blackmail, bribe, or physically abuse someone in order to obtain an password than to wait 247 trillion years for a technology-based attack to succeed.

Longer pass phrases are many orders of magnitude harder to crack than more complex but shorter passwords. Pass phrases usually contain both upper and lowercase words, spaces, and punctuation, which make them "complex passwords" by the previous definition. In addition, and possibly most importantly, pass phrases are easier for users to remember.

Unfortunately, some identity stores may not accept such long passwords. Alternatively, they might accept them, but only use the first n characters, which cause problems when you synchronize between different stores. Active Directory supports passwords of up to 127 characters but may require the development of custom code.

For more information about pass phrases, see "The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3" article on TechNet.

Implementing a Custom Password Filter DLL

If Active Directory Group Policy options do not meet your password complexity needs, then you might have to implement a custom password dynamic-link library (DLL) that has interfaces for both password filtering and password change notification. To create the custom DLL, a C-language programmer can modify the PassFilt code sample supplied with the Windows Platform Software Development Kit (SDK) and then implement the specific password complexity policy requirement for the organization. You can download the SDK from the Windows Server 2003 SP1 Platform SDK Web Install Web site.

SP1 for MIIS 2003 includes a custom password-filtering DLL, which you can deploy through Group Policy. This password-filtering DLL works in conjunction with the Password Change Notification Service (PCNS) that runs on the domain controllers. For more information, see the topic "Using Password Synchronization" in Microsoft Identity Integration Server 2003 Help on a computer running MIIS 2003 SP1.

A custom password DLL file intercepts the change password request and checks the password against one or more sets of complexity requirements. If the new password passes the checks, the password change request is passed to Active Directory. However, if a password change attempt fails, the Windows client displays a message that informs the user that password complexity requirements were not met.

The disadvantage of this approach is that you must install this custom DLL on every domain controller in your environment.

Figure 2.1 shows the relationship between the components that handle the password change request on both the Windows client and the domain controller.

Figure 2.1. Components in the Windows password change request process

On the client side, the LSASS.EXE process contains a component known as the Graphical Identification and Authentication DLL (GINA). The GINA component is invoked whenever the user performs a secure action sequence (SAS). In Windows, this is the CTRL+ALT+DEL key combination.

Performing the SAS causes the Windows Security dialog box to display with an option to change the password. If the user clicks Change Password, the Change Password dialog box displays fields in which the user must type her old password and new password (twice). When the user clicks OK, the GINA component creates a change password request that is encrypted and sent to a domain controller.

On the domain controller, the LSASS.EXE process receives the change password request and performs the following steps to process it:

  1. All installed password filters are called to validate the change request.
  2. The built-in password complexity checker is called to validate the change request.
  3. If the previous steps succeed, the account credentials are updated in Active Directory, and all installed password notification DLLs are called.
  4. Success or failure status is returned to the client.

Some independent software vendor (ISV) products replace the GINA component or install a GINA "stub" DLL to override the default GINA component behavior. These replacement GINA implementations may include password complexity checking. The main disadvantage of such approaches is that you must be absolutely sure that all workstations and servers on your network have the GINA component properly installed and configured. Otherwise, a user could circumvent the established password policy without knowing.

Enforcing Password Changes

Another aspect of a secure password policy is to ensure that users change passwords on a regular basis. Although it is difficult to eliminate completely bad security practices such as account sharing, regular password changes help ensure that such bad practices do not continue indefinitely. Password changes also reduce the effects of compromised passwords. To reduce the chance of certain kinds of attacks, such as brute force cryptographic attacks on relatively strong passwords, the password change interval should be less than the time it would take the attacker to guess the password by using automated means and reasonable computing resources.

Passwords for all accounts in Active Directory must be changed on a regular basis to improve the security of the network. You can configure Active Directory to support mandatory password changes for all users by specifying an expiration interval in Group Policy.

Note It is possible to set an account option in Active Directory for Password never expires. But you should set this option only for service accounts and for accounts that have password resets managed by an administrator, such as accounts for temporary staff. Be very cautious about setting this option for any other account, especially service accounts.

Active Directory password change enforcement is integrated with the Windows desktop through the GINA API referenced previously. GINA also prompts users to change their password before they expire. The default interval for this notification is 14 days, but you can change this by using the "Prompt user to change password before expiration" Active Directory Group Policy. The Windows desktop will not allow a user to log on to the network after the password has expired.

Organizations that choose to implement the Web-based password change application in MIIS 2003 with SP1 may want to disable the Change Password button in the Windows Security dialog box. This will prevent the accidental change of Active Directory passwords without the subsequent synchronization process that the Web application implements. You can accomplish this by using the "Remove Change Password" Active Directory Group Policy.

Maintaining Password Histories

Complex passwords can be difficult for users to create and remember. Some users have been known to circumvent the complex password requirement by having a favorite password; when they are requested to change it, they change it to a "temporary" password and then change it back immediately. Password histories prevent this practice by storing previous passwords and preventing users from reusing them until a suitable number of different passwords have been used.

Password histories are usually combined with minimum password ages, which prevents users from changing a password again until a certain amount of time has elapsed — usually at least a day.

Incorporating an Account Lockout Policy

The final component to consider in an effective password policy is an account lockout policy. Account lockouts provide users and service accounts with a certain number of attempts to log on, and if a user exceeds that number, the account is locked out. The user must then either wait until the account automatically re-enables itself (after a suitable time-out) or contact the help desk to have their account re-enabled manually.

Account lockouts work in conjunction with complex passwords and security auditing to counter brute force and dictionary attacks that attackers can direct against the authentication mechanism. However, you should carefully consider account lockout policies to ensure that they do not contribute to additional password reset requests. Choose a value for account lockouts that allows users to make a reasonable number of guesses, but locks the account if the user has obviously forgotten the password. Ensure that the help desk tracks requests to reset locked accounts, and if they become excessive (and are genuinely caused by users and are not attempts at unauthorized access), increase the number of tries before users are locked out.

While five is a common value for this setting, it can lead to a denial of service situation due to either an incorrect administrative configuration or a malicious attack. For more information about recommended account lockout settings, see the "Account Passwords and Policies" article on TechNet.

Password Change

Active Directory Group Policy settings provide a mechanism for ensuring that users must change their passwords at regular intervals. Password change is a similar process to password reset, except that with password change the user typically must authenticate to change their password. Therefore, the password change process does not have to identify the user.

There are three main ways that users can change their passwords in a Windows environment:

  • Use the Change Password button in the Windows Security dialog box.
  • Respond to the change password notification message dialog box.
  • Change the password through a Web-based interface that is implemented with a metadirectory product, such as MIIS 2003 with SP1.

In a heterogeneous environment with several identity stores, the password change must then replicate to multiple locations.

Password Synchronization

Password synchronization is a process that applies both to password reset and password change.

Quite a bit of confusion exists in the industry about the related terms password synchronization and password push. This series defines password synchronization as an operation in which a plaintext copy of a password is extracted from one location and then placed in one or more credential stores. Password synchronization can then occur in one of two ways:

  • One-way password synchronization (or password push). Changes to the password in one central system are intercepted and pushed to one or more additional stores.
  • Bidirectional password synchronization. Changes can be made in either store and then replicated to the other.

Although bidirectional password synchronization might seem appealing because of its flexibility and bidirectional nature, it can cause additional organizational and technical complexities. On the organizational side, users may not be certain where they should change their passwords. However, this can be a benefit, because in a properly implemented system it does not matter where the password is changed.

The technical challenges include how to implement special software on each platform that will avoid infinite loops. An infinite loop occurs when a system changes a password and then replicates the change to another system, which also changes it and replicates the change back to the first one. Security concerns also exist when passwords are stored in multiple locations, because one security breach could lead to compromises in multiple systems.

Storing Passwords in Active Directory

Many directory services, including Active Directory, use encryption and hash algorithms to protect the integrity of passwords. This design prevents implementation of password synchronization after a password has changed.

The recommended security configuration for Windows Server 2003 makes it impossible to retrieve a plaintext version of the password during normal operations. This important security feature of Active Directory is one that most Windows customers demand.

The only time that a password is available in plaintext on a domain controller running Windows Server 2003 is when you execute a command to change the password. By using the password notification service and a filter DLL described previously, you can create a solution to push password changes from Active Directory to other systems each time a password changes.

Password Push Solutions with Active Directory

Password push solutions work in conjunction with the password change event to provide proactive password management on multiple identity stores within an organization. Password push reduces the user frustration of dealing with different passwords by using Active Directory to distribute passwords to other connected systems.

Security considerations for password push include:

  • How well do the target systems secure the password information?
  • Who has administrative access to the target systems?
  • Do the target systems support complex or lengthy passwords or an entirely different password composition and history scheme?
  • Can you secure the communications channel used to push passwords to each target system?

The main concern with this approach is whether a target system receiving the password from Active Directory has compatible security characteristics. An attacker who has cracked a user's Active Directory password can access the user's e-mail, desktop, and remote resources. For this reason, it is critically important to understand the security ramifications of password synchronization with Active Directory.

If the target system stores password information in plaintext or uses weak encryption, then the system is probably not a good choice for participation in password synchronization. In addition, the system that receives the information should support the same level of security and similar protection mechanisms as that in Active Directory so that even trusted administrators cannot easily recover a user's plaintext password. Active Directory implements a sophisticated set of password protection mechanisms that include system encryption keys and one-way password hash technology to prevent credentials from being retrieved in plaintext.

If the target system does not have the same capability to support complex passwords as Active Directory, you might have to make the Active Directory password policy less complex to ensure that all of the target systems can adequately store the passwords. However, it is important to note that this situation could create an unacceptable level of security, because password strength is a key element to the overall security of your organization. You must decide, based on a risk analysis, whether to enforce the strong passwords and accept the compatibility limitation or to reduce the password strength and complexity and accept the corresponding increased risk.

Microsoft has developed several products to facilitate password management and synchronization with different target systems, including:

MIIS 2003 with Service Pack 1, Enterprise Edition (MIIS 2003 with SP1). MIIS 2003 with SP1 ships with several management agents that support password management and synchronization on different systems, including:

  • Active Directory.
  • Active Directory Application Mode (ADAM).
  • Lotus Notes.
  • Novell eDirectory.
  • Sun and Netscape directory servers.

MIIS 2003 with SP1 also provides password extension support with the following management agents:

  • Attribute–value pair text files
  • Delimited text files
  • Directory Services Markup Language (DSML)
  • Extensible connectivity
  • Fixed–width text files
  • IBM DB2 Universal Database
  • IBM Directory Server
  • LDAP Data Interchange Format (LDIF)
  • Microsoft SQL Server 2000
  • Oracle Database
  • Resource Access Control Facility (RACF)

After writing and enabling a password extension, you can use these management agents to call the extension to perform password operations.

You can use MIIS 2003 with SP1 to synchronize passwords to any of these systems through a Windows Management Instrumentation (WMI) interface. MIIS 2003 with SP1 is also packaged with a Web application through which users can change passwords and a separate Web application that allows help desk personnel to reset user passwords.

MIIS 2003 with SP1 synchronizes user password changes and password resets from Active Directory domain controllers to other connected data sources that use the PCNS and a password filter on each Active Directory domain controller. Password changes are encrypted and sent by using remote procedure call (RPC) to the server running MIIS 2003, which pushes the changes to the appropriate management agents.

For more information about MIIS 2003 with SP1 password management capabilities, including the list of MIIS 2003 with SP1 management agents that support password change and reset, download the Microsoft Identity Integration Server 2003 Scenarios.

  • Microsoft Host Integration Server. Host Integration Server supports many options for integrating computers that run the Windows operating system with mainframe or AS/400 systems. Password synchronization is a Host Integration Server feature. For AS/400 systems, password synchronization is bidirectional. For mainframes, a third-party provider is required to achieve complete bidirectional synchronization with security systems such as RACF, ACF/2, and Top Secret. For more information about password synchronization capabilities in Host Integration Server, see the Host Integration Server 2004 Product Overview page on TechNet.
  • Microsoft Windows Services for UNIX. Windows Services for UNIX version 3.5 provides the programs and services to support bidirectional password synchronization between Windows- and UNIX- or Linux-based computers. Password changes can originate from either Windows-based computers or UNIX-based computers, and the changes propagate to all configured computers. For more information about Windows Services for UNIX, download Windows Services for UNIX 3.5.
  • Microsoft Windows Services for Netware. Microsoft Directory Synchronization Services (MSDSS), which is included with Windows Services for NetWare 5, also includes support for password push from Active Directory to Novell eDirectory 8.7. For more information about MSDSS and the password synchronization capabilities of Services for Netware, see the Microsoft Windows Services for Netware 5.03 page.

Password Synchronization Products

The following ISVs produce password synchronization products:

  • SecurPass, part of the ManageID suite from Proginet
  • P-Synch from M-Tech
  • CA Identity Manager from Computer Associates
  • v-GO SSO from Passlogix
  • SecureLogin Single Sign-On Password Management Suite from ActiveIdentity

For more information about these products and ISVs, see the Overview paper in this series.

Credential Mapping

An alternative to password synchronization is credential mapping. This technology accepts that passwords (or other credentials such as X.509 certificates) will be different in various systems, but it provides an easy way to switch from one credential to another. You can generally implement credential mapping technologies on the client or by using middleware.

Some credential mapping products offer features that can completely control password management and are usually enabled on an individual target store basis. The advantages of this approach are:

  • Users do not have to remember passwords for all target systems. The software signs in on the user's behalf automatically.
  • Users do not have to change passwords on target systems. The software recognizes or anticipates password change requirements and changes the password randomly on the user's behalf.
  • Passwords on all target systems do not have to be the same as the password used in your primary authentication mechanism. This approach is especially useful for systems that do not have the same security characteristics, such as the ability to support complex passwords.

These credential mapping password management features work best if the target systems are only accessed through the credential management software.

Windows XP Credential Manager

The Windows XP client operating system and Windows Server 2003 provide a feature called Stored User Names and Passwords (also called Credential Manager) that manages user passwords and other credentials for applications.

Credential Manager is a client-based store for credentials that the user can configure to access file shares and Web applications hosted in untrusted domains. It also enables authentication to non-Windows-based systems that use user name and password combinations with Basic authentication, X.509 certificates for client authentication, and Microsoft .NET Passport credential types. It also supports roaming profiles that allow users to access the same credential sets from multiple workstations.

Credential Manager enables management of user credentials for different systems, but you can also manually configure Credential Manager to automatically provide credentials that are different from the domain credentials stored on the client. Depending on how often remote user credentials change, the credentials stored in Credential Manager can provide a user-friendly alternative to repeatedly having to type passwords for applications. For more information about using Credential Manager, see the "Stored User Names and Passwords" topic in Windows XP Help and the Fundamental Concepts paper in this series.

Enterprise Single Sign On

Microsoft business applications such as Microsoft BizTalk® Server 2004, Microsoft SharePoint® Portal Server 2003, and Host Integration Server 2004 offer powerful tools for the password management technique known as Enterprise Single Sign On (ESSO), a credential mapping technology that maps one set of credentials to another.

ESSO works with middle-tier applications that must access data from a server resource that uses the user's security context. However, the server resource, which is not integrated with Active Directory, uses a different identity store. Typically, the server resource is not owned by the highly trusted group of administrators who manage Active Directory. For this reason, it is not desirable to synchronize the user's Active Directory password.

The ESSO service accesses a database that contains a credential map for each user that allows access to server resources. Operationally, the BizTalk Server, Host Integration Server, or SharePoint middle-tier server authenticates the client by using Windows Integrated Authentication and then retrieves a credential from the ESSO database that is valid for the server resource. BizTalk Server 2004 provides interfaces that you can use to automatically manage credentials in both the ESSO database and those in the server systems to provide a totally automated password management solution.

ISV Solutions for Credential Management

Microsoft partners provide extensive client-side credential management capabilities that you can use to solve specific identity and access management issues that other mechanisms do not easily address. These products include:

  • SecurAccess, part of the ManageID suite from Proginet.
  • P-Synch from M-Tech.
  • v-GO SSO from Passlogix.
  • Simple Sign-On from Version 3.

For more information about these products and ISVs, see the Overview paper in this series.

Chapter 3: Issues and Requirements

This chapter provides background information, issues, and requirements for designing the Microsoft Identity and Access Management password management solution for Contoso Pharmaceuticals, the fictitious company used in this scenario. The security policy for Contoso has been updated to implement the following:

  • Strong password policy enforcement
  • Intranet password management
  • Extranet password management

For more information about the Contoso scenario, see the Platform and Infrastructure paper in this series.

Enforcing Password Policy

A security audit at Contoso revealed that Microsoft® Active Directory® directory service user accounts were not protected by a strong password policy and were not changed on a regular basis. As a result, several weak passwords were in use, including one that protected an administrative account. As discussed in Chapter 2, "Approaches to Password Management," requiring users to create strong passwords is a cornerstone of an effective password policy. This requirement must apply to all user accounts at Contoso.

Business Issues

Before Contoso can expose more of its information infrastructure to partners and other external parties, the company must ensure that its computer systems and data are well protected. Requiring users to employ strong passwords and change them frequently in Active Directory is a key step to improve the overall security of the network.

Technical Issues

The only technical issue for Contoso is that secure password enforcement should be controlled through the Microsoft Windows® desktop and managed centrally through Active Directory Group Policy.

Security Issues and Vulnerabilities

During the security audit, commonly available tools searched for passwords in Active Directory that were easy to guess. The results of the audit determined that five percent of all Active Directory user account passwords were blank, and that another 30 percent used very weak passwords such as password, secret, or the user account name. An anonymous user survey found that many users created passwords that an attacker could easily guess because they contained names of family members or pets.

Analysis of the password age attribute for the Active Directory accounts also indicated that passwords for many accounts had not changed since the system was deployed several years earlier. This means that an attacker carrying out a long-term password guessing or brute force attack, one that is perhaps months or years in length, is more likely to be successful at compromising the account.

Solution Requirements

Contoso translated these issues into the following requirements for the company's password policy:

  • The password policy should enforce regularly-scheduled password changes.
  • Users must create passwords according to the following rules:
    • Users are not allowed to reuse recent passwords.
    • Passwords may not contain all or any space-delimited part of the user's account name.
    • Passwords must be at least eight characters long.
    • Passwords must contain characters from three of the following four categories:
      • English uppercase characters (A through Z).
      • English lowercase characters (a through z).
      • Base 10 digits (0 through 9).
      • Non-alphabetic characters (for example, !, $, #, %).

Contoso can support these requirements through Active Directory Group Policy.

Intranet Password Management

A group of Contoso employees still needs to connect to different identity stores and directories. For example, some users must connect to Lotus Notes for e-mail. Unlike employees who use the company's Microsoft Exchange e-mail system, the Lotus Notes users must first log on to their Windows-based desktops and then authenticate a second time to their e-mail system, usually with a different password. Other users at Contoso must maintain a third set of credentials to access a custom application that uses Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server) as an identity store and authentication point.

The need for a second and sometimes third set of credentials to access the Lotus Notes e-mail system and Sun ONE Directory Server has led to many operational and security problems. These include the need to memorize multiple different passwords, and the likelihood that users will circumvent difficult password security controls on different systems. This can result in overall weaker security for the organization.

Business Issues

Many Contoso users have to use different passwords for the multiple systems that they access daily. Many of these users do not use the same passwords on all systems, so they must keep track of which password to use for which system. Contoso users have not shown the ability to retain this type of information without writing it down, which means that they often must call the IT help desk to reset their passwords on one or more systems. Synchronizing passwords can address this issue and increase efficiency by reducing the number of passwords that users must remember. In addition, the reduction of password reset requests significantly reduces help desk operating expenses.

Technical Issues

The solution to the described business and security issues must allow for strong password policy variations for the identity stores that Active Directory, Lotus Notes, and Sun ONE Directory Server 5.1 use. These variations are often confusing when users try to create new passwords.

Security Issues and Vulnerabilities

Contoso is subject to the "sticky note" security vulnerability. Many users post their passwords to different systems in plain view of other employees to remind themselves which password is for which system. Compounding this vulnerability is the fact that users have many passwords for the different systems. Enforcement of a common password policy across multiple systems at Contoso will reduce the number of passwords that users must remember, which will lessen their need to post sticky notes in the first place.

Solution Requirements

Contoso distilled the issues related to password change and synchronization into the following requirements for the company's password policy:

  • Password changes must be synchronized between Active Directory, Lotus Notes, and the Sun ONE Directory Server 5.1 directory service.
  • User-initiated password changes must take place through the Windows Security dialog box, invoked through the CTRL+ALT+DEL key combination. Following this protocol ensures that all users use a single standard password change procedure, because all users run Windows XP and have access to this dialog box.

Contoso can address these requirements through a combination of Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1), using suitable management agents, Active Directory on Microsoft Windows Server™ 2003, and Windows XP clients.

Extranet Password Management

Implementing an effective password change strategy for external partners and vendors helps reduce the cost of password management. It also helps increase the security of those passwords by applying the same password policy to all users, not just internal ones.

Business Issues

Contoso plans to implement a new password expiration policy for extranet user accounts. This expiration policy requires all users to change their passwords periodically in order to mitigate several types of password attacks.

Currently, extranet users such as customers and partners have no way to change their passwords in the extranet domain. Contoso must provide the tools needed so that extranet users can meet its security requirements as conveniently as possible.

Technical Issues

Contoso's plan to implement password change management on the intranet does not apply to the extranet. On the intranet, users will use the Windows Security dialog box to change their passwords. This kind of functionality is not available to users who log on to Contoso's extranet Web applications, so Contoso must provide a Web-friendly interface through which extranet users can change their passwords.

The password change system must also notify users when their passwords are about to expire so that users can change the passwords before their accounts are disabled. If users do not change their passwords within a certain period after their current ones expire, the old passwords will no longer provide authentication.

Security Issues and Vulnerabilities

Anytime that passwords are sent across a network, especially a public network like the internet, security is a primary concern. The password change operation must be as secure as possible.

Solution Requirements

Contoso translated these password change issues into the following requirements for the company's password policy:

  • Passwords for vendor and partner accounts must follow the corporate password policy. This applies regardless of whether the partners have access to the intranet.
  • Password changes from the extranet must take place through a secure Web application.
  • Passwords must be transmitted in a secure manner.

After Contoso determined its password policy requirements, the company's system architects started designing a suitable infrastructure for the solution. Chapter 4, "Designing the Solution," describes this design process.

Chapter 4: Designing the Solution

This chapter focuses on designing a strong password management solution for Contoso based on the requirements determined in the previous chapter. The design will be a customized version of the Microsoft Identity and Access Management Password Management Solution that meets the requirements of the existing systems in the company's environment.

Enforcing Password Policy

Contoso identified the following as important goals for the company's password policy:

  • Requiring acceptable password strength (both password length and complexity)
  • Requiring password complexity
  • Forcing regular password changes
  • Preventing immediate password reuse

Solution Concept

The solution concept is to configure the Group Policy settings in the Active Directory® directory service to enforce the use of strong, complex passwords and to prompt users to change their passwords frequently.

Solution Prerequisites

A prerequisite for this solution is that the identity stores in the organization's environment will support the same level of password policies. For example, they must all be able to accept complex passwords that use special characters. If your security policy encourages the use of pass phrases, all connected identity stores must support sufficiently long passwords (usually at least 30 characters).

Solution Architecture

The central component of the solution architecture is Active Directory, which provides security options within Group Policy that require users to create strong passwords and change them on a regular basis. Active Directory then replicates the new Group Policy settings to all domain controllers throughout the domain.

Typically, password policy creation involves configuring several settings in the Default Domain Policy in Active Directory. The following table shows these settings along with the values that Contoso has chosen to deploy.

Table 4.1. Password Policy Values

Setting

Value

Maximum password age

60

Minimum password age

1

Minimum password length

8

Enforce password history

24

Passwords must meet complexity requirements

Enabled

After these policies are configured, they are enforced for all users in the domain.

Note Individual user settings may override password expiration requirements. In Active Directory, you can enable the Password never expires option for an account that takes precedence over values set through Group Policy. This option is for service accounts, which typically use considerably stronger passwords than normal user accounts.

Maximum Password Age

This setting in Active Directory determines the amount of time (in days) that a password can be used before the system requires the user to change it. The default value of 42 days is generally appropriate; some IT departments shorten the value to 30 days to require a shorter interval. However, the usability of such short duration passwords is often a concern.

Enforce Password History

This Active Directory setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused. It also rejects new passwords that are too similar to old passwords. This setting feature prevents users from circumventing password expiration restrictions by recycling old passwords or ones like them. The default value for this setting is to remember 24 passwords. Most IT departments choose a value greater than six, and many use the default setting of 24.

Minimum Password Age

This setting in Active Directory determines the number of days that must pass before users can change their passwords. Defining a minimum password age prevents users from circumventing the password history policy by defining multiple passwords in rapid succession until they can use their old passwords again. The default value for this setting is one day, which discourages rapid password recycling but permits users to eventually change their passwords. Most IT departments use this default value.

Minimum Password Length

This Active Directory setting determines the minimum number of characters that a user's password must contain. You may want to increase this setting from the default value of seven. A minimum password length of seven characters is no longer considered secure; the best defense against direct attacks on passwords is to have very long passwords. See Chapter 2, "Approaches to Password Management," for more information about this subject. Most IT departments specify longer passwords than the default value of seven characters.

Passwords Must Meet Complexity Requirements

This setting enables Active Directory to verify that new passwords meet complexity requirements. The strong password policy included with Microsoft Windows Server™ 2003 requires that all passwords:

  • Not include any space-delimited portion of the user account name.
  • Contain at least six characters (may be overridden by Minimum Password Length).
  • Contain characters from three of the following four categories:
    • Uppercase English alphabet characters (A through Z).
    • Lowercase English alphabet characters (a through z).
    • Arabic numerals (0 through 9).
    • Special characters, such as !$#,%).

This setting is enabled by default in Windows Server 2003. Most IT departments leave it on or create a custom filter that requires even more stringent complexity rules.

How the Solution Works

The administrator uses the Group Policy Microsoft Management Console (MMC) snap-in to change the required settings in the Default Domain Policy for each domain. After the Group Policy updates all domain controllers (usually within five minutes for domain controllers within the same site), any subsequent password changes must meet the policy requirements. Password changes that do not meet the requirements are rejected; a message displays that informs the user that the new password does not meet organizational requirements for length, complexity, or uniqueness. The following figure shows how the solution works.

Figure 4.1. The password policy solution using Active Directory Group Policy

This solution works in conjunction with the password change and synchronization scenario, which the next section of this chapter discusses.

Intranet Password Management

To meet the password change and synchronization requirement for Contoso at a conceptual level, the company evaluated the following two possible solutions:

  • Using the Microsoft Windows® Change Password dialog box. After users initiate a password change by using this dialog box, information is pushed from Active Directory to the metadirectory service and out to the organization's other identity stores.
  • Using the Web-based, self-service, password-change application that ships with Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1) to allow users to change their passwords in the Contoso identity stores. MIIS 2003 with SP1 then processes this password information and pushes it out to all of the connected identity stores.

Although both solutions still require that users with access to Lotus Notes and Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server) log on separately to these systems, users will be able to use the same passwords in each system. This approach improves the user experience significantly and reduces the security risk of users managing multiple passwords.

The Web interface approach is generally simpler to deploy. However, it is important to consider security and user experience issues before deciding to use this method. When a user password is about to expire, a notification displays automatically through the Windows user interface (UI). However, the UI prompts the user to change their password through the mechanism built into the Windows operating system rather than through the Web interface. Contoso management realizes that implementing a new Web interface to handle password changes requires the company to train employees how to use it. Users would have to be trained not to use the standard Change Password mechanism to change their passwords. Because of this training requirement, Contoso decided to use the Windows Change Password feature from client workstations.

Solution Concept

The solution concept uses a password notification and filtering dynamic-link library (DLL) on all domain controllers to intercept the password change request. A Windows service (the Password Change Notification Service or PCNS) then uses Windows Management Instrumentation (WMI) to redirect the change to the configured management agents in MIIS 2003 with SP1. MIIS then updates the designated identity stores with the new password information. After the password change has been successfully processed, the intermediate data is deleted from the MIIS Server.

Solution Prerequisites

Like the enforcing password policy scenario, a prerequisite for this solution is that the identity stores in the target organization's environment must all be capable of supporting the same level of password length and complexity. For the stores specified in this solution, these password requirements are supported.

The solution also requires a metadirectory product with management agents that support password push and that can connect to all of the relevant identity stores within the organization. MIIS 2003 with SP1 was selected for this purpose.

Finally, the solution requires Windows XP or Windows 2000 clients and Active Directory domain controllers running on Windows 2000 Server or Windows Server 2003.

Solution Architecture

The architecture of the Intranet Password Management solution is identical to the architecture of the PCNS feature of MIIS 2003 with SP1.

How the Solution Works

The following diagram shows the solution architecture for changing and synchronizing users' passwords, as well as the components involved and the order in which password management takes place:

Figure 4.2. The solution concept for password change and synchronization

The process that the solution observes is as follows:

  1. The user initiates the password change request by pressing CTRL+ALT+DEL. The password change request, including the new password, is sent to the nearest domain controller.
  2. The domain controller records the password change request and notifies the local password change notification filter (Pcnsflt.dll). This filter is installed on each domain controller.
  3. The password change notification filter passes the request to the Password Change Notification Service (PCNS).
  4. The PCNS verifies the password change request, authenticates the service principal name (SPN) by using Kerberos, and then forwards the password change request in encrypted remote procedure call (RPC) to the MIIS 2003 with SP1 target server.
  5. MIIS 2003 with SP1 validates the source domain controller, uses the domain name to locate the management agent that services that domain, and then uses the user account information in the password change request to locate the corresponding object in the connector space.
  6. By using the join table information, MIIS 2003 with SP1 determines the management agents that receive the password change and pushes the password change out to them.

For more details about how PCNS works and PCNS data flow is provided, see "MIIS 2003 Walkthrough: Password Synchronization" (MIIS_2003_Password_Synchronization_Step_by_Step.doc). The document is part of the Microsoft Identity Integration Server 2003 Scenarios package. The package provides detailed step-by-step instructions on how to prepare for, implement, and verify this solution.

Extranet Password Management

To meet the extranet password management requirements at a conceptual level, Contoso evaluated two possible solutions:

  • Have the extranet users contact the Contoso Help desk for password management tasks such as changing and resetting passwords. The Help desk would then use the Active Directory Users and Computers MMC snap-in from Windows Server 2003 to perform password management on the extranet domain.
  • Deploy customized Web-based password management applications that ship with MIIS 2003 with SP1 and this solution to change user passwords. The extranet users would use these Web pages to manage their passwords themselves.

Both of these solutions allow extranet users to perform password management tasks that are required to comply with Contoso's overall password policy. The Web-based self-service password management utility must be configured before it is deployed, and it must be deployed properly to help prevent attacks. The Help desk scenario does not require an additional software-based investment, but is expensive over time due to higher Help desk costs. Furthermore, the scenario does not scale to meet the increasing number of extranet users. In addition, the Help desk solution does not notify users before their passwords expire.

After reviewing various password management products, Contoso decided to use the self-service Web-based password management solution because it meets all of the requirements defined during the design process. Specifically, this solution provides extranet users with the ability to manage their own passwords through a customizable Web interface while still maintaining security during the password change process. This solution also notifies extranet users when their passwords are about to expire so that they can change them in time.

Solution Concept

Contoso will implement the password policy described previously in this document. This solution works for all user accounts in the domain. However, many of the components of the solution require the user to be connected to the intranet to work properly. For example, users that are on the intranet are notified during logon when their passwords are about to expire, and they are given the option to change their passwords at that time. These users can also press CTL+ALT+DEL at any time to change their passwords.

Extranet users do not have this convenience. The CTL+ALT+DEL password change will not change their passwords, because they are not connected to the intranet and cannot establish a direct connection to a domain controller. In addition, extranet users are not notified by a domain controller when their passwords are about to expire. So while this does not circumvent the account policies that are in place, extranet users run a significant risk of having their accounts disabled due to password expiration without any way to change those passwords.

There are two significant components to this solution: password management and password expiration notification. Although these components are separate and technologically unrelated, they each provide part of the overall Contoso extranet solution.

Note For additional information about the MIIS 2003 with SP1 Password Management feature that provides Help desk password reset and user password change capabilities, refer to the MMS_2003_Password_Management.doc in the Password Management folder on the MIIS 2003 with SP1 installation CD.

Solution Prerequisites

Implementing this solution requires a Web server that extranet users can access. This Web server will make a connection back to an extranet domain controller, so it must have access to both the Internet and the extranet domain.

The solution also requires Active Directory running on Windows 2000 Server or Windows Server 2003, along with the different identity stores to which MIIS 2003 with SP1 will connect by using the management agents. In addition, a Microsoft Exchange server is required to implement e-mail-based password expiration notification.

Solution Architecture

The following diagram shows the solution architecture for extranet password expiration notification and user-initiated password changes. The components involved and the order in which the process takes place are also shown.

Figure 4.3. Extranet password management

The process that this solution observes is as follows:

  1. The Identity Management Notification Service (IMNS) periodically queries the extranet domain for a list of user accounts whose passwords will expire soon.
  2. When a user's password is set to expire soon, IMNS obtains the user's e-mail name from Active Directory. IMNS then creates a message to notify the user of the imminent password expiration. This message and the appropriate e-mail address are sent to an Exchange server.
  3. The Exchange server sends the password expiration e-mail message to the user. The e-mail message usually contains a link to a Web-based password change application.
  4. When users receive the e-mail, they click the link to open the Web page for password change. Users can then supply their old and new passwords. This connection is protected with secure sockets layer (SSL) encryption through the Web browser.
  5. The Web server opens an encrypted channel to an extranet Active Directory domain controller and sends the password change information.
  6. The domain controller processes the password change request the same way as any other password change request and returns a success or failure message to the Web server. The message is displayed for the user as a confirmation that the password has been changed.

Steps 1–3 are the password expiration notification portion of this solution. Steps 4–6 comprise the extranet password change component.

Note This is not a completely secure solution because it does not use digitally signed or encrypted e-mail by default. If e-mail authenticity is a security requirement for your organization, consider modifying the solution to sign or encrypt e-mail.

Now that Contoso has determined its password policy solution design, it is prepared to implement the solution. Chapter 5, "Implementing the Solution," describes this process.

Chapter 5: Implementing the Solution

The previous chapters in this paper provide information about the typical issues, requirements, and design of solutions that address the Strong Password Management, Intranet Password Management, and Extranet Password Management solution scenarios. This chapter provides guidance about how to implement these solutions and introduces the tools and templates provided for these scenarios.

You can verify the prerequisites and implementation guidance in this chapter by following the guidance in Chapter 6, "Testing the Solution."

Tools and Templates

The Identity and Access Management download package includes Identity and Access Management Tools and Templates.msi, which is the Tools and Templates installer file. The Tools and Templates that are part of this download include text-based scripts, code samples, and configuration files that are related to identity and access management, but do not include any executable programs or compiled code.

Note These samples are provided as examples only. Be sure to review, customize, and test these tools and templates before you use them in a production environment.

When you run the installer file, the resulting folder structure will look similar to the one displayed in the following figure, depending on where you install it.

Figure 5.1. The Tools and Templates folder structure

This guide assumes you have installed the Tools and Templates into the default location of %UserProfile%\My Documents\Identity and Access Management Tools and Templates. If you use a different installation location, ensure that you use this path in all the steps in this document.

Note The Tools and Templates MSI package can sometimes produce an error during the installation process. See the Identity and Access Management Series Readme.htm file for more information.

Folder: PwdManagement

Table 5.1. Files in the PwdManagement Folder

File name

Purpose

ExtranetPwdChange.sln

The Microsoft® Visual Studio® .NET 2003 solution file that contains the settings and environment for the PwdManagement project.

Folder: PwdManagement\ExtranetPwdChange

Table 5.2. Files in the PwdManagement\ExtranetPwdChange Folder

File name

Purpose

AssemblyInfo.cs

An information file that contains metadata about the assemblies in a project, such as name and version.

ExtranetPwdChange.csproj

The project file containing the configuration and build settings that keeps a list of files associated with the project.

PwdChange.aspx.cs

The Microsoft Visual C#® file that implements a Web page where users can change their password.

Web.config

The configuration file that contains configuration settings for the application.

Folder: PwdManagement\ExtranetPwdLib

Table 5.3. Files in the PwdManagement\ExtranetPwdLib Folder

File name

Purpose

AssemblyInfo.cs

An information file that contains metadata about the assemblies in a project, such as name and version.

IisInstallerUtil.cs

The Helper class that wraps common Internet Information Services (IIS) metabase configuration tasks.

LocalizationUtils.cs

The Visual C# file that implements localization utility functions for the application.

LocalizedPage.cs

The Visual C# file that implements localization utility functions for the application Web page.

LocalizedUserControl.cs

The Visual C# file that implements localization utility functions for the application user controls.

This chapter assumes that you have the following software installed according to the Contoso scenario as described in the Platform and Infrastructure paper in this series:

  • Microsoft Windows Server™ 2003, Enterprise Edition
  • Microsoft SQL Server™ 2000, Service Pack 3 (SP3) or later
  • Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1) or later
  • Microsoft Visual Studio .NET 2003 (for debugging and customization of code samples)

For more information about these prerequisites, see the Platform and Infrastructure paper in this Series.

Enforcing Strong Passwords

You can use the tasks in this section to configure the Default Domain Policy in Microsoft Windows® 2000 and to implement changes for the following Group Policy settings in Active Directory® directory service:

  • Enforce password history
  • Set maximum password age
  • Set minimum password age
  • Set minimum password length
  • Enforce complex passwords

Configuring the Default Domain Policy in Windows Server 2003 and Windows 2000 Server

Active Directory in Windows Server 2003 implements several of the recommendations in this paper by default. However, if you run Windows 2000 Server in your environment, or if you need to configure the settings to meet company requirements, you can change them by using the following procedure. It is also a good practice to explicitly define these settings, even if they are the default settings, to ensure that they are configured and that there is no perceived lack of configuration.

To perform this procedure, you must be a member of the Domain Admins or Enterprise Admins group in Active Directory or have equivalent access rights. You must also either be logged on to a domain controller for the domain or a workstation on which the Windows Server 2003 Administration Tools Pack is installed. For more information, download the Windows Server 2003 Administration Tools Pack.

To configure the Default Domain Policy

  1. Log on to Windows Server 2003 as a Domain Admin.
  2. Click Start, point to All Programs, point to Administrative Tools, and then click Domain Security Policy to open the Default Domain Security Settings Microsoft Management Console (MMC).
  3. In the left pane, expand Security Settings, expand Account Policies, and then click Password Policy to display the Group Policy Object Editor as shown in the following figure.

Figure 5.2. Password policy options

Configuring Group Policy Settings

To prevent users from recycling passwords

  1. In the right pane of the Group Policy Object Editor, double-click Enforce password history to open the Enforce password history Properties dialog box.
  2. Select the Define this policy setting check box, and in the Keep password history for box, adjust the value to 24 as shown in the following figure. Then click OK.

Figure 5.3. Configuring the Enforce password history option in the Group Policy Object Editor

To make passwords expire at a set interval

  1. In the right pane of the Group Policy Object Editor, double-click Maximum password age to open the Maximum password age dialog box.
  2. Select the option to Define this policy setting, and in the Password will expire in box, adjust the value to 60. Then click OK.

To ensure that users cannot change passwords again immediately

  1. In the right pane of the Group Policy Object Editor, double-click Minimum password age to open the Minimum password age dialog box.
  2. Select the option to Define this policy setting, and in the Password can be changed after box, adjust the value to 1. Then click OK.

To ensure that users use minimum-length passwords

  1. In the right pane of the Group Policy Object Editor, double-click Minimum password length to open the Minimum password length dialog box.
  2. Select the option to Define this policy setting, and in the Password must be at least box, adjust the value to 8. Then click OK.

Note The Minimum password length setting takes precedence over the six-character minimum length enforced by the Password must meet complexity requirements setting.

To that ensure users create complex passwords

  1. In the right pane of the Group Policy Object Editor, double-click Password must meet complexity requirements to open the Password must meet complexity requirements dialog box.
  2. Select the option to Define this policy setting, select the Enabled option, and then click OK.
  3. Close the Default Domain Security Settings MMC.

Performing these configuration tasks establishes the defined password policy in Active Directory. After a short delay, the settings are distributed to all domain controllers and are then enforced.

Intranet Password Management

For these implementation details to work correctly, you need to have a basic Contoso infrastructure implemented as introduced in the Platform and Infrastructure paper in this series, specifically Chapter 4, "Designing the Infrastructure," and Chapter 5, "Implementing the Infrastructure." You also need to have connected your various identity stores in the way that the Identity Aggregation and Synchronization paper describes. Components of the infrastructure include:

  • An intranet Active Directory forest. It should contain the provided Contoso organizational units, groups, and users.
  • An extranet Active Directory forest. It should contain the provided Contoso organizational units, groups, and users.
  • A three-tier public key infrastructure (PKI).
  • A centralized, consistent identity store.

For more information, see the following Identity and Access Management Series papers:

  • Platform and Infrastructure.
  • Identity Aggregation and Synchronization.

Implementation Overview

Implementing this solution scenario involves the following activities:

  • Installing the Password Change Notification Service (PCNS)
  • Configuring MIIS 2003 with SP1 to work with PCNS

Implementation Details

To implement the intranet Password Management portion of this solution, see "MIIS 2003 Walkthrough: Password Synchronization" (MIIS_2003_Password_Synchronization_Step_by_Step.doc). The document is part of the Microsoft Identity Integration Server 2003 Scenarios. The package provides detailed step-by-step instructions on how to prepare for, implement, and verify this solution.

Note In the MIIS 2003 Walkthrough: Password Synchronization paper, it is assumed that you have configured MIIS 2003 to use a domain-based service account to ensure connectivity between the MIIS 2003 server and the computer running PCNS. If this account is currently setup as a local account, reconfigure MIIS 2003 to use a domain-based account by using the steps provided in the MIIS 2003 documentation.

Extranet Password Management

This solution requires the installation and configuration of both the Identity Management (IdM) Notification Service and the Extranet Web Application.

Implementing extranet password management involves the following tasks:

  • Preparing the environment
  • Installing the Extranet Password Management and IdM Notification Service applications
  • Configuring Internet Information Services (IIS)
  • Verifying the installation

The Contoso identity and access management solution requires the scripts and software that the following sections reference. It is essential to install the software in the prescribed order for this scenario to work properly.

Preparing the Environment

Before you install this application, ensure that you have Windows Server 2003 installed with IIS and the Microsoft .NET Framework version 1.1, and that you have Active Server Pages (ASP) enabled. For information about how to enable ASPs in IIS, refer to the Windows Server 2003 Help and Support Center.

You must also install and build the Data Access Application Block for .NET v2.

To manage the passwords centrally stored in Active Directory, you also must join the computer to the extranet Active Directory domain.

Installing the Applications

The following subsections describe the contents of various folders within the Password Management folder of the Tools and Templates directory that downloads with this paper.

Folder: IdMNotificationSvc

This folder contains the sample code for the Notification Service that Contoso uses. The Notification Service is a sample Windows Service written in Microsoft Visual C# that you must compile and install to make the other scenario solutions in this paper fully functional.

Table 5.4. Password Notification Service Files

File name

Purpose

AssemblyInfo.cs

An information file that contains metadata about the assemblies in a project, such as name, version, and culture information.

AcccountExpirations.cs

The C# file that implements notifications for account expirations.

AcccountProvisioning.cs

The C# file that implements notifications for the provisioning solutions in this paper.

ContactorWorkflow.cs

The C# file that implements notifications for the self-service provisioning Web application in this paper.

IdMNotificationSvc.cs

The C# file that implements the service main function.

miisGroupManagement.cs

The C# file that implements notifications for the group management scenario in this paper.

PasswordExpirations.cs

The C# file that implements notifications for extranet password expirations.

SMTPMailer.cs

The C# file that implements the Simple Mail Transfer Protocol (SMTP) messaging used for all notifications.

IdmNotificationSvc.cs

The project file that contains the configuration and build settings and keeps a list of files associated with the project.

Task 1: Editing the IdMNotificationSvc.config Configuration File

To edit this configuration file

  1. Open the IdMNotificationSvc.exe.config file by using Visual Studio .NET.
  2. Edit this file to change its default settings to the Lightweight Directory Access Protocol (LDAP) settings of your domain.
  3. Save and close this file.

Task 2: Compiling and Configuring the Group Management Applications

To compile the Notification Service program

  1. Log on to the computer running MIIS 2003 with SP1 and Visual Studio.NET.
  2. In Windows Explorer, navigate to the installation folder and double-click the IdmNotificationSvc.sln file to open the solution in Visual Studio.
  3. On the Build menu, select Rebuild Solution.

Important For this section to work, you must install and build the Data Access Application Block for .NET v2.

Task 3: Installing the Notification Service

To install this service

  1. At a command prompt, use InstallUtil.exe to install IdMNotificationSvc.exe:

    C:\Windows\Microsoft.NET\Framework\v1.1.4322>InstallUtil "%UserProfile%\My Documents\Identity and Access Management Tools and Templates\Password Management\IdMNotificationSvc\bin\debug\IdMNotificationSvc.exe"

  2. To start the service, type the following at the command prompt:

    NET START IdMNotificationSvc

You should see the message "The IdM Notification Service started successfully."

Folder: Extranet Web Application

This folder contains the Web application components that will enable you to provision and deprovision your extranet users. Perform the following tasks locally on the computer running MIIS 2003 with SP1. In this example, this computer is the extranet Web server.

Task 1: Copying the Web Application Files to the Computer Running MIIS 2003 with SP1

  • Copy all files from the %UserProfile%\My Documents\Identity and Access Management Tools and Templates\Password Management\ExtranetPwdChange\PwdManagement folder to a new folder on the computer running MIIS 2003 with SP1, C:\Inetpub\wwwroot\PwdManagement.

Task 2: Installing the Web Application

To install the Web application

  1. Browse to the subfolder C:\Inetpub\wwwroot\PwdManagement\ to view the \ExtranetPwdChange\ subfolder.
  2. Right-click the \ExtranetPwdChange\ subfolder, and then click Properties.
  3. In Properties, click the Web Sharing tab, and then select the Share this folder option.
  4. Accept the default settings in the Edit Alias dialog box, and click OK.
  5. Click OK to close the Properties dialog box.

Important Do not change the default name that is selected for you.

Configuring IIS

Perform the following tasks to configure IIS to provide the newly installed password management Web application.

Important Before you perform these tasks, you must have installed a Web server certificate that IIS will use to enforce secure sockets layer (SSL) security. If you do not have a certificate installed on the server that is trusted by your clients, these tasks will fail. For more information about obtaining and installing a Web server certificate, see the "Certificates" section in the Windows Server 2003 documentation.

Task 1: Configuring IIS

To configure IIS

  1. Open IIS Manager, then under Web Sites\Default Web Sites, right-click ExtranetPwdChange, click Properties, and then click the Directory Security tab.
  2. Under Secure communications, select the Edit and Require secure channel (SSL) check boxes, and then click OK.

Task 2: Changing the Solution to Use the LDAP Settings of Your Domain

To use the LDAP settings of your domain

  1. Using Visual Studio.NET, open the C:\Inetpub\wwwroot\PwdManagement\ExtranetPwdChange\ExtranetPwdChange.sln file.
  2. Edit the web.config file to change the LDAP settings to those of your domain.
  3. Click Build, and then click Rebuild Solution to build the solution with your new settings.

Task 3: Verifying That the Application Is Hosted

  • In Internet Explorer, go to https://localhost/ExtranetPwdChange/PwdChange.aspx.

On this Web page, you should be able to see the application load.

Note If you receive a 404 Page Not Found error, restart IIS.

Verifying the Installation

Task 1: Verifying That IdmNotificationSvc Is Running

  • Using CTRL+ALT+DEL, open Task Manager, select the Processes tab, and then confirm that IdmNotificationSvc is running.

Task 2: Verifying That the Extranet Password Change Application Will Run

  • Go to https://localhost/ExtranetPwdChange/PwdChange.aspx and confirm that the Web application opens.

Note If you receive a 404 Page Not Found error, restart IIS by opening a command prompt, typing IISReset, and pressing Enter.

Chapter 6: Testing the Solution

This chapter describes how to validate the implemented solution scenarios from the previous chapter. It also provides some troubleshooting steps to help with common implementation challenges. The chapter does not provide comprehensive guidance for testing the end-to-end user and administrator experience.

Enforcing Strong Passwords

After the strong password implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.

Validating the Implementation Prerequisites

Before you test the implementation guidance, you should perform the following basic prerequisite test to ensure that the solution infrastructure is correctly configured:

  • Basic Test 1: Verifying the functionality of the intranet domain controller
Basic Test 1: Verifying the Functionality of the Intranet Domain Controller

Complete the following procedures to verify that the intranet domain controller is working properly and not generating any errors.

To verify that the intranet domain controller is working properly

  1. Log on to the intranet domain controller with administrative privileges.
  2. If you have not already installed the Windows Server 2003 Support Tools, install them from the \SUPPORT\TOOLS directory of the Windows Server 2003 CD.
  3. At a command prompt, type dcdiag.exe and then press ENTER.

The dcdiag utility executes a series of tests. All tests should pass.

To check the domain controller's event log for errors

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, type eventvwr.msc and then press ENTER to open the Event Viewer Manager console.
  3. Browse to the Directory Service node, and then click it to display the event logs in the right pane of the console.

The event log should not contain any errors. If any errors are logged, investigate them to ensure they do not impact the functionality of the domain.

Validating the Implementation

In this scenario, the following test areas are important for validating key requirements and functionality:

  • Validating replication of new settings
  • Validating enforcement of new settings
Validating New Setting Replication

Complete the following test to verify that the new settings that you created have been applied correctly:

  • Settings Test 1: Verifying that the settings are replicated

Settings Test 1: Verifying That the Settings Are Replicated

Complete the following steps to verify that the new settings are replicated to each domain controller.

To verify setting replication

  1. Log on to an intranet domain controller with administrative privileges.
  2. This domain controller should not be the one that you used to apply the settings in Chapter 5, "Implementing the Solution."
  3. Click Start, click Run, type gpedit.msc and then press ENTER to bring up the Local Computer Policy GPO.
  4. Browse to the \Computer Configuration \ Windows Settings \ Security Settings \ Account Policies \ Password Policy node.
  5. Compare the effective settings that display against the settings you applied in Chapter 4, "Designing the Solution," listed in Table 4.1.

The settings that display should be identical with those listed in Table 4.1.

The presence of the settings on this domain controller confirms that the settings are being successfully replicated through Active Directory.

Note To be absolutely certain that these settings are being replicated properly, perform this procedure on each domain controller in your environment. There are automated tools available that will help you accomplish this task in large environments.

Validating New Setting Enforcement

Complete the following tests to verify that the new settings are being enforced correctly:

  • Enforcement Test Prerequisite: Create a test user account
  • Enforcement Test 1: Maximum password age
  • Enforcement Test 2: Minimum password age
  • Enforcement Test 3: Minimum password length
  • Enforcement Test 4: Enforce password history
  • Enforcement Test 5: Password must meet complexity requirements

Enforcement Test Prerequisite: Create a Test User Account

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to an intranet domain controller with administrative privileges.
  2. Launch the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.
  3. Right-click Users, click New, and then click User.
  4. Create a user named Mike Danseglio with the user name mikedan and an easily remembered password.

For this example, the domain name is NA.

Enforcement Test 1: Maximum Password Age

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to an intranet domain controller with administrative privileges.
  2. Click Start, point to All Programs, click Administrative Tools, and then click Domain Security Policy to open the domain security policy.
  3. Browse to the \Security Settings \ Local Policies \ Security Options node.
  4. Open the Begin prompting this many days before password expires option and change the value to 60 days.
  5. Restart a client computer to obtain the new security policy.
  6. Log on to a client computer as NA\mikedan.

You should be prompted to change your password immediately and informed that your password expires in 60 days.

  1. Repeat steps 1-4 and change the Begin prompting this many days before password expires option back to its original value.

Enforcement Test 2: Minimum Password Age

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to a client computer as NA\mikedan.
  2. To change the password, press CTRL+ALT+DEL and then click Change Password.

Change the password to another easily remembered password, or write it down.

  1. Press CTRL+ALT+DEL and then click Change Password again, supplying yet another password.

This password change should fail because the minimum password age has not yet been reached for mikedan.

Enforcement Test 3: Minimum Password Length

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to a client computer as NA\mikedan.
  2. To change the password, press CTRL+ALT+DEL and then click Change Password.
  3. In the New password and Confirm new password boxes, type Hello! and then click OK.

This password change should fail because even though the password meets complexity requirements, the minimum password length is 8 characters, and this password is only 6 characters.

Enforcement Test 4: Enforce Password History

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to a client computer as NA\mikedan.
  2. To change the password, press CTRL+ALT+DEL and then click Change Password.

Change the password to an easily remembered password, or write it down.

  1. Press CTRL+ALT+DEL and then click Change Password again, supplying your original password.

This password change should fail because the previous password is stored in the password history for the mikedan user, and repeat passwords are not allowed.

Enforcement Test 5: Password Must Meet Complexity Requirements

Complete the following steps to verify that this new setting is enforced.

To verify that the setting is enforced

  1. Log on to a client computer as NA\mikedan.
  2. To change the password, press CTRL+ALT+DEL and then click Change Password.
  3. In the New password and Confirm new password boxes, type hellofriend and then click OK.

This password change should fail; even though the password is long enough to meet the minimum required length, it is not complex.

  1. Press CTRL+ALT+DEL and then click Change Password again.
  2. In the New password and Confirm new password boxes, type Hello, friend! and then click OK.

This password change should succeed because it is both long and complex enough to meet the system's password policy.

Intranet Password Management

After the intranet scenario implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.

To validate the implementation of the intranet Password Management portion of this solution, see "MIIS 2003 Walkthrough: Password Synchronization" (MIIS_2003_Password_Synchronization_Step_by_Step.doc).

The document is part of the Microsoft Identity Integration Server 2003 Scenarios package. The package provides detailed step-by-step instructions on how to prepare for, implement, and verify this solution. The validation tasks provided in this chapter are supplemental to those tasks. For more information about this document and the implementation tasks, see Chapter 5, "Implementing the Solution."

Validating the Implementation Prerequisites

Before you test the implementation guidance, you should perform a few basic prerequisite tests to ensure that the solution infrastructure is correctly configured:

  • Basic Test 1: Verifying the functionality of the intranet domain controller
  • Basic Test 2: Verifying the functionality of non–Microsoft application servers
  • Basic Test 3: Verifying Microsoft® Exchange server configuration
  • Basic Test 4: Verifying domain name lookups from MIIS 2003 with SP1 Server
  • Basic Test 5: Verifying network connectivity
Basic Test 1: Verifying the Functionality of the Domain Controller

Complete the following procedures to verify that the intranet domain controller works properly and does not generate errors.

To verify that the intranet domain controller is working properly

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, type dcdiag.exe and then press ENTER.

The dcdiag utility executes a series of tests. All tests should pass.

To check the domain controller's event log for errors

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, type eventvwr.msc and then press ENTER to open the Event Viewer Manager console.
  3. Browse to the Directory Service node and click it to display the event logs in the right pane of the console.

There should be no errors in the event log.

Basic Test 2: Verifying the Functionality of Non–Microsoft Application Servers

Complete the following steps to ensure that the Lotus Notes and Sun ONE Directory Server 5.1 (formerly iPlanet Directory Server) servers work properly.

To verify that the Lotus Notes server is working properly

  1. Use the Lotus Domino Administrator client to log on to the Lotus Notes server.
  2. From the Administration menu, select Server and then select Status.

The user interface (UI) should display the server status as Listening for TCP/IP connections.

To verify that the Sun ONE Directory server is working properly

  1. Use Planet Console 5.1 with administrative privileges to log on to the Sun ONE Directory Server.
  2. In the Server and Applications tree, navigate to "Directory Server" (<server name>).

The UI should display server status as Started.

Basic Test 3: Verifying Microsoft Exchange Server Configuration

Complete the following steps to ensure that Simple Mail Transfer Protocol (SMTP) addresses end in @contoso.com.

To verify that the Exchange server is working properly

  1. Log on to the Exchange server with Exchange administrator privileges.
  2. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.
  3. Double-click Contoso, double-click Recipients, and then double-click Recipient Policies.
  4. Right-click Default Policy, and then click Properties.
  5. On the E-mail Addresses (Policy) tab, ensure that the SMTP type has an address value of @contoso.com.

The Exchange server must have an SMTP type with an address value of @contoso.com.

Basic Test 4: Verifying Domain Name Lookups from the MIIS 2003 with SP1 Server

Complete the following steps to confirm that domain name lookups to both the intranet and extranet domains work properly from the Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1) server.

To verify domain name lookups

  1. Log on to the MIIS 2003 with SP1 server.
  2. At a command prompt, type nslookup na.corp.contoso.com and then press ENTER. The result should be similar to the following:

    Name: na.corp.contoso.com

    Address: 192.168.0.202

  3. Repeat for perimeter.contoso.com.

NSLOOKUP must succeed when you use the fully qualified domain names (FQDN) of the intranet and extranet domains.

Basic Test 5: Verifying Network Connectivity

Complete the following steps to verify network connectivity to the intranet and extranet domain controllers, the Sun ONE Directory Server, and the Lotus Domino server.

To verify network connectivity

  1. Log on to the MIIS 2003 with SP1 server.
  2. At a command prompt, type ping <Intranet Domain Controller host name> and then press ENTER.

The MIIS 2003 with SP1 server should receive a response from the intranet domain controller.

  1. Attempt to contact the Lotus Domino server and Sun ONE Directory Server servers by using the same ping command as in step 2. You should receive responses from each of these servers.
  2. Open a command prompt, type telnet <Extranet Domain Controller host name> 53 and then press ENTER.

A Telnet connection should be made to the extranet domain controller.

All network connectivity tests should pass without failure.

Validating the Implementation

In this scenario, the following test areas are important for validating key requirements and functionality:

  • Validating the Password Change Notification Service (PCNS) configuration
  • Validating password propagation
Validating the PCNS Configuration

Complete the following tests to verify the proper configuration of the PCNS:

  • PCNS Test 1: Verifying that PCNS runs
  • PCNS Test 2: Verifying the Service Principal Name (SPN) setting for MIIS 2003 with SP1
  • PCNS Test 3: Verifying the configuration of MIIS 2003 with SP1 as a target with PCNS
  • PCNS Test 4: Verifying the MIIS 2003 with SP1 password source configuration
  • PCNS Test 5: Verifying the password synchronization configuration in MIIS 2003 with SP1

PCNS Test 1: Verifying That PCNS Is Started

Complete the following steps to verify that the PCNS runs.

To verify that PCNS runs

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, type eventvwr.msc and then press ENTER to open the Event Viewer Manager console.
  3. Browse to the Application node and click it to display the event logs in the right pane of the console.
  4. Verify that the following events are present from the source PCNSSVC:

    Event ID: 2105

    Description: The Password Change Notification Service is starting.

    Event ID: 2101

    Description: The Password Change Notification Service is starting.

    Event ID: 2102

    Description: Target <target name> is enabled. Password changes will be queued for this target.

The presence of these two events confirms that the PCNS has started successfully.

PCNS Test 2: Verifying the SPN Setting for MIIS 2003 with SP1

Complete the following steps to ensure the proper setting of the SPN for the MIIS 2003 with SP1 service account.

To verify the SPN setting for MIIS 2003 with SP1

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, type Setspn –L <MIIS service account>, and then press ENTER.

The following SPN should display as registered for the <MIIS service account>:

PCNSCLNT\<MIIS server host name>

PCNS Test 3: Verifying Configuration of MIIS 2003 with SP1 as a Target with PCNS

Complete the following steps to ensure the proper configuration of MIIS 2003 with SP1 as a target with PCNS.

To verify configuration of MIIS 2003 with SP1 as a target with PCNS

  1. Log on to the intranet domain controller with administrative privileges.
  2. At a command prompt, browse to the PCNS installation directory (typically C:\Program Files\Microsoft Password Change Notification).
  3. Type Pcnscfg LIST and then press ENTER.

The output listing should correspond to the setting made in the implementation chapter. Details should include the target name, the MIIS 2003 with SP1 server name, the SPN for the MIIS 2003 with SP1 service account, authentication type, and inclusion/exclusion groups (if any).

PCNS Test 4: Verifying the MIIS 2003 with SP1 Password Source Configuration

Complete the following steps to ensure that MIIS 2003 with SP1 is configured to accept passwords from the Intranet Directory MA.

To verify the MIIS 2003 with SP1 password source configuration

  1. Log on to the computer running MIIS 2003 with SP1 with administrative privileges.
  2. Open Identity Manager, and then on the Tools menu, click Management Agents.
  3. Select Intranet Directory MA, and then on the Actions menu, click Properties.
  4. In the left pane, select Configure Directory Partitions.
  5. Verify that the Enable this partition as a password synchronization source option is selected.

This test confirms that MIIS 2003 with SP1 is configured to accept password changes from the intranet domain controller.

PCNS Test 5: Verifying the Password Synchronization Configuration in MIIS 2003 with SP1

Complete the following steps to ensure password synchronization is configured correctly in MIIS 2003 with SP1.

To verify password synchronization configuration in MIIS 2003 with SP1

  1. Log on to the computer running MIIS 2003 with SP1 with administrative privileges.
  2. Open Identity Manager, and then on the Tools menu, click Management Agents.
  3. Select Sun ONE Directory Server 5.1 MA, and then on the Actions menu, click Properties.
  4. In the left pane, select Configure Extensions.
  5. Verify that the Enable password management option is selected.
  6. Verify the same for Lotus Notes MA.

This test confirms that Sun ONE Directory Server 5.1 and Lotus Notes are configured to synchronize password changes.

Validating Password Propagation

Complete the following tests to verify that the password change is propagated to Sun ONE Directory Server 5.1 and Lotus Notes servers:

  • Propagation Test 1: Verifying client logons
  • Propagation Test 2: Verifying password change notification
  • Propagation Test 3: Verifying password synchronization

Propagation Test 1: Verifying Client Logons

Complete the following procedures to verify that users can log on to the client workstations on two different servers.

To verify user logon to intranet domain

  1. Log on to the intranet domain on a client computer with the credentials of NA\mikedan (or any other user).
  2. Verify that the logon process completes successfully.

To verify user logon to Sun ONE Directory Server 5.1

  1. Log on to the Sun ONE Directory Server 5.1 computer.
  2. Using the iPlanet console 5.1, log on to the directory server with the credentials of mikedan (Mike Danseglio).
  3. Verify that Mike can log on by using the iPlanet console.

To verify user logon to Lotus Notes

  1. Log on to any computer that has the Lotus Notes client installed.
  2. Using the Notes client setup with the mikedan user.id file, log on to the Notes server.
  3. Verify that Mike can log on to the Notes server.

Propagation Test 2: Verifying Password Change Notification

Complete the following procedures to verify that MIIS 2003 with SP1 receives password change notification.

To change passwords by using CTRL+ALT+DEL

  1. Log on to the client computer with the credentials of NA\mikedan (Mike Danseglio).
  2. Press CTRL+ALT+DEL and then click Change Password to change the user password.

To verify that PCNS captures the password change and passes it to MIIS 2003 with SP1

  1. Log on to the domain controller with administrative privileges.
  2. At a command prompt, type eventvwr.msc and then press ENTER to open the Event Viewer Manager console.
  3. Browse to the Application node, and then click it to display the event logs in the right pane of the console.
  4. Verify that the following event is present from the source PCNSSVC:

    Event ID: 2100

    Description: The password notification has been delivered to all targets.

The presence of these events before any error logs confirms the PCNS delivered the password change to MIIS 2003 with SP1.

Propagation Test 3: Verifying Password Synchronization

Complete the following procedures to verify that the password change is synchronized with Sun ONE Directory Server 5.1 and Lotus Notes.

To verify the password change in Sun ONE Directory Server 5.1

  1. Log on to the Sun ONE Directory Server 5.1 computer.
  2. Using the iPlanet console 5.1, log on to the directory server with the changed credentials of mikedan (Mike Danseglio).
  3. Verify that Mike can log on by using the iPlanet console.

To verify the password change in Lotus Notes

  1. Log on to any computer that has the Lotus Notes client installed.
  2. Using the Notes client setup with the mikedan user.id file, log on to the Notes server.
  3. Verify that Mike can log on to the Notes server.

Troubleshooting

This section provides information about some common errors that you may encounter when you test this scenario and how to most likely resolve them. However, the information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.1. Troubleshooting Information

Error

Troubleshooting procedure

Event ID 6025: Thread received an RPC exception

Make sure that the SPN set for the MIIS 2003 with SP1 service account is correct.

Check the time skew between the domain controller and the MIIS server. For Kerberos protocol authentication, this time skew should by default not be more than five minutes.

Extranet Password Management

After the extranet password management implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.

Validating the Implementation Prerequisites

Before you test the implementation guidance, you should perform a few basic prerequisite tests to ensure that the solution infrastructure is correctly configured:

  • Basic Test 1: Verifying the LDAP configuration of the Extranet Web Application
  • Basic Test 2: Verifying whether users can change their passwords
  • Basic Test 3: Verifying whether extranet users receive password expiration notification
  • Basic Test 4: Verifying the hyperlink e-mailed in expiry e-mail links to the Extranet Password Change Web page
Basic Test 1: Verifying the LDAP Configuration of the Extranet Web Application

Complete the following steps to ensure your perimeter web server LDAP settings are correct.

To verify LDAP settings correctly configured

  1. Log on to the Perimeter Web server with administrator privileges.
  2. Using VisualStudio.NET, open the C:\Inetpub\wwwroot\PwdManagement\ExtranetPwdChange\ExtranetPwdChange.sln file.
  3. Edit the web.config file to change the LDAP settings to those of your domain.
  4. Verify the LDAP configuration string matches the extranet domain users Organizational Unit (OU).
Basic Test 2: Verifying Whether Users Can Change Their Passwords

Complete the following steps to ensure that users can change their passwords.

To verify whether users can change their passwords

  1. Log on to the Perimeter Web server.
  2. Open http://localhost/ExtranetPwdChange/PwdChange.aspx.
  3. Complete the Password Change form, entering the credentials of any sales user, and then click Submit.
  4. Verify that you receive a Password Change pass notification.
Basic Test 3: Verifying Whether Extranet Users Receive Password Expiration Notification

Complete the following steps to ensure Extranet users are informed of upcoming password expirations.

To verify password expiration notifications are sent

  1. Edit the Group Policy of the Perimeter domain controller and set the number of days for password expiry to 1.
  2. Change system time on the Perimeter domain controller forward 24 hours to simulate the passing of a day, or, simply wait a day.
  3. Check whether users received their password expiry notification e-mails.
  4. Edit the Group Policy of the Perimeter domain controller, and reset the number of days for passwords to expire.
  5. Correct the system time and date if they have changed.
Basic Test 4: Verifying that the Hyperlink E-mailed in the Expiry Email Links to the Extranet Password Change Web Page

Complete the following steps to ensure extranet users receiving password expiration e-mails can access the password change Web page to change their passwords.

To verify the password expiration notification and Password Change function

  1. After successfully verifying that extranet users are receiving password expiry notification e-mails, open an e-mail generated from Basic Test 3, and then click the link in it.

Clicking this link will open the Extranet Password Change Web page.

  1. On the Password Change Web page, complete the Old Password, New Password and Confirm New Password text boxes, and click Submit.
  2. Log on to the Web page by using the New Password credentials.

Chapter 7: Operating the Solution

After you implement and verify the elements of this solution, you should consider a number of ongoing activities to ensure that it will continue to operate successfully for you.

Previous chapters in the papers of the Identity and Access Management series provide a broad discussion of the management tasks associated with the long-term operation of the infrastructure components for this solution. These chapters include:

  • Chapter 6, "Operating the Infrastructure," of the Platform and Infrastructure paper in this series, which provides information and references about backing up and monitoring Active Directory®, Certificate Services, and Firewall and Proxy Services.
  • Chapter 7, "Operational Considerations," of the Identity Aggregation and Synchronization paper in this series, which provides additional information and references about how to manage a MIIS 2003 with SP1 database, schedule and automate Management Agent runs, and monitor MIIS 2003 with SP1.

This chapter examines specific operational considerations for the elements of this solution.

Enforcing Strong Passwords

The Enforcing Strong Passwords scenario enacts various password setting restrictions through Group Policy on the domain controllers in your Active Directory domain. This section describes some operational activities for Group Policy.

The Group Policy Operations Guide

This scenario relies entirely on Group Policy for its proper implementation and operation. You should be familiar with general Group Policy operations, as they are the standard that this scenario uses. A resource for this information is the Group Policy Operations Guide, available on TechNet.

Account Expiration Management

It is reasonably common for passwords to expire. And there are a number of causes that can make this happen to user account passwords. Passwords could expire due to:

  • Users who are on leave or vacation that extends beyond their password expiration dates.
  • Users logging on at offsite locations who do not receive change password notifications.
  • Users sailing around the world who cannot update their credentials.
  • Users who ignore change password prompts.

Notice that the user is responsible for the majority of these causes. For this reason, user education is important because it can help to minimize password expirations. For example, instructing users going on vacation or leave to change their passwords just before these events helps to ensure that they will not encounter an expired password or disabled account when they return to work.

Note that not all password expirations indicate unused accounts. However, it is important to periodically review all accounts that have expired passwords. Examine these accounts to determine whether you still need them. If it is necessary to retain them, but they will remain unused for some time, consider disabling the accounts until users need them. If the accounts will not be used again, consider deleting them to minimize the number that an attacker can try to access.

User Education

Using passwords in an environment that implements strong password security policies can be difficult. For example, users cannot just use whatever password they like. They must change their passwords periodically, and seemingly rigid password management rules also restrict them. This can make the security experience difficult for the user and the IT staff.

Consider educating the users in your environment both before deploying this scenario and periodically after the settings are in place. Provide information about exactly what security settings are in place and why for your users. You can also offer helpful tips to them to improve their experience. Such tips might include suggestions on password construction, recommendations to change their password before vacation or leave, and how to change their password easily.

You can also periodically run a script to identify users with passwords that are about to expire. You can then send these users information about changing their passwords and other guidance before their passwords expire. This can significantly improve the user experience while maintaining productivity, and save you the IT cost of password resets.

Note You can also use the technology in the Extranet Password Management scenario to identify and notify users whose passwords are about to expire. For more information, refer to this scenario throughout this chapter.

Intranet Password Management

The intranet Password Management solution in this paper describes how to use a password notification and filtering dynamic-link library (DLL) on all domain controllers to intercept password change requests. A Windows® service called the PassSync service then uses Windows Management Instrumentation (WMI) to redirect the change requests to the configured management agents (MA) in MIIS 2003 with SP1. MIIS 2003 with SP1 then updates the designated identity stores with the new password information. After a password change has been successfully processed, the intermediate data is deleted from the MIIS 2003 with SP1 Server. The following sections describe some operational considerations for this solution.

Connected Systems Management

The intranet Password Management solution is designed to support many different types of systems. Although the main portion of the solution is configured on Microsoft Windows Server™ 2003, there may be numerous heterogeneous networks connected to this solution through MIIS 2003 with SP1 and its MAs. Ensure that you regularly maintain each of these networks and the MAs associated with them according to the network guidance.

In particular, carry out periodic administrative and service account password changes on all systems. Changing the password that MIIS 2003 with SP1 or an MA runs may require you to reconfigure a component to reflect the new password. Failure to do so may result in lost connectivity and unsynchronized passwords.

For more information about MIIS 2003 with SP1 MA configuration, refer to the MIIS 2003 with SP1 documentation. For information about maintaining security on interconnected network systems, refer to your network system documentation.

PCNS Installation Verification

In Chapter 6, "Testing the Solution," of this paper you verified the installation of the Password Change Notification Service (PCNS) on all of the domain controllers in your environment. This is important because any domain controllers that do not have PCNS installed will not report password changes to MIIS 2003 with SP1, and then the passwords will not be synchronized.

Many domains have a variable number of domain controllers. This is because new domain controllers are periodically introduced as old ones are retired. If you have a standard build process for your domain controllers, ensure that you install PCNS during this process. Also periodically verify that all domain controllers are running PCNS.

A script named PCNSLookup.vbs can help you complete this task. The script is included in the Microsoft Identity Integration Server 2003 Resource Toolkit 2.0.

Monitoring PCNS and MIIS 2003 with SP1

Regularly monitoring PCNS can help you maintain this solution. PCNS creates numerous events that can indicate the health of the system, as well as errors and configuration problems. These events can also help you determine the source of performance and functionality issues.

The Microsoft Password Change Notification Service Management Pack for MOM is designed to help streamline monitoring and analysis of these events.

Regularly monitoring MIIS 2003 with SP1 will also help you maintain this solution. MIIS 2003 with SP1 creates numerous events that can indicate the health of the system, as well as errors and configuration problems. These events can also help you determine the source of performance and functionality issues.

Monitoring MIIS 2003 with SP1 operations with MOM will assist you to address and resolve identify problems as quickly as possible. For more information about monitoring MIIS 2003 with SP1, see:

  • The MIIS 2003 Management Pack Guide on TechNet.
  • The MIIS 2003 Management Pack for MOM 2000 SP1 package from the Microsoft Download Center.

The Microsoft Operations Manager Resource Kit offers another set of tools that you can use to monitor MIIS 2003 with SP1. The tool set includes the Service Status Monitor, which allows you to determine the state of MIIS 2003 with SP1 servers. This can help you to quickly identify any servers that have failed. You can download the Microsoft Operations Manager Resource Kit.

PCNS Events

Monitoring PCNS involves the capture and analysis of event logs. PCNS creates events in the event log for a variety of tasks that either complete or fail. While most of these events are self-descriptive, some are difficult to understand.

For your reference, the complete list of PCNS events is available in the Release Notes of the Microsoft Identity Integration Server 2003 Scenarios package. You can obtain the release notes in the Identity Integration Server Walkthrough Scenarios.msi package.

Extranet Password Management

The extranet Password Management solution in this paper describes how to deploy a self-service Web-based password management solution. Specifically, this solution provides extranet users with the ability to manage their own passwords through a customizable Web interface that maintains security during the password change process.

This solution also notifies extranet users when their passwords are about to expire so that they can change them before they do. There are several operational considerations to make after you have deployed and tested this solution.

Network Port Usage

The extranet password management solution includes several different components. Many of them may run on different computers. However, the computers involved must properly flow password information, and synchronize the passwords on the different systems. Although these requirements must be met, many networks restrict communications over specific ports to mitigate a variety of threats. For this reason, it is important to know which ports the solution uses to properly configure and monitor communication.

The following tables are taken from Chapter 5, "Implementing the Solution," of the Identity Aggregation and Synchronization paper in this series.

The paper provides the basis to implement and verify the extranet password management solution. However, because network configurations change and different threats emerge over time, you may need to refer to this list of required ports to ensure that the solution will continue to function.

The following table lists all the outbound ports in the external firewall that you need to open from the MIIS 2003 with SP1 server's IP address to the external domain controller's IP address.

Table 7.1. MIIS 2003 with SP1 Server Outbound Ports to External Domain Controller

Outbound port

Protocol

Purpose

389

TCP and UDP

LDAP

88

TCP and UDP

Kerberos authentication protocol

135

TCP

RPC Endpoint Mapper (may require additional open ports)

464

TCP and UDP

Kerberos Change Password

The following table lists the outbound port in the internal firewall that you need to open from the internal root domain controller's IP address to the external domain controller's IP address.

Table 7.2. Internal Root Domain Controller Outbound Port to External Domain Controller

Outbound port

Protocol

Purpose

53

TCP and UDP

DNS

SSL Certificate Management

The Extranet Password Management scenario employs secure sockets layer (SSL) security to help encrypt password change requests between the client and the Internet Information Services (IIS) server. SSL is highly effective at this, in part because it is a certificate-based security solution that uses strong encryption to protect the data.

You must maintain the SSL certificate on the IIS server. Certificates have a specified lifetime, after which client computers may no longer trust them. The certificates also have an associated private key that you should archive in case the IIS server experiences data loss.

These operational tasks are part of IIS management. For more information, see the About Certificates topic in the Windows Server 2003 Help and Support Center documentation.

Service Account Management

The Identity Management (IdM) Notification Service for this solution requires you to use administrative credentials to log on to the service to make it perform. The scenario requires you to create an account called Extranet Admin that you can then use as the logon account for the service. This information is added to the IdMNotificationSvc.exe.config file that you configure while deploying the scenario.

The password for this account should periodically change due to password policy improvements, password expiration, and so forth. You must update the IdM Notification Service with the new password in order to maintain the service. Otherwise, the service will record failed logon attempts, and it will fail to connect to other computers. In addition, if you have enabled account lockout, the service may lock the account out.

To maintain access to this service, complete the following two tasks to update the password for the IdM Notification Service immediately after the password for the Extranet Admin account has changed.

The tasks are to:

  • Update the password in the IdMNotificationSvc.exe.config file. Modify the remoteLDAPCredentials value to reflect the new password.
  • Restart the IdM Notification Service.

When the service restarts, it will read the updated IdMNotificationSvc.exe.config file, and then use the new password during the network authentication process.

Exchange Mailbox Maintenance

Part of this solution focuses on notifying extranet users when their passwords are about to expire. Because extranet users do not receive automatic notification, this solution uses e-mail from a Microsoft Exchange-based solution to send users e-mail when their passwords are about to expire.

The notification service is configured during deployment to use a specific Exchange mailbox from which to send the e-mail. This mailbox can both send and receive e-mail. In fact, returned e-mail or replies to notifications also go to this mailbox. Some of these messages may be important because they can indicate incorrect e-mail addresses or contain important information from extranet users. In addition, the amount of e-mail in the Exchange mailbox could eventually exceed the user's storage capacity. This could lead to suspension of outgoing e-mail from the account, which would block password expiration notification messages.

To ensure that this does not happen, regularly check and clear the Exchange mailbox. For information about how to do this, see the Product Documentation for Exchange Server 2003 Web site.

Monitoring MIIS 2003 with SP1

Regularly monitoring MIIS 2003 with SP1 will help you maintain this solution. MIIS 2003 with SP1 creates numerous events that can indicate the health of the system, as well as errors and configuration problems. These events can also help you determine the source of performance and functionality issues.

Monitoring MIIS 2003 with SP1 operations with MOM will assist you to address and resolve identify problems as quickly as possible. For more information about monitoring MIIS 2003 with SP1, see:

  • The MIIS 2003 Management Pack Guide on TechNet.
  • The MIIS 2003 Management Pack for MOM 2000 SP1 package from the Microsoft Download Center.

The Microsoft Operations Manager Resource Kit offers another set of tools that you can use to monitor MIIS 2003 with SP1. The tool set includes the Service Status Monitor, which allows you to determine the state of MIIS 2003 with SP1 servers. This can help you to quickly identify any servers that have failed. You can download the Microsoft Operations Manager Resource Kit.