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 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:
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.
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:
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.
Readers who want to implement the guidance in this paper must have the following:
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.
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:
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.
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.
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.
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:
Subsequent chapters describe how a subset of these approaches addresses the scenarios identified in Chapter 1, "Introduction to the Password Management Paper."
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:
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.
A successful password policy must consider many issues and tradeoffs. This section explores such aspects of password policy as:
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 is always a tradeoff. The security tradeoff paradigm typically involves three factors:
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.
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:
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.
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.
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.
When you enforce the use of strong passwords, you help protect your organization against two primary threats: physical access and network authentication.
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.
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.
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:
Most password policies use a combination of both approaches to increase security.
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.
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:
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.
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.
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:
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.
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.
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.
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.
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:
In a heterogeneous environment with several identity stores, the password change must then replicate to multiple locations.
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:
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.
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 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:
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:
MIIS 2003 with SP1 also provides password extension support with the following management agents:
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.
The following ISVs produce password synchronization products:
For more information about these products and ISVs, see the Overview paper in this series.
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:
These credential mapping password management features work best if the target systems are only accessed through the credential management software.
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.
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.
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:
For more information about these products and ISVs, see the Overview paper in this series.
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:
For more information about the Contoso scenario, see the Platform and Infrastructure paper in this series.
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.
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.
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.
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.
Contoso translated these issues into the following requirements for the company's password policy:
Contoso can support these requirements through Active Directory Group Policy.
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.
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.
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.
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.
Contoso distilled the issues related to password change and synchronization into the following requirements for the company's password policy:
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.
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.
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.
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.
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.
Contoso translated these password change issues into the following requirements for the company's password policy:
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.
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.
Contoso identified the following as important goals for the company's password policy:
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.
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).
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.
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.
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.
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.
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.
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:
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.
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.
To meet the password change and synchronization requirement for Contoso at a conceptual level, the company evaluated the following two possible solutions:
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.
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.
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.
The architecture of the Intranet Password Management solution is identical to the architecture of the PCNS feature of MIIS 2003 with SP1.
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:
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.
To meet the extranet password management requirements at a conceptual level, Contoso evaluated two possible solutions:
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.
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.
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.
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:
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.
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."
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.
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. |
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. |
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:
For more information about these prerequisites, see the Platform and Infrastructure paper in this Series.
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:
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
Figure 5.2. Password policy options
To prevent users from recycling passwords
Figure 5.3. Configuring the Enforce password history option in the Group Policy Object Editor
To make passwords expire at a set interval
To ensure that users cannot change passwords again immediately
To ensure that users use minimum-length passwords
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
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.
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:
For more information, see the following Identity and Access Management Series papers:
Implementing this solution scenario involves the following activities:
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.
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:
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.
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.
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.
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
Task 2: Compiling and Configuring the Group Management Applications
To compile the Notification Service program
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
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"
NET START IdMNotificationSvc
You should see the message "The IdM Notification Service started successfully."
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
Task 2: Installing the Web Application
To install the Web application
Important Do not change the default name that is selected for you.
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
Task 2: Changing the Solution to Use the LDAP Settings of Your Domain
To use the LDAP settings of your domain
Task 3: Verifying That the Application Is Hosted
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.
Task 1: Verifying That IdmNotificationSvc Is Running
Task 2: Verifying That the Extranet Password Change Application Will Run
Note If you receive a 404 Page Not Found error, restart IIS by opening a command prompt, typing IISReset, and pressing Enter.
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.
After the strong password implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.
Before you test the implementation guidance, you should perform the following basic prerequisite test to ensure that the solution infrastructure is correctly configured:
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
The dcdiag utility executes a series of tests. All tests should pass.
To check the domain controller's event log for errors
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.
In this scenario, the following test areas are important for validating key requirements and functionality:
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
Complete the following steps to verify that the new settings are replicated to each domain controller.
To verify setting replication
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.
Complete the following tests to verify that the new settings are being enforced correctly:
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
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
You should be prompted to change your password immediately and informed that your password expires in 60 days.
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
Change the password to another easily remembered password, or write it down.
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
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
Change the password to an easily remembered password, or write it down.
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
This password change should fail; even though the password is long enough to meet the minimum required length, it is not complex.
This password change should succeed because it is both long and complex enough to meet the system's password policy.
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."
Before you test the implementation guidance, you should perform a few basic prerequisite tests to ensure that the solution infrastructure is correctly configured:
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
The dcdiag utility executes a series of tests. All tests should pass.
To check the domain controller's event log for errors
There should be no errors in the event log.
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
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
The UI should display server status as Started.
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
The Exchange server must have an SMTP type with an address value of @contoso.com.
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
Name: na.corp.contoso.com
Address: 192.168.0.202
NSLOOKUP must succeed when you use the fully qualified domain names (FQDN) of the intranet and extranet domains.
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
The MIIS 2003 with SP1 server should receive a response from the intranet domain controller.
A Telnet connection should be made to the extranet domain controller.
All network connectivity tests should pass without failure.
In this scenario, the following test areas are important for validating key requirements and functionality:
Complete the following tests to verify the proper configuration of the PCNS:
PCNS Test 1: Verifying That PCNS Is Started
Complete the following steps to verify that the PCNS runs.
To verify that PCNS runs
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
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
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
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
This test confirms that Sun ONE Directory Server 5.1 and Lotus Notes are configured to synchronize password changes.
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
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
To verify user logon to Sun ONE Directory Server 5.1
To verify user logon to Lotus Notes
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
To verify that PCNS captures the password change and passes it to MIIS 2003 with SP1
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
To verify the password change in Lotus Notes
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.
After the extranet password management implementation is complete, you are ready to validate your implementation to ensure that it meets the requirements.
Before you test the implementation guidance, you should perform a few basic prerequisite tests to ensure that the solution infrastructure is correctly configured:
Complete the following steps to ensure your perimeter web server LDAP settings are correct.
To verify LDAP settings correctly configured
Complete the following steps to ensure that users can change their passwords.
To verify whether users can change their passwords
Complete the following steps to ensure Extranet users are informed of upcoming password expirations.
To verify password expiration notifications are sent
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
Clicking this link will open the Extranet Password Change Web page.
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:
This chapter examines specific operational considerations for the elements of this solution.
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.
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.
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:
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.
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.
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.
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.
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.
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 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.
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.
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.
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 |
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.
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:
When the service restarts, it will read the updated IdMNotificationSvc.exe.config file, and then use the new password during the network authentication process.
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.
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 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.