ࡱ> 5@ bjbj22 "JXX8Ҡl>a&(NNNNa7D{$$RS^]aNN$WWWNNWWW|N o+>4<%<ahh|`W\ yXAccount Passwords and Policies MicrosoftWindowsNT Server4.0, Windows 2000, Windows XP, and the Windows Server2003 Family Ramesh Chinta, Program Manager, Microsoft Corporation Mike Danseglio, Technical Writer, Microsoft Corporation Mike Resnick, Technical Lead, Microsoft Corporation Acknowledgements Vincent Abella, Technical Editor, Microsoft Corporation Jen Bayer, Technical Writer, Microsoft Corporation Emily Moon, Technical Editor, S&T OnSite Joseph Vasil, Support Engineer, Microsoft Corporation Introduction Password and account lockout settings are designed to protect accounts and data in your organization by mitigating the threat of brute force guessing of account passwords. Settings in the Account Lockout and Password Policy nodes of the Default Domain policy settings enable account lockout and control how account lockout operates. This white paper describes how these settings affect account lockout and makes some general recommendations for configuring and troubleshooting account lockout issues. Account Lockout and Password Concepts Passwords are an important step in a security plan for your network. Users may see passwords as a nuisance; however, the security of your enterprise relies on a combination of password length, password uniqueness, and password lifespan. These three items help defend against dictionary attacks and brute force attacks. A dictionary attack occurs when a malicious user tries known words that are in the dictionary and a number of common password names to try and guess a password. A brute force attack occurs when a malicious user tries all of the possible permutations until one is successful. Because most users prefer passwords that they can easily remember, dictionary attacks are often an effective method for a malicious user to find a password in significantly less time than they would with brute force attacks. Therefore, the strength of a password depends on how many characters are in the password, how well the password is protected from being revealed by the owner, how well the password is protected if it is intercepted by a malicious user on the network, and how difficult the password is to guess. Even good passwords that are protected by cryptography on the network and that are not subject to dictionary attacks can be discovered by brute force in a few weeks or months by a malicious user who intercepts the password on the network. Currently, several attack methods are based on guessing weak passwords by using dictionary and brute force attacks. For a few simple ways to help prevent these attacks, see "Protecting from External Lockout Denial of Service Attacks" in this document for ports to block and registry values that you can set to help prevent such attacks. Frequently, a malicious user will guess a number of passwords during a password-based attack. To help prevent the attacks from being successful, you can configure account lockout settings. The result of this configuration is that the associated account is temporarily disabled after a specified number of incorrect passwords are tried. This helps to prevent a successful attack by preventing the account from being used. However, a legitimate user cannot use that account until it is unlocked. This paper discusses the balance between the benefits and risks of account lockout. Understanding Password Complexity A complex password that is enforced by the operating system is one of the most effective methods that you can use to deter the opportunity for a successful attack. When you configure both an expiration time and a minimum length for a password, you decrease the time in which a successful attack could occur. For example, when you enforce password complexity with a password length of 6 and set the password to expire in 60days, a user can choose from a permutation of: 26lowercase characters 26uppercase characters 32 special characters 10 numbers This means that: 26 + 26 + 32 + 10 = 94 possible characters in a password Password length policy = 6 946 = 689,869,781,056 unique password permutations With a 60-day password expiration time, the malicious user would have to make 133,076 password attempts every second to attempt all of the possible passwords during that password's limited lifetime. If it takes only 50percent of the permutations to guess the password, a malicious user would have to attempt to log on to the computer about 66,538 (133,076*.50) times every second to discover the password before it expires. To decrease the chances that a malicious user has to discover the password, you can use a password length of7. When you set the minimum password length to 7, the possible password permutations exceed 64trillion (947= 64,847,759,419,264). When you compare the calculations above that have a password length of 6 to the calculations below that have a password length of7, you will notice that the malicious user would have to log on to the computer about 6,254,606 times for each second that the password is valid in the 60-day expiration time that you set. The following list describes how increasing password length deters both dictionary and brute force attacks. Note that the examples that are in this list assume that you are have applied a policy that requires users to create complex passwords. When you do this, there are 94possible characters from which the users can choose their password. 6 characters: 946 = 689,869,781,056 7 characters: 947 = 64,847,759,419,264 8 characters: 948 = 6,095,689,385,410,816 9 characters: 949 = 572,994,802,228,616,704 10 characters: 9410 = 53,861,511,409,489,970,176 NoteA few of these password possibilities are not valid. By default, users cannot choose any part of their user name for their password and they cannot use all of the same characters as a password. Because of this, these password possibilities must be deducted from the total number of possible passwords that are listed above. Because there are very few passwords that apply to these exceptions and because the number of passwords that do apply to these exceptions can vary (based on the number of letters that are in the user's logon name), this document does not account for these exceptions. These statistics explain how difficult it is for a malicious user to discover a password when you require the users in your network to use a complex password. Because of this, Microsoft recommends that you enforce a complex password policy that requires users to choose passwords with a specific number of characters for the security needs of your organization. The "Password Policies Settings" section in this document describes the complex password policies and settings for Microsoft( WindowsNT( Server4.0, the Windows(2000 family, and the Windows Server2003 family of operating systems. Microsoft recommends that you use the account lockout feature to help deter malicious users and some types of automated attacks from discovering user passwords. The following section provides more information about how you can use the account lockout feature. Authentication Authentication is the process of validating a user name and password on a domain controller for: The initial logon to either a workstation or domain that uses the CTRL+ALT+DELETE secure logon sequence. An attempt to unlock a locked workstation by using the CTRL+ALT+DELETE secure logon sequence. An attempt to type a password for a password-protected screen saver. A user, script, program, or service that attempts to connect to a network resource by using either a mapped drive or a Universal Naming Convention (UNC) path. NoteAn account that is locked out may still be able to gain access to some resources if the user has a valid Kerberos ticket to the resource. The ability to access the resource ends when the Kerberos ticket expires. However, neither a user who is locked out nor a computer account can renew the ticket. Kerberos cannot grant a new ticket to the resource because the account is locked out. There are two primary authentication protocols used by Windows: NTLM and Kerberos. This paper assumes you are familiar with these authentication protocols and does not focus on authentication details. Instead, the focus is placed on how authentication plays a role in account lockout. For more information on authentication protocols, see online help in WindowsXP and the Windows Server2003 family. How Domain Controllers Verify Passwords To illustrate the authentication process, the following diagram describes the steps that occur when a logon attempt does not work. Figure 1 Process for a Failed Logon Attempt  The client computer presents the user logon information to a domain controller. This includes the users account name and a cryptographic hash of their password. This information can be sent to any domain controller and is typically sent to the domain controller that is identified as the closest domain controller to the client computer. When a domain controller detects that an authentication attempt did not work and a condition of STATUS_WRONG_PASSWORD, STATUS_PASSWORD_EXPIRED, STATUS_PASSWORD_MUST_CHANGE, or STATUS_ACCOUNT_LOCKED_OUT is returned, the domain controller forwards the authentication attempt to the primary domain controller (PDC) emulator operations master. Essentially, the domain controller queries the PDC to authoritatively determine if the password is current. The domain controller queries the PDC for this information because the domain controller may not have the most current password for the user but, by design, the PDC emulator operations master always has the most current password. The authentication request is retried by the PDC emulator operations master to verify that the password is correct. If the PDC emulator operations master rejects the bad password, the PDC emulator operations master increments the badPwdCount attribute for that user object. The PDC is the authority on the user's password validity. The failed logon result information is sent by the PDC emulator operations master to the authenticating domain controller. The authenticating domain controller also increments its copy of the badPwdCount attribute for the user object. The authenticating domain controller then sends a response to the client computer that notifies the domain controller that the logon attempt did not work. As long as that user, program, or service continues to send incorrect credentials to the authenticating domain controller, logon attempts that failed because of an incorrect password continue to be forwarded to the PDC until the threshold value for incorrect logon attempts is reached (if you set it in a policy). When this occurs, the account is locked out. For more information, see "How the Bad Password Count Is Incremented in WindowsNT" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=219898. New Features in the Windows Server2003 Family In the Windows Server2003 family of operating systems, Microsoft has improved the function of the Account Lockout feature on both servers and client computers. Computers Running Windows Server2003 That Act As Network Servers To improve the experience for users and to decrease the overall total cost of ownership, Microsoft made the following changes to the behavior of domain controllers in the Windows Server2003 family: Password history check (N-2): Before a Windows Server2003 operating system increments badPwdCount, it checks the invalid password against the password history. If the password is the same as one of the last two entries that are in the password history, badPwdCount is not incremented for both NTLM and the Kerberos protocol. This change to domain controllers should reduce the number of lockouts that occur because of user error. Single user object on demand replication: See the "Urgent Replication" section in this document for more information. Optimized replication frequency: The default frequency for replication between sites is to replicate every 3 hours. This optimization improves the replication of a password change in a site because it decreases the chances that the domain controller would have to contact the PDC operations master. Computers Running Windows Server2003 Family Acting As Network Clients Microsoft has added the following features in the Windows Server2003 family to gather the process ID that is using the credentials that fail authentication: Auditing logon changes: There are entries for all logon and logoff events (528 and 540, as well as 529 through 539). Auditing of processes encountering authentication failures: New information is added to the Security event log when authentication failures occur: Caller User Name Caller Domain Caller Logon ID Caller Process ID NoteTo use the process ID, turn on success auditing for Audit process tracking events so that you can obtain the process identifier (PID) for the associated Event592. If you do not do this, the PID is not useful after the process stops. To view audit process tracking, in the Group Policy Microsoft Management Console (MMC), in the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click Audit Policy. Microsoft has added the following administrative enhancements to provide more account lockout information than the information that is available in the default configuration of the Windows Server2003 family: AcctInfo.dll: The AcctInfo.dll file is a property page extension for user objects in the Active Directory Users and Computers MMC that provides detailed information about user password attributes. An administrator can use the AcctInfo.dll file to reset user account passwords on a domain controller that is in the user's Active Directory site. LockoutStatus.exe: The LockoutStatus.exe tool displays bad password count and time information from all of the domain controllers that are in a domain. You can run this tool as either a stand-alone tool or as an extension to the AcctInfo.dll file when you place it in the Systemroot\System32 folder on your computer. More information about both AcctInfo.dll and LockoutStatus.exe is available in "Account Lockout Tools" in this document. Configuring Account Lockout Settings To enable the Account Lockout policy settings for both domain and local users, configure the settings that are described in this section. Recommended Service Packs and Hotfixes Security issues in Windows operating systems are discovered and fixed often. These fixes often have an impact on account lockout and password policy features, as well as their dependent components. Therefore, you should apply the latest service packs and hotfixes to all of the domain controllers, servers, and clients to ensure that the account security settings that you want are applied and to ensure that the domain controllers and operating systems are up-to-date. Note that service packs resolve groups of issues and hotfixes resolve a specific issue. You should have an ongoing strategy to keep your computers updated and protected against viruses, trojans, and so on, that may use vulnerabilities that are already fixed. For more information about how to create a software update strategy, refer to Help and Support Center in the Windows Server2003 family and WindowsXP, or refer to Help in Windows2000. Because these issues are discovered and fixed on an ongoing basis, they are not listed in this document. For more information, see "Service Packs and Hotfixes Available to Resolve Account Lockout Issues" in the Microsoft Knowledge Base| HYPERLINK "http://support.microsoft.com/?id=817701" http://support.microsoft.com/?id=817701. Configuring Account Lockout The account lockout policy settings are designed to help prevent a brute force attack on user passwords. This section describes where you can configure the setting, as well as some things that you should consider before you use the settings. Configuring Account Lockout for Domain Users For domain users, set the appropriate values by configuring the default domain policy in the console tree. To configure the default domain policy, open the Group Policy MMC, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then double-click Account Lockout Policy. For more detailed steps, see "Account Lockout Settings" in this document. Configuring Account Lockout for Local Users For a stand-alone workstation, set the appropriate registry values by configuring the local policy: Click Start, click Run, type gpedit.msc, and then press ENTER. In the Group Policy Object Editor MMC, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then double-click Account Lockout Policy. In the details pane, right-click the policy setting that you want, and then click Properties. If you are defining this policy setting for the first time, click Define this policy setting. Select the options that you want, and then click OK. Microsoft recommends that you do not exempt the privileged accounts from password policies. Your privileged accounts should have complex passwords, an expiration period, and the passwords should be a minimum of fifteen characters in length. Microsoft also recommends that you also protect the local accounts (non-domain clients) by using a local password policy for all users. For all workstations in a domain, set a domain-level Group Policy object (GPO) and filter it to apply to the domain member computer. Choosing Account Lockout Settings for Your Deployment This section describes the ramifications of changing the various settings and a way to estimate the difficulty of using the brute force method of password guessing with a certain configuration. Like other settings that are associated with passwords, choosing settings for account lockout involves balancing the benefits and drawbacks between security, usability, and cost. The primary consideration is how much risk is acceptable when you configure the password policy of the domain. For example, consider the following two domain configurations: User accounts that are in domainA have a minimum password length of 3 characters, no password complexity requirements, and passwords never expire. User accounts that are in domainB have a minimum password length of 6 characters, password complexity, and passwords in the domain expire in 42 days. There is less risk of a malicious user guessing the password of a domainB user; for the same risk tolerance, domainB can have a less stringent account lockout policy. Whether you set the LockoutDuration registry value to0 or not also has an important on the setting that is permitted for both the ObservationWindow and LockoutThreshold registry values. As an example, assume that the administrator resets the password when the account is locked with LockoutDuration registry value of 0. With the LockoutDuration registry value set to 0 and the LockoutThreshold registry value set to 20, the malicious user has 20guesses to use against that password. If the lockout duration is 30minutes, the malicious user has 20guesses every 30minutes against that password until it is changed. This is a very significant difference in the total number of guesses that are available to the malicious user. In comparison, if the administrator sets the maximum password age to 42days, the first malicious user has only 20guesses against any given password, while the second malicious user has 40,320guesses (20tries for ever lockout, multiplied by 48lockouts every day, multiplied by 42days before the user changes the password). With the default password settings, there are approximately 1012 possible passwords. This means that the malicious user has approximately a .000004percent (%) chance of guessing the password. With an optimized guessing scheme, this percentage would most likely be a larger percentage. This example demonstrates that setting the LockoutDuration registry value to0 allows the LockoutThreshold registry value to be a significantly higher number for equivalent risk tolerance. If you increase the LockoutThreshold registry value, you help to reduce the behavior of a user accidentally locking themselves out of their computer. When you choose the setting for account lockout, it is important that you consider the inherent denial of service that is associated with a locked out account. Ideally, the only accounts that are locked out are the accounts that are being attacked. However, the computer cannot determine the difference between a user typing an incorrect password or an automated task that is using an incorrect password. As a result, from the users perspective, users who are trying to perform their daily tasks may be suddenly unable to perform their work, which incurs both the cost of support to the domain and the cost of lost work. The lower the value that you set for the LockoutThreshold registry value, the more likely this behavior is to occur. The length of the ObservationWindow registry value has much less effect on this behavior than the LockoutThreshold registry value. Microsoft recommends that you regularly review the Security event logs of all computers so that you are aware of any patterns that might show an attack or user error. The values that are necessary to identify specific malicious users and targets can be obtained only after you implement the auditing policies that are mentioned in the "Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues" section in this document. Microsoft offers an event log monitoring solution, Microsoft Operations Manager (MOM), that you can script with responses. This tool also has many other built-in actions that you can use. For more information about MOM, see the MOM Web sitehttp://www.microsoft.com/mom/default.asp. NoteWeb addresses can change, so you might be unable to connect to the Web site or sites mentioned here. LockoutThreshold vs. ObservationWindow In general, the LockoutThreshold value has more of an effect on how the computer behaves than the ObservationWindow value. Most logon attempts that do not work occur during a very short period of time. Because of this, the period of time is inside of the ObservationWindow time. Users rarely type a bad password many times in a row, so the LockoutThreshold value is rarely exceeded. The exception to this is the environment where the LockoutThreshold registry value is set so low that a user could accidentally mistype their password often enough to lock themselves out (for example, if you set the LockoutThreshold value to2). Malicious password attacks are almost always automated. A user typically locks themselves out of their computer when they type a bad password once and try to type that same bad password over and over again. Recommended Account Lockout Settings The security configuration for an organization is determined by the level of protection that is required in the organization's environment. In some low-security scenarios (such as in a small office where no sensitive information is stored in the system), a simple password policy may be sufficient to protect the resources. However, in a high-security environment (such as in a banking system), much stronger security protection is desired. You should use account lockout and strong password policies in these environments. In all examples, the stronger the security that is implemented, the higher the cost that is associated with maintaining that security. The following table provides recommended account lockout settings for many different security configurations. Table 1 Recommended Account Lockout Settings Security categoryAccount lockout settingsCostThresholdObservation windowLockout durationLowN/AN/AN/ALowMedium103030MediumHigh1030Infinite/0HighNote"Cost" includes downtime cost for the user whose account is locked out, as well as support cost for servicing the locked out account. Recommended Password Policy Settings The table below provides recommended password policy settings for various security configurations. Table 2 Recommended Password Policy Settings Security CategoryPassword policy settingsCostPassword historyMaximum password ageMinimum password ageMinimum password lengthComplexityLow34200disabledLowMedium244217enabledMediumHigh244218enabledHighGeneral Recommendations for Account Lockout and Password Policy Settings In addition to the specific account lockout and password policy settings in the previous tables, there are some other configuration changes that may help you achieve the level of security that you want. These include: When you enable account lockout, set the ForceUnlockLogon registry value to1. This setting requires that Windows re-authenticates the user with a domain controller when that user unlocks a computer. This helps to ensure that a user cannot use a previously-cached password to unlock their computer after the account is locked out. False lockouts can occur if you set the LockoutThreshold registry value to a value that is lower than the default value of10. This is because users and programs can retry bad passwords frequently enough to lock out the user account. This adds to administrative costs. After you unlock an account that is locked out, verify that the LockoutDuration value is set. You should do this because the value may have changed during the account unlock process. Carefully consider setting the LockoutDuration registry value to0. When you apply this setting, you may incur additional administrative labor by requiring administrators to manually unlock a locked out user account. Although this does increase security, the increased labor drawback may outweigh the security benefit. Define account lockout and password policies once in every domain. Ensure that these policies are defined only in the default domain policy. This helps to avoid conflicting and unexpected policy settings. Unlock an account from a computer that is in the same Active Directory site as the account. By unlocking the account in the local site, urgent replication occurs in that site which triggers immediate replication of the change. Because of this, the user account should be able to regain access to resources faster than waiting for replication to occur. Note that the AcctInfo.dll tool helps to identify an appropriate domain controller and unlock the account. For more information about AcctInfo.dll, see the "Account Lockout Tools" section in this document. Protecting from External Account Lockout Denial of Service Attacks It is possible for a malicious user to launch a denial-of-service attack against your enterprise from outside of your network. Because most networks are interconnected, this can be a difficult attack to mitigate. The following techniques technologies are common techniques and technologies that you can use to help mitigate or prevent such attacks: Require complex passwords: All accounts should have a complex password. All administrator accounts (local and domain) should have a long, complex password and you should change the password regularly. Rename the administrator account: Because the administrator account cannot be locked out, it is recommended that you rename the account. Although this does not mitigate all of the attacks against the administrator account, it does help mitigate these attacks most of the time. For more information, see "HOW TO: Rename the Administrator and Guest Account in Windows 2000" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=320053. Protect your environment with firewalls: To avoid an account lockout denial of service attack, block the TCP and UDP ports135 through139 and port445 on your routers and firewalls. When you do this, you prevent logon attempts that occur outside of your network. Prevent anonymous access: Set the RestrictAnonymous value to2 on all computers that are exposed to the internet and to the entire domain if all of the computers are running versions of Windows2000 or later. This stops malicious users from making anonymous connections to resources and may help defeat some types of attacks. Note that some operating systems have limited support for computers that have this setting. Some programs may also have issues with this setting if the programs use an anonymous connection to gain access to resources. For more information, see "How to Use the RestrictAnonymous Registry Value in Windows 2000" on the Microsoft Knowledge Basehttp://support.microsoft.com/?id=246261. Protect site-to-site traffic by using a VPN tunnel: If communication between domain members in two sites is required, use a site-to-site VPN tunnel to securely connect site networks together. Do not open all NetBIOS ports on the firewall. You can use the Windows2000 Server Routing and Remote Access service to create site-to-site VPN tunnels. If no VPN devices are available, you should configure the edge firewall or router filters to limit the traffic that is permitted to flow between the Internet Protocol (IP) address ranges that are used by each site. If sites need to use Active Directory replication only across the Internet, then use Internet Protocol security (IPSec) transport mode through the firewalls to secure all traffic between Active Directory servers. For more information about Active Directory replication through firewalls, see the "Active Directory Replication over Firewalls" white paper on the Microsoft Web site|http://www.microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp. Protecting authentication and NetBIOS ports from Internet attack: On either the firewall or the router that connects your internal network to the Internet, block access to TCP and UDP ports135 through139 and port445. If no edge filtering device is available, you can use IPSec filters to block these ports. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878. In the same IPSec policy, you must create an additional rule that adds filters to permit traffic to these ports when the source address is in a subnet that is used by the internal network. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=813878. Protecting authentication and NetBIOS ports from internal attack: If you must protect access to both authentication and NetBIOS ports from internal malicious users, you can restrict the computers that are permitted to gain access to these ports to only domain member computers by using the feature in IPSec that allows you to negotiate security. By allowing only trusted computers (domain member computers) to gain access to both authentication and NetBIOS ports, you reduce the number of computers that can perform the attack. This extra protection provides a defense against any breaches in your security perimeter and against malicious users who can connect to the internal network. For information about how to create a custom IPSec policy to use Kerberos authentication when negotiating IPSec security for access to TCP and UDP ports135 through139 and port445 see the "Step-by-Step Guide to Internet Protocol Security (IPSec)" on the Microsoft Web site|http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp. Update the server: Keep all of your servers up-to-date with current versions of antivirus software, firewall software, and Windows security patches. This helps prevent trojan horse programs and viruses from attacking your resources if the malicious user can launch an attack from your internal network instead of from the Internet. These updates are an important part of an in-depth and defensive security strategy. Details of Account Lockout Settings and Processes With the account lockout feature enabled, access to the account is denied when the number of logon attempts that did not work exceeds the LockoutThreshold registry value (the account lockout threshold) in a specified amount of time. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for that account expires. Account Lockout is disabled on default installations of WindowsNT Server4.0, Windows2000, and WindowsServer 2003 domains. Account lockout operation is enabled after the domain administrator enables settings in the default domain policy. The policy settings remain enabled when you upgrade domain controllers to a later version of an operating system. Although the Group Policy Object Editor appears to support account lockout and password policy in each organizational unit, these settings actually occur across the domain; you must define the settings on the root organizational unit for the domain. Microsoft recommends that you define account lockout and password policies in only one Group Policy object (GPO) for every domain (in the Default Domain policy settings). Password Policy Settings The first step that you should use to secure your network is to enforce password policy settings. When you implement a secure password policy, you may not need to implement the account lockout feature. Password Complexity Passwords, by default, can include any combination of characters; passwords can also be blank. Microsoft recommends that you require the use of complex passwords to help ensure that passwords provide the best security possible. These complex passwords are much more resistant to attack than blank or simple passwords. To enforce password complexity in your organization, you can enable the Password must meet complexity requirements security setting. The complexity requirements enforced by this setting are stored in Passfilt.dll. In Windows2000 operating systems and later, Passfilt.dll is built into the operating system. In WindowsNT Server4.0, you must add the Passfilt.dll file to the operating system to achieve the same results. Passfilt.dll is included in WindowsNT Server4.0 Service Pack2 and in later service packs. By default, complex passwords enforced by Passfilt.dll have the following properties: Do not contain all or part of the user's account name. Contain characters from three of the following four categories: English uppercase characters (A through Z). English lowercase characters (a through z). Base-10 digits (0 through 9). Non-alphanumeric (for example, !, $, #, %). extended ASCII, symbolic, or linguistic characters. NoteDepending on your environment, using extended ASCII, symbolic, or linguistic characters in passwords can have unexpected results. It is highly recommended that you test these characters before using them in production. When implementing this policy, it is recommended to inform your users of the change in policy so that a smooth transition can take place from a simple password to a complex password. Otherwise, users may be confused by the new password criteria and circumvent security to avoid the difficulty. You can create and register your own custom password filter if you want to modify the complexity requirements enforced in the security setting. For information about how to create a Passfilt.dll file, see "Password Filters" on the MSDN Web site|http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/password_filters.asp. Password History You can use the Password History setting to prevent users from repeatedly using the same password. When you use the password history feature, a user is prevented from using passwords that they used in the past, up to the number of passwords that you specify. You can configure Windows to retain between 0and 24passwords by using the Password History feature. Microsoft recommends that you set the password history to the maximum value to help ensure the least amount of password reuse by users. In the Windows2000 Server family and later, the location of the password history is in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Enforce Password History. Valid non-zero values are between1 and24. The default value is24 for domain controllers running a member of the Windows Server2003 family, 3for domain controllers running a member of the Windows 2000 family, and0 for all other Windows operating systems. Minimum Password Length You can use the Minimum Password Length setting to decrease the chances that a password can be discovered by a malicious user. For more information about the Minimum Password Length setting, see "Understanding Password Complexity" in this document. In versions of Windows2000 operating systems and later, you can change the Minimum Password Length setting in the Group Policy MMC, in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum Password Length. An administrator can set the value between 0and 14characters. Each additional character increases the total possible password permutations. However, if you set the value to0, blank passwords are not permitted. Valid non-zero values are between 1and 14, with a default value of zero. Maximum Password Age You can use the Maximum Password Age setting to limit the time for which a given password is valid. This decreases the odds of being able to crack a password. For more information, see the example in the Passwords section in this document. In the Windows2000 family and later, the Maximum Password Age setting is located in the Group Policy MMC, in the Default Domain policy at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Maximum Password Age. This setting determines the period of time (in days) that a user can use their password before the computer requires the user to change it. You can set passwords to expire in between 1and 999days, or you can specify that passwords never expire by setting the number of days to0. Valid non-zero values are between1 and999, with a default value of42. Minimum Password Age You can use the Minimum Password Age setting to preventing users from repeatedly changing passwords until the user is able to use their original password, if you enforce the Password History setting. When you use the Minimum Password Age setting, you prevent the circumvention of password expiration and help to assure unique passwords. The Minimum Password Age setting determines the period of time (in days) that a password must be used before the user can change it. You can set the value to between 1and 999days, or allow immediate changes by setting the number of days to0. Configure the Minimum Password Age setting to be a number that is larger than0 if you want the Enforce Password History setting to be effective. If you do not set a minimum password age, users can repeatedly cycle through passwords until they are able to use an old favorite password. This could allow users to circumvent established password policy. The Minimum Password Age setting is located in the Group Policy MMC, in Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy. Valid non-zero values are between1 and999, with a default value of one for domain controllers and zero for other computers. Account Lockout Settings You can set the Account Lockout settings in the Active Directory Users and Computers MMC by using the procedure in this section. NoteThe value that you set for LockoutDuration cannot be a value that is less than OberservationWindow. Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers. In the console tree, right-click the domain on which you want to set a Group Policy object. Click Properties, and then click the Group Policy tab. In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit. In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then click Account Lockout Policy. In the details pane, right-click the policy setting that you want, and then click Properties. If you are defining this policy setting for the first time, click Define this policy setting. Click the options that you want, and then click OK. ObservationWindow The ObservationWindow setting (also known in Group Policy as the Reset account lockout counter after setting) is the number of minutes after which an accounts badPwdCount registry value is reset. You can use the ObservationWindow setting to help mitigate lockout issues that are initiated by users. When you enable this setting, the bad password attempt is removed from the server after a period of time. Valid non-zero values are between 1and 99999, with a default value of 30. LockoutDuration The LockoutDuration setting (also known in Group Policy as the Account lockout duration setting) is the amount of time, in minutes, that account lockout is enforced on an account that has exceeded the LockoutDuration registry value, measured from the time of lockout. If you set the LockoutDuration registry value to0, the account is permanently locked out until either an administrator or a user who has a delegated account resets the account. If the administrator or a delegated user account does not unlock the account, the operating system unlocks the account after the number of minutes that you set in the LockoutDuration registry value. Non-zero values for the LockoutDuration registry value reduce the administrative overhead of unlocking accounts by having them unlocked automatically; however, non-zero values do not provide the added security of user validation before the account is restored. Valid non-zero values are between 1 and 99999, with a default value of 30. LockoutThreshold The LockoutThreshold setting (also known in Group Policy as the Account lockout threshold setting) is the number of times that the user, computer, service, or program can send a bad password during logon authentication before the account is locked out. Account lockout occurs when the badPwdCount registry value is equal to or exceeds the LockoutThreshold value. You can adjust the LockoutThreshold value to prevent both brute force and dictionary attacks, but you can set the value too low to capture user error and other non-attack errors. Administrators often set this value too low (3through5), which causes a large number of account lockouts because of user error, program caching by service accounts, or issues with networking clients. If you set the LockoutThreshold value to0, no account lockouts occur on the domain. Valid non-zero values are between 1 and 999, with a default value of zero. Account Lockout Values Account lockout registry values are described in this section. These values store the information that you need to track account lockout information. NoteThese values are maintained by the operating system, so you should not manually modify them. badPasswordTime The badPasswordTime value stores the last time that the user, computer, or service account submitted a password that did not match the password on the authenticating domain controller This property is stored locally on each domain controller that is in the domain. A value of0 means that the last incorrect password time is unknown. For an accurate value for the user's last incorrect password time in the domain, you must query each domain controller that is in the domain; the largest one is the accurate value. For more information, see the "LockoutStatus.exe" section in this document. NoteThe badPasswordTime registry value is not replicated between domain controllers. This attribute, however, is reported to the PDC operations master. badPwdCount The badPwdCount value stores the number of times that the user, computer, or service account tried to log on to the account by using an incorrect password. This value is maintained separately on each domain controller in the domain, except for the PDC operations master of the accounts domain that maintains the total number of incorrect password attempts. A value of0 indicates that the value is unknown. For an accurate total of the user's incorrect password attempts in the domain, you must query each domain controller and use the sum of the values. For more information, see the "LockoutStatus.exe" section in this document. NoteThe badPwdCount registry value is not replicated between domain controllers. This registry value, however, is reported to the PDC operations master. ntPwdHistory The ntPwdHistory registry value contains the password history for the user in WindowsNT Server4.0 one-way function (OWF). Both Windows2000 and the Windows Server2003 family use the WindowsNT Server4.0 OWF. This property is used by only the operating system. Note that you cannot obtain the password from the password in OWF form. Other Settings That Affect Account Lockout This section describes another setting that affect account lockout behavior. While the setting is focused on authentication, it is closely tied with account lockout policy. You can set the authentication settings in the Active Directory Users and Computers MMC by using the procedure in this section. Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers. In the console tree, right-click the domain on which you want to set a Group Policy object. Click Properties, and then click the Group Policy tab. In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit. In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Security Options. In the details pane, right-click the policy setting that you want, and then click Properties. If you are defining this policy setting for the first time, click Define this policy setting. Click the options that you want, and then click OK. ForceUnlockLogon The ForceUnlockLogon setting (also known as Interactive logon: Require Domain Controller authentication to unlock workstation controls the behavior of a computer running Windows2000, WindowsXP or the Windows Server2003 family when the computer is unlocked by a user. With a value of 1 (or Enabled, in Group Policy), unlocking the computer also performs a synchronous logon to the domain to verify user authenticity. This option is slower than allowing cached authentication because it requires network-based authentication. With a value of 0 (or Disabled, in Group Policy), cached information is used to verify the users identity. When the verification is successful, the user is logged on. Windows then performs an asynchronous logon to the domain in the background. This means that the user can still unlock a computer when the account is unlocked. Valid values are 0 and 1, with a default value of 0. For additional information about unlocking a workstation, see the following articles: "Information About Unlocking a Workstation" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=281250. "Screensaver Password Works Even If Account Is Locked Out" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=188700. Replication and Account Lockout Account lockout relies on the replication of lockout information between domain controllers to ensure that all domain controllers are notified of an accounts status. In addition, password changes must be communicated to all domain controllers to ensure that a users new password is not considered incorrect. This data replication is accomplished by the various replication features of Active Directory and is also discussed in this section. Immediate Replication When you change a password, it is sent over Netlogon's secure channel to the PDC operations master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC operations master that includes the user name and new password information. The PDC operations master then locally stores this value. Immediate replication between Windows2000 domain controllers is caused by the following events: Lockout of an account Modification of a Local Security Authority (LSA) secret State changes of the Relative ID (RID) Manager Urgent Replication Active Directory replication occurs between domain controllers when directory data is updated on one domain controller and that update is replicated to all other domain controllers. When a change in directory data occurs, the source domain controller sends out a notice that its directory store now contains updated data. The domain controller's replication partners then send a request to the source domain controller to receive those updates. Typically, the source domain controller sends out a change notification after a delay. This delay is governed by a notification delay. (The Windows2000 default notification delay is 5minutes; the Windows Server2003 default notification delay is 15seconds.) However, any delay in replication can result in a security risk for certain types of changes. Urgent replication ensures that critical directory changes are immediately replicated, including account lockouts, changes in the account lockout policy, changes in the domain password policy, and changes to the password on a domain controller account. With urgent replication, an update notification is sent out immediately, regardless of the notification delay. This design allows other domain controllers to immediately request and receive the critical updates. Note, however, that the only difference between urgent replication and typical replication is the lack of a delay before the transmission of the change notification. If this does not occur, urgent replication is identical to standard replication. When replication partners request and subsequently receive the urgent changes, they receive, in addition, all pending directory updates from the source domain controller, and not only the urgent updates. When either an administrator or a delegated user unlocks an account, manually sets password expiration on a user account by clicking User Must Change Password At Next Logon, or resets the password on an account, the modified attributes are immediately replicated to the PDC emulator operations master, and then they are urgently replicated to other domain controllers that are in the same site as the PDC emulator. By default, urgent replication does not occur across site boundaries. Because of this, administrators should make manual password changes and account resets on a domain controller that is in that user's site. The following events are not urgent replications in Windows2000 domains: Changing the account lockout policy Changing the domain password policy Changing the password on a computer account Domain trust passwords For additional information about urgent and immediate replication, see "Urgent Replication Triggers in Windows2000" in the Microsoft Knowledge Base |http://support.microsoft.com/default.aspx?scid=kb;en-us;232690. Single User Object On Demand Replication In the Windows2000 family, when an administrator resets and immediately expires a user's password on a domain controller in siteA (so that the user is given a new password but forced to change it when the user first logs on), the logon may still succeed when the user logs on with that new password in siteB. This occurs because the domain controller chains to the PDC operations master during authentication. However, the users password change may not replicate correctly because domain controllers in siteB do not yet have the reset password. This occurs because there is replication latency between sites. An update is available for Windows2000 that changes this behavior. For more information to help change this behavior by implementing an "on-demand" replication scheme, see "You Cannot Change Your Password After an Administrator Resets It" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=812499. The updated replication scheme allows the domain controller to contact the PDC operations master to request an update of the user object that failed authentication because of an incorrect password. This helps to ensure that the authenticating domain controller receives the most current user account information as quickly as possible. Mixed Environments with WindowsNT Server4.0 and Active Directory Domain Controllers If servers that are running WindowsNT Server4.0 and earlier are in the domain, account lockout is not a dependable security feature. For example, a WindowsNT Server4.0, Enterprise Edition, backup domain controller (BDC) may authenticate a user, even though the account is marked as locked out on a domain controller that is running WindowsNT Server4.0 and earlier. Also, WindowsNT Server4.0, Enterprise Edition, BDCs cannot unlock an account. The server that is running WindowsNT Server4.0, Enterprise Edition, can increment the bad password count when the user logs in with an incorrect password. That server can then report the increment to the other domain controller. However, the WindowsNT Server4.0, Enterprise Edition, BDC does not send this information to the domain controller that is running WindowsNT Server4.0 and earlier if the user logs on with the correct password. Because of this, the bad password count is not reset after the successful logon attempt. The account lockout feature of Microsoft LAN Manager is not compatible with the account lockout feature on computers that are running WindowsNT Server4.0 and earlier. The domain controller that is running WindowsNT Server4.0 and earlier does not replicate any account lockout information to a LAN Manager BDC. If the account is marked as locked out on the WindowsNT Server4.0 and earlier domain controller, the LAN Manager BDC may still validate the user. The LAN Manager BDC displays the account lockout policy as set to "Never," even in a domain running WindowsNT Server4.0 and earlier where account lockout is enabled. For these reasons, you should consider ensuring that all domain controllers in your network are running Windows2000 or the Windows Server2003 family. This is the only way to ensure that account lockout is enforced consistently across your network. Maintaining and Monitoring Account Lockout After you configure the account lockout options that you want, set up the computers so that you can capture more data about the accounts that are being locked out. This section describes how to enable auditing, Netlogon logging, and Kerberos logging, as well as which computers to retrieve the logs from. After you configure the logging and capture the appropriate data, this section will show you how to analyze the information so that you can ensure account lockout settings are working and identify attacks. Enable Auditing at the Domain Level The following sections describe how to enable auditing at the domain level for different operating systems. To effectively troubleshoot account lockout, enable auditing at the domain level for the following events: Account Logon Events Failure Account Management Success Logon Events Failure Windows2000 and Windows Server2003 Domains The Audit Policy settings are located in the Default Domain policy settings. To view the Auditing policy settings, in the Group Policy MMC, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click Audit Policy. Enable auditing for the event types listed in the previous section. WindowsNT Server4.0 Domain Open User Manager, click Policies, click Auditing, enable Logon and Logoff auditing for failure events, and then enable User and Group Management auditing for success events. Settings for Event Logs For troubleshooting purposes, change some of the settings for the Security event logs: Set the maximum security log size to 10,000KB or more. This helps to ensure that important events are not overwritten when the log file becomes large in size. Set the event retention method to Overwrite events as needed to ensure that the computer is not shut down because there are too many Security event log entries, even when the log file becomes large in size. For information about how to change the size and retention method of the Security event log , see the Help documentation for the operating system with which you are working. Because the events can occur on both the client and the server, you can use the following tools to help you gather the information in a single location. Use the EventCombMT.exe tool, a multithreaded tool, to gather specific events from event logs from several different computers to one central location and then search those event logs for specific data of interest. Some specific search categories are built into the tool, such as account lockouts, which is already configured to include events 529, 644, 675, 676, and 681. For more information, see the Help file that is included with the tool. Use the Eventlog.pl tool to help you manage event logs in Windows2000. You can use this tool to change the properties of event logs, back up event logs, export event lists to text file, clear event logs, and query the properties of the event logs. For more information, see "HOW TO: Use the Event Log Management Script Tool (Eventlog.pl) to Manage Event Logs in Windows 2000" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=318763. Netlogon Logging You can use Netlogon logging to capture Netlogon and NTLM events. It is recommended that you configure Netlogon logging in a Windows2000 domain that has Windows2000 clients. You must configure Netlogon logging on the primary domain controller (PDC) and on any other domain controllers that are involved in user authentication. To determine the authenticating domain controller, at a command prompt, type set l or use the LockoutStatus.exe tool. For more information about the LockoutStatus.exe tool, see the "Account Lockout Tools" section in this document. For enterprises that have less then 10domain controllers, you should enable Netlogon logging on all domain controllers for each domain. Enabling Netlogon Logging on Computers Running Windows2000 Server To enable Netlogon logging on computers that are running Windows2000 Server, at a command prompt, type nltest /dbflag:2080ffff. The log file is created in Systemroot\Debug\Netlogon.log. If the log file is not in that location, stop and restart the Netlogon service on that computer. To do this, at a command prompt, type net stop netlogon & net start netlogon. For more information, see "Enabling Debug Logging for the Netlogon Service" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=109626. If free disk space is low, make sure there is enough space to allow the 40megabytes (MB) maximum space for the logging. You should also consider the disk space that Netlogon logging uses. When Netlogon.log reaches 20MB in size, it is renamed to Netlogon.bak and a new Netlogon.log is created with the latest Netlogon data. After that Netlogon.log reaches 20MB in size, Netlogon.bak is truncated, and the current Netlogon.log file is renamed to Netlogon.bak. Because of this process, the total disk space that is used by Netlogon logging is never more than 40MB. NotePerformance may be slightly degraded by the logging process. Therefore, you should disable Netlogon logging after you have captured the events that you want in the log file. To disable Netlogon logging, at a command prompt, type nltest /dbflag:0, press ENTER, type net start netlogon and then press ENTER. Kerberos Logging If account lockouts involve Kerberos clients that are running a member of the Windows2000 family or later, you can enable Kerberos logging on those client computers. You would typically perform this step after you have determined that there is an authentication issue that is related to Kerberos. To enable Kerberos event logging on a computer: Click Start, click Run, type regedit, and then press ENTER. Add the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters registry value to the registry key: Registry value: LogLevel Value type: REG_DWORD Value data: 0x1 If the Parameters registry key does not exist, create it. Close Registry Editor and restart the computer. CautionIncorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. NotePerformance may be degraded by the logging process. Therefore, you should disable the logging process after you capture the events that you want in the log file. To disable logging, remove the LogLevel registry value, and then restart the computer. You can automate this process by using the script that is in the "Account Lockout Tools" section in this document. This script sets the Kerberos logging key in the registry on client computers that are running Windows2000. If you want to enable logging for groups of computers, you can specify this script as a startup script in an Active Directory group policy. To disable Kerberos event logging on a computer: Click Start, click Run, type regedit, and then press ENTER. Delete the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel registry value. Close Registry Editor and restart the computer. CautionIncorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. For more information, see the "HOW TO: Enable Kerberos Event Logging" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=262177. Event and Netlogon Log Retrieval After you set the auditing and logging, wait until account lockouts occur. When the account lockout occurs, retrieve both the Security event log and the System event log, as well as the Netlogon logs for all of the computers that are involved with the client's lockout. This includes the PDC emulator operations master, the authenticating domain controller, and all of the client computers that have user sessions for the locked-out user. To determine the domain controllers that are involved with the lockout, run the LockoutStatus.exe tool and specify the user account that is locked out. This tool gathers and displays information about the specified user account from all the domain controllers in the domain. In addition, the tool displays the user's badPwdCount value on each domain controller. The domain controllers that have a badPwdCount value that reflects the bad password threshold setting for the domain are the domain controllers that are involved in the lockout. These domain controllers always include the PDC emulator operations master. The badPwdCount value may appear to be higher than the threshold because of the way that passwords are chained to the PDC emulator operations master. When a bad password is presented by a user or program, both the authenticating domain controller and the PDC emulator operations master increment their badPwdCount value for that account. When Active Directory replication occurs, this can result in an increased value. However, the end resultthe account becoming locked outremains the same. You can also use the EventCombMT.exe tool to gather specific event log data from multiple computers to one central location. For more information about both the EventCombMT.exe and LockoutStatus.exe tools, see the "Account Lockout Tools" section in this document. Analyzing Log File Information The previous section described the processes that you can use to enable log files to record information that is lockout-specific on your computers. This section focuses on analyzing those log files and determining what behavior occurred that created the log files and caused the issue that you are trying to resolve. This section also describes how to resolve the issues that you find when you analyze the log files. Analyzing Netlogon Log Files Before you start to analyze the Netlogon log files, you should be familiar with the authentication process works from previous sections in this paper. Although this section describes an NTLM authentication process, a similar chain of events occurs during Kerberos authentication. The following sample scenario discusses what occurs when a user who is on a client computer tries to gain accesses to a resource that is on a file server in the same domain as the user account. In this process: User credentials are passed to the file server. This is displayed in the Network Logon section in the Netlogon.log file. The file server tries to authenticate the user, but the file server has to forward the credentials to the authenticating domain controller for validation because this account is a domain user account. This behavior is displayed as Transitive Network logon in the Netlogon.log file and is commonly referred to as pass-through authentication. If the password is incorrect or if it is not the same as the password that is stored by the authenticating domain controller, the authenticating domain controller chains the credentials to the PDC for validation. This is displayed as Transitive Network Logon in the Netlogon.log file. Netlogon Log File Walkthrough The following sections provide a sample Netlogon.log file output from the following three computers: The PDC operations master for the domain: DC002 The authenticating domain controller: DC003 The member server: MEMSERVER01 The sample output sections show the following participants involved in network authentication: Domain name: Tailspintoys Logon user name: User1 Logon computer name: Computer-006 Transitive Network Logon (Pass-Through Authentication) Sample from the DC002 PDC emulator Netlogon log file: 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A 29-Mar 14:28:31 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC0000234 Sample from the DC003 authentication domain controller Netlogon log file: 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC000006A 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC000006A 29-Mar 14:28:31 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC000006A 29-Mar 14:28:31 Transitive Network logon Tailspintoys\User1 Computer-006 (via MEMSERVER01) 0xC0000234 Sample from the MEMSERVER01 member server Netlogon log file: 29-Mar 14:28:31 Network logon Tailspintoys\User1 Computer-006 0xC000006A 29-Mar 14:28:31 Network logon Tailspintoys\User1 Computer-006 0xC000006A 29-Mar 14:28:32 Network logon Tailspintoys\User1 Computer-006 0xC000006A 29-Mar 14:28:32 Network logon Tailspintoys\User1 Computer-006 0xC000006A 29-Mar 14:28:32 Network logon Tailspintoys\User1 Computer-006 0xC000006A 29-Mar 14:28:32 Network logon Tailspintoys\User1 Computer-006 0xC0000234 These Netlogon.log file samples provide an example of the information contained in the Netlogon logs. This information is used to trace the account lockout from the domain controller back to the member server on which a user or application tried to gain access with the incorrect credentials. Stepping Through the Netlogon Log File Sample This section describes the standard analysis process of log files when attempting to determine the cause of an account lockout issue. In most troubleshooting scenarios, you should begin your log file analysis by examining the Netlogon.log file on the PDC operations master. Because this is a transitive network logon, you can find the authenticating domain controller by viewing the "Via" line in the Netlogon.log file for the domain controller that is chaining logon to the PDC operations master. Sample from the PDC Emulator (DC002) Netlogon Log File On the "Via" line from the PDCs Netlogon.log file in the following example, note that the authentication is being chained from DC003. 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer006 (via DC003) 0xC000006A This is an illustration of step3 of the authentication process that was detailed in "Analyzing Netlogon Log Files" previously in this document. Sample from the Authentication Domain Controller (DC003) Netlogon Log File In the Netlogon log file on DC003, this authentication is still a transitive network logon, because credentials were sent to DC003 for verification. Because of this, note where the credentials are sent from. In this example, the credentials are being sent via MEMSERVER01": 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer006 (via MEMSERVER01) 0xC000006A This is an illustration of step2 of the authentication process that was detailed in "Analyzing Netlogon Log Files" previously in this document. The file server tries to authenticate the user, but the file server has to forward the credentials to the authenticating domain controller for validation because this is a domain user account. This is displayed as Transitive Network logon in the FileServername section of the Netlogon.log file. Sample from the Member Server (MEMSERVER01) Netlogon Log File From the Netlogon.log file on MEMSERVER01 from the same time period, verify the actual client computer name where the original logon or session setup request came from. In this example, the request came from Computer-006: 29-Mar 14:28:31 Network logon Tailspintoys\User1 Computer-006 0xC000006A This is an illustration of step1 of the authentication process that was detailed in "Analyzing Netlogon Log Files" previously in this document. User credentials are passed to the file server. This is displayed in the Network Logon section in the Netlogon.log file. Even though the log file does not display the exact process that is sending the incorrect credentials, Netlogon log files do provide the following information to help you troubleshoot the lockout: Netlogon output displays the number of unsuccessful logon attempts (0xC000006A) for a user's account in a certain time period. Logs in which there are several 0xC000006A events in one second indicate that the lockout is most likely caused by a process, program, or script that is sending incorrect credentials. Netlogon output provides a complete picture of all computers that are involved in the account lockout. You can narrow down the culprit by determining the common elements, such as programs, among the computers involved. For example, from the Netlogon output above, after you determined that MEMSERVER01 was common to all user lockouts, the troubleshooting focus changed to the particular network services or user accounts that are used by MEMSERVER01. In this example, MEMSERVER01 is the Microsoft Exchange server. After you examine the Microsoft Outlook client and Exchange server settings, you may want to use the information that is in the following two articles to help resolve the issue. These articles describe how to remove unnecessary RPC bindings from the Exchange server. For example, remove Named Pipe support if there is no client that requires the named pipes. "Outlook Locks Your Account Because of a Directory Service Referral with Exchange 2000 Server" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=291598. "Unexpected Account Lockouts Caused When Logging On to Outlook from an Untrusted Domain" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=276541. If the Netlogon logs from all domain controllers from the time of lockout but do not display data that pertains to any of the locked-out user accounts that you are analyzing, then NTLM authentication is not involved in the lockouts. This normally indicates that the authentication issues are between computers running Windows2000 or later, because earlier versions of Windows used NTLM authentication exclusively. You should focus on Kerberos authentication troubleshooting by using Kerberos logging and examining the Security event logs. Netlogon Log File Error Codes Each event in the Netlogon log contains a corresponding error code. The following table describes these error codes. Table 3 Netlogon Log Error Codes Log CodeDescription0x0Successful login0xC0000064The specified user does not exist0xC000006AThe value provided as the current password is not correct0xC000006CPassword policy not met0xC000006DThe attempted logon is invalid due to a bad user name0xC000006EUser account restriction has prevented successful login0xC000006FThe user account has time restrictions and may not be logged onto at this time0xC0000070The user is restricted and may not log on from the source workstation0xC0000071The user account's password has expired0xC0000072The user account is currently disabled0xC000009AInsufficient system resources0xC0000193The user's account has expired0xC0000224 User must change his password before he logs on the first time0xC0000234 The user account has been automatically lockedNoteMany of these codes provide information in the log file that is redundant with the corresponding Netlogon event log. This allows you to analyze the events in a variety of ways. Frequently Asked Questions This section answers common questions that might be helpful in troubleshooting the Account Lockout feature in the Windows Server2003 family. Do the logon attempts happen seconds apart or are there many invalid logon attempt events (error code 0xC000006A) in the same second? The pattern shows whether this is a user error or a process or program that is creating the lockout. Users take several seconds between events, however, a process or program typically register many invalid or unsuccessful logon attempt events in one second. NoteYou can use the NLParse.exe tool to parse Netlogon logs for specific events that are related to account lockout, such as events 0xC000006A and 0xC0000234. The parsed data is sent to a .csv file that you can read by using a program like Microsoft Excel. For more information about NLParse, see the "Account Lockout Tools" section in this document. From which computers are the invalid logon attempt events generated? When you review the Netlogon logs and event logs, you can isolate from which computer the user was logged on during the account lockouts. In many situations, you will discover that a user is logged onto multiple computers; after the user changes their password on one computer, the user account is locked out. What client computers are displayed in the Netlogon log files? If only Windows98 or Windows95 clients are locked out, you may need to install the directory service client for those clients. For example, below, the Computer-006 computer generates the invalid logon attempt event: 29-Mar 14:28:30 Transitive Network logon Acme\User1 Computer-006 (via DC003) 0xC000006A Which user accounts are associated with the invalid logon attempt events? If privileged accounts (such as the administrator, service accounts, and well-known application account names) are receiving a large number of incorrect password attempts, first review the information for the computers that have made the attempts with the incorrect passwords, and then determine if there is a wrong password for the account. After you do this, if the passwords on all of the accounts are reset and incorrect password attempts persist, perform a trace to determine if the computer is under an attack. You can place an event trigger to stop the trace and determine where the attempt may be coming from. Internal or external computers can be a threat if there are worm viruses or compromises. The following example shows that the 0xC000006A error code is generated from the Tailspintoys\User1 user: 29-Mar 14:28:30 Transitive Network logon Tailspintoys\User1 Computer-006 (via DC003) 0xC000006A Is there an obvious pattern to the invalid logon attempt events and account lockouts? Pattern: All users on the domain are locked out, including users who did not change their password. There are many unsuccessful authentication attempts per second. Possible Solution: If you determine that the log files show that most or all of the user accounts are locked out in your domain, you must perform a trace to determine whether the source of the attack is internal or external to your network. If the attack appears to come from a internal computer, examine the processes running on these computers as this likely indicates a common process that uses outdated or incorrect credentials. Attacks from outside your network often indicate denial of service or brute force attacks against your user accounts. Pattern: Alphabetical list of users in the log files. Possible Solution: If the log files show that all of the user accounts are locked out in a list that is almost alphabetical, it is most likely that this behavior is caused by an attempt to break passwords or a denial of service attack. You must perform a network trace to the source of the attack. Pattern: A specific number of logon attempts are made on each locked-out account. Possible Solution: If you determine that the log files display a specific number of logon attempts for a each user, add the number of occurrences of 0xC000006A and 0xC0000234 errors for the user. In some scenarios, you may see a pattern of a specific number of attempts for one user, and then the same number of attempts for another user, and so on. This behavior may be an attack on the network or a program could be sending a specific set of attempts. 16or 17attempts per user is a common figure for these types of attacks. In most account lockout situations, you must use Netlogon log files to determine which computers are sending bad credentials. When you analyze Netlogon log files, look for the 0xC000006A event code, because this event will help you determine where the bad password attempts began to occur. When you see the 0xC000006A event code and it is followed by a 0xC0000234 event code, the event codes that come after these event codes help you determine what caused the account lockout. If you see patterns in the log files, the patterns can help you determine if the event code was logged because of either a program attack or user error. Analyzing Event Logs You cannot determine the authentication type that was used when an account is locked out unless you enable Netlogon logging before the account lockout. However, because of differences in authentication, there may be situations in which Netlogon logging does not capture the data that you need to determine which computers were involved in an account lockout. Configuring the appropriate computers to create event logs may provide additional information in these situations. Before the problems occur, you should enable security auditing and Kerberos logging on all computers that might be involved in the account lockout event. Enabling auditing and Netlogon log files is discussed elsewhere in this document. If the auditing is not configured before the initial error occurs, it can be done afterwards. Once the account lockout occurs, there are several tasks that should be completed to help identify the cause of the issue: Obtain both the Security and System event logs from all of the computers that are locked out if those computers were logged on when the lockout occurred. Also, obtain these log files from the PDC emulator operations master and all domain controllers that may be involved in the account lockout. Look for Event675 (Preauthentication Failures) in the Security event log for the domain controllers for the locked-out user account. This event displays the IP address of the client computer from which the incorrect credentials were sent. When you view these events in the Security event log from the PDC, an IP address with Event675 may be the IP address of another domain controller because of password chaining from other domain controllers. If this is true, obtain the Security event log from that domain controller to see the Event675. The IP address that is listed in that Event675 should be the IP address for the client computer that sent the invalid credential. After you know which client computer is sending the invalid credentials, determine the services, programs, and mapped network drives on that computer. If this information does not reveal the source of the account lockout, perform network traces from that client computer to isolate the exact source of the lockout. NoteYou can use the EventCombMT.exe tool to gather event log dates from different domain controllers at the same time. For more information about EventCombMT.exe, see the Account Lockout Tools section in this document. For more information, see the following articles: "Windows 2000 Security Event Descriptions (Part 1 of 2)" in the Microsoft Knowledge Base|(http://support.microsoft.com/?id=299475. "Windows 2000 Security Event Descriptions (Part 2 of 2) in the Microsoft Knowledge Base|http://support.microsoft.com/?id=301677. Example event log entry: incorrect password processed by Kerberos The following example displays a sample Event675 in the Security event log from the PDC emulator operations master: Event Type: Failure Audit Event Source: Security Event Category: Account Logon Event ID: 675 Date: 12/5/2001 Time: 5:47:26 PM User: NT AUTHORITY\SYSTEM Computer: COMPUTER-006 Description: Pre-authentication failed: User Name: user1 User ID: %{S-1-5-21-4235101579-1759906425-16398432-1114} Service Name: krbtgt/Tailspintoys.com Pre-Authentication Type: 0x2 Failure Code: 0x18 Client Address: 172.16.1.85 In this example, failure code 0x18 is listed because an incorrect user name or password was used. The client address of 172.16.1.85 identifies the network client that caused this failure. The user name "user1" is also included in this event. The client address and user name should provide enough information for you to begin to address the issue, because you know which user is attempting to logon from which computer. Example event log entry: Account is locked out The following example displays a sample of Event644, which indicates that the account is locked out: Event Type: Success Audit Event Source: Security Event Category: Account Management Event ID: 644 Date: 12/5/2001 Time: 5:47:26 PM User: Everyone Computer: COMPUTER-006 Description: User Account Locked Out: Target Account Name: user1 Target Account ID:%{S-1-5-21-4235101579-1759906425-16398432-1114} Caller Machine Name:COMPUTER-006 Caller User Name:USER1$ Caller Domain:TAILSPINTOYS Caller Logon ID:(0x0,0x3E7) For more information on account lockout events, see "Audit Account Lockout" on the Microsoft TechNet Web site|http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/516.asp. Example event log entry: Logon failure The following example displays a sample of Event529, which results from an unsuccessful logon attempt due to an invalid user name or password. This event is often useful in identifying the source of the lockout: Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 529 Date: 12/21/2001 Time: 2:05:20 PM User: NT AUTHORITY\SYSTEM Computer: COMPUTER-006 Description: Logon Failure: Reason: Unknown user name or bad password User Name: user1 Domain: Tailspintoys Logon Type: 2 Logon Process: User32 Authentication Package: Negotiate Workstation Name: COMPUTER-006 This event contains several useful elements. It identifies the name of the computer that is attempting authentication, as well as the user and domain name. It also displays the logon type, which is discussed later in this section. When Event529 is logged, you should look for patterns in the event. Determine if there are several 529 events logged and determine if they all occur in one second or if they occur at specific time intervals. If so, there is a process or service that is running on the computer that is sending incorrect credentials. Look at the Logon Process and Logon Type entries in the log to determine the type of process that is passing incorrect credentials and to determine how the process is logging on. Example event log entry: Account Is Disabled When there is an attempt to logon using a disabled account, a specific event is created in the event log. This can help you quickly identify intruders, because normal operations should not allow for the use of locked out accounts. You should analyze and respond quickly to these events. Event Type: Failure Audit Event Source: Security Event Category: Logon/Logoff Event ID: 531 Date: 12/21/2001 Time: 2:05:21 PM User: NT AUTHORITY\SYSTEM Computer: COMPUTER-006 Description: Logon Failure: Reason: Account currently disabled User Name: user1 Domain: TAILSPINTOYS Logon Type: 2 Logon Process: User32 Authentication Package: Negotiate Kerberos Events Logged During an Account Lockout Once Kerberos logging is enabled, certain events will be logged when an account lockout occurs. These events are described in this section. Incorrect Password This event is logged when an incorrect password is received by Kerberos as part of an authentication request. Event Type: Error Event Source: Kerberos Event Category: None Event ID: 4 Date: 12/21/2001 Time: 2:02:05 PM User: N/A Computer: COMPUTER-006 Description: The function LogonUser received a Kerberos Error Message: on logon session TAILSPINTOYS\user1 Client Time: Server Time: 19:2:5.0000 12/21/2001 (null) Error Code: 0x18 KDC_ERR_PREAUTH_FAILED Client Realm: Client Name: Server Realm: TAILSPINTOYS.COM Server Name: krbtgt/TAILSPINTOYS.COM Target Name: krbtgt/TAILSPINTOYS@TAILSPINTOYS Error Text: File: Line: Error Data is in record data. Kerberos Event When a User Account Is Locked Out This event is logged when Kerberos is used for authentication and an account lockout occurs. Event Type: Error Event Source: Kerberos Event Category: None Event ID: 4 Date: 12/21/2001 Time: 2:05:21 PM User: N/A Computer: COMPUTER-006 Description: The function LogonUser received a Kerberos Error Message: on logon session TAILSPINTOYS\user1 Client Time: Server Time: 19:5:21.0000 12/21/2001 (null) Error Code: 0x12 KDC_ERR_CLIENT_REVOKED Client Realm: Client Name: Server Realm: TAILSPINTOYS.COM Server Name: krbtgt/TAILSPINTOYS.COM Target Name: krbtgt/TAILSPINTOYS@TAILSPINTOYS Error Text: File: Line: Error Data is in record data Logon Events Many different events can be created by various logon and logoff actions. The following table describes each logon event. Table 4Logon Event IDs Event IDDescription528A user successfully logged on to a computer. For information about the type of logon, see the Logon Types table below.529Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password.530Logon failure. A logon attempt was made, but the user account tried to log on outside of the allowed time.531Logon failure. A logon attempt was made using a disabled account.532Logon failure. A logon attempt was made using an expired account.533Logon failure. A logon attempt was made by a user who is not allowed to log on at this computer.534Logon failure. The user attempted to log on with a type that is not allowed.535Logon failure. The password for the specified account has expired.536Logon failure. The Netlogon service is not active.537Logon failure. The logon attempt failed for other reasons. Note:In some cases, the reason for the logon failure may not be known.538The logoff process was completed for a user.539Logon failure. The account was locked out at the time the logon attempt was made.540A user successfully logged on to a network.541Main mode Internet Key Exchange (IKE) authentication was completed between the local computer and the listed peer identity (establishing a security association), or quick mode has established a data channel.542A data channel was terminated.543Main mode was terminated. Note:This might occur as a result of the time limit on the security association expiring, policy changes, or peer termination. (The default expiration time for security associations is eight hours.)544Main mode authentication failed because the peer did not provide a valid certificate or the signature was not validated.545Main mode authentication failed because of a Kerberos failure or a password that is not valid.546IKE security association establishment failed because the peer sent a proposal that is not valid. A packet was received that contained data that is not valid.547A failure occurred during an IKE handshake.548Logon failure. The security identifier (SID) from a trusted domain does not match the account domain SID of the client. 549Logon failure. All SIDs that correspond to untrusted namespaces were filtered out during an authentication across forests.550A denial-of-service attack may have taken place.551A user initiated the logoff process.552A user successfully logged on to a computer using explicit credentials while already logged on as a different user.672An authentication service (AS) ticket was successfully issued and validated.673A ticket-granting service (TGS) ticket was granted.674A security principal renewed an AS ticket or TGS ticket.675Preauthentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password.676Authentication ticket request failed. This event is not generated in WindowsXP or in the Windows Server2003 family.677A TGS ticket was not granted. This event is not generated in WindowsXP or in the Windows Server2003 family. 678An account was successfully mapped to a domain account.681Logon failure. A domain account logon was attempted. This event is not generated in WindowsXP or in the Windows Server2003 family. 682A user has reconnected to a disconnected terminal server session.683A user disconnected a terminal server session without logging off. Note:This event is generated when a user is connected to a terminal server session over the network. It appears on the terminal server.Netlogon Logon Types When many Netlogon logon events are logged, a logon type is also listed in the event details. The following table describes each logon type. Table 5Netlogon Logon Types Logon typeLogon titleDescription2InteractiveA user logged on to this computer.3NetworkA user or computer logged on to this computer from the network.4BatchThe batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.5ServiceA service was started by the Service Control Manager.7UnlockThis workstation was unlocked.8NetworkCleartextA user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext). 9NewCredentialsA caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.10RemoteInteractiveA user logged on to this computer remotely using Terminal Services or Remote Desktop.11CachedInteractiveA user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.Troubleshooting Account Lockout In an environment where you set the account lockout feature, you may notice a large number of lockouts that occur. To determine if these lockouts are false lockouts or a real attack: Verify that the domain controllers and client computers are up-to-date with service packs and hotfixes. For more information, see the "Recommended Service Packs and Hotfixes" section in this document. Configure your computers to capture data: Enable auditing at the domain level. Enable Netlogon logging. Enable Kerberos logging. For more information, see the "Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues" section in this document. Analyze data from the Security event log files and the Netlogon log files to help you determine where the lockouts are occurring and why. Analyze the event logs on the computer that is generating the account lockouts to determine the cause. For more information, see the Account Lockout Tools section in this document. The following section further describes the account lockout troubleshooting process. Common Causes for Account Lockouts This section describes some of the common causes for account lockouts The common troubleshooting steps and resolutions for account lockouts are also described in this section. To avoid false lockouts, check each computer on which a lockout occurred for the following behaviors: Programs: Many programs cache credentials or keep active threads that retain the credentials after a user changes their password. Service accounts: Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the security control manager to use the new password and avoid future account lockouts. Bad Password Threshold is set too low: This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry invalid passwords. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing Account Lockout Settings for Your Deployment" in this document. User logging on to multiple computers: A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log off and back on. NoteCommuters running WindowsXP or a member of the Windows Server2003 family automatically detect when the users password has changed and prompt the user to lock and unlock the computer to obtain the current password. No logon and logoff is required for users using these computers. Stored user names and passwords retains redundant credentials: If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information on Stored User Names and Passwords, see online help in WindowsXP and the Windows Server2003 family. NoteComputers that are running Windows95, Windows98, or Windows Millennium Edition do not have a Stored User Names and Passwords file. Instead, you should delete the users .pwl file. This file is named Username.pwl, where Username is the users logon name. The file is stored in the Systemroot folder. Scheduled tasks: Scheduled processes may be configured to using credentials that have expired. Persistent drive mappings: Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, type net use /persistent:no. Alternately, to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive. Active Directory replication: User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should verify that proper Active Directory replication is occurring. Disconnected Terminal Server sessions: Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information. A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that the source of the lockout comes from a single computer that is running Terminal Services. Service accounts: By default, most computer services are configured to start in the security context of the Local System account. However, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account. NoteYou can use the System Information tool to create a list of services and the accounts that were used to start them. To start the System Information tool, click Start, click Run, type winmsd, and then click OK. Other Potential Issues Some additional considerations regarding account lockout are described in the following sections. Account Lockout for Remote Connections The account lockout feature that is discussed in this paper is independent of the account lockout feature for remote connections, such as in the Routing and Remote Access service and Microsoft Internet Information Services (IIS). These services and programs may provide their own unrelated account lockout features. Internet Information Services By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache. For more information, see "Mailbox Access via OWA Depends on IIS Token Cache" in the Microsoft KnowledgeBase|http://support.microsoft.com/?id=173658. MSN Messenger and Microsoft Outlook If a user changes their domain password through Microsoft Outlook and the computer is running MSN Messenger, the client may become locked out. To resolve this behavior, see "MSN Messenger May Cause Domain Account Lockout After a Password" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=328867. Account Lockout Tools After you determine the pattern for the account lockouts and narrow down your scope to a specific client computer or member server, you should gather detailed information about all of the programs and services that are running on that computer. Some of the information that you should obtain includes: Mapped network drives Logon scripts that map network drives RunAs shortcuts Accounts that are used for service account logons Processes on the client computers Programs that may pass user credentials to a centralized network program or middle-tier application layer The following sections discuss the tools that you can use to help you gather information from the network environment. The LockoutStatus.exe Tool The LockoutStatus.exe displays information about a locked out account. It does this by gathering account lockout-specific information from Active Directory. The following list describes the different information that is displayed by the tool: DC Name: Displays all domain controllers that are in the domain. Site: Displays the sites in which the domain controllers reside. User State: Displays the status of the user and whether that user is locked out of their account. Bad Pwd Count: Displays the number of bad logon attempts on each domain controller. This value confirms the .domain controllers that were involved in the account lockout. Last Bad Pwd: Displays the time of the last logon attempt that used a bad password. Pwd Last Set: Displays the value of the last good password or when the computer was last unlocked. Lockout Time: Displays the time when the account was locked out. Orig Lock: Displays the domain controller that locked the account (the domain controller that made the originating write to the LockoutTime attribute for that user). Where to Obtain the LockoutStatus.exe Tool LockoutStatus.exe is included with the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the LockoutStatus.exe Tool To install the LockoutStatus.exe tool, install the ALTools package on your domain controller.. How to Use the LockoutStatus.exe Tool To run the LockoutStatus.exe tool and display information about a locked out user account: Double-click LockoutStatus.exe. On the File menu, click Select target. Type the user name whose lockout status on the enterprise's domain controllers you want information about. The following figure displays an example where two domain controllers have a badPwdCount value of5, which is also the bad password threshold. One domain controller is the PDC operations master, and the other domain controller is the authenticating domain controller. These two domain controllers are displayed because of password chaining from the authenticating domain controller to the PDC. Figure2 The LockoutStatus.exe Tool  The ALockout.dll Tool The ALockout.dll tool and the Appinit.reg script are included in the ALTools package. ALockout.dll is a logging tool that may help you determine the program or process that is sending the incorrect credentials in an account lockout scenario. The tool attaches itself to a variety of function calls that a process might use for authentication. The tool then saves information about the program or process that is making those calls into the Systemroot\Debug\Alockout.txt file. The events are time stamped so that you can match them to the events that are logged in either the Netlogon log files or the Security event log files. You can use Appinit.reg to initialize the .dll file. This file provides no other functionality. NoteMicrosoft does not recommend that you use this tool on servers that host network programs or services. You should not enable ALockout.dll on Exchange servers because the ALockout.dll tool may prevent the Exchange store from starting. ImportantBefore you install the ALockout.dll tool on any mission-critical computer, make a full backup copy of the operating system and any valuable data. For more information, see "Errors Installing Exchange Server with CleanSweep" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=164431. In most account lockout scenarios, you should install ALockout.dll on client computers. Use the information that is stored in both the Netlogon log file and the Security event log to determine the computers from which the incorrect credentials are being sent that are locking out the user's account. When you install the ALockout.dll tool on the client computer that is sending the incorrect credentials, the tool logs the process that is sending the incorrect credentials. Where to Obtain the ALockout.dll Tool ALockout.dll is included with the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the ALockout.dll Tool There two versions of the ALockout.dll file. One version of the file is for computers that are running a Windows2000 operating system, and the other version of the file is for computers that are running a WindowsXP operating system. View the Readme.txt file that is included with the ALTools package. To install ALockout.dll: On the computer that has generated account lockout error messages in the Security event log, copy both the ALockout.dll and Appinit.reg files to the Systemroot\System32 folder . Double-click the Appinit.reg file to run the script. When you do this, the ALockout.dll file is registered and can begin providing information. Restart the computer to complete the installation. How to Remove the ALockout Tool To remove the ALockout.dll file from the computer: Delete the ALockout.dll file from the Systemroot/System32 folder. At a command prompt, type regsvr32 /u alockout.dll. Delete the Alockout.dll value that is under the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_DLLs After you delete the Alockout.dll value, the AppInit_DLLs registry key is blank. Restart the computer. How to Use the ALockout.dll Tool You should use the ALockout.dll tool with Netlogon logging and security auditing. To use the ALockout.dll tool: Wait for an account to lock out on the computer. When an account is locked out, the ALockout.txt file is created in the Systemroot\Debug folder. Compare event time stamps in ALockout.txt with the time stamps in both the Netlogon log files and the Security event log files. When you do this, you can determine the process that is causing the lockouts. You can use the ALockout.dll tool if you have already set up Netlogon logging, as well as Kerberos and logon auditing on the local computer. ALockout.dll does not interfere with any other logging or event generation. The ALoInfo.exe Tool If account lockouts seem to happen most frequently after a user is forced to change their password, you may want to determine which users' passwords are about to expire. You can use the ALoInfo.exe tool to display all user account names and the password age for those user accounts. This will allow you to use the ALockout.dll tool and other account lockout tools to set up the tools prior to the initial account lockout. You can also obtain a list of all local services and startup account information by using the ALoInfo.exe tool. NoteYou can also use the SecDump tool to display password expiration information in a WindowsNT Server4.0 domain. You can download this tool from the SystemTools Web site|http:// HYPERLINK "http://www.somarsoft.com" www.somarsoft.com. Note that Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here. Where to Obtain the ALoInfo.exe Tool The ALoInfo.exe file is included with the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the ALoInfo.exe Tool To install the ALoInfo.exe tool, install the ALTools package on your domain controller. The ALTools package contains the ALoInfo.exe tool. How to Use the ALoInfo.exe Tool You can use ALoInfo.exe at a command prompt with either of the following methods: To display an accounts password ages from a domain controller, at a command prompt, type the following: aloinfo /expires /server:Domain_Controller_Name To display all local service startup account information and mapped drive information for a user who is currently logged on, at a command prompt, type the following command: aloinfo /stored /server:Computer_Name You can redirect the output of ALoInfo.exe to a text file and then sort the results to determine which users may be involved in the account lockout. This information can also be stored for later analysis. The AcctInfo.dll Tool You can use the AcctInfo.dll tool to add new property pages to user objects in the Active Directory Users and Computers MMC Snap-in. You can use these property pages to help isolate and troubleshoot account lockouts and to reset a users password on a domain controller in that user's local site. AcctInfo.dll displays the following user account information that you may be able to use to identify and resolve account lockout issues: Last time the password was set When the password will expire User Account Control Raw Value and Decode Time the account was locked out If the account is locked out now, when it will be unlocked Security identifier (SID) of the account, and its SIDHistory Globally unique identifier (GUID) of the account These account properties: Last Logon Last Logoff Last Bad Logon Time Logon Count Bad Password Count You can also use the AcctInfo.dll tool to obtain the domain password information (expiration, lockout time, and so on). You can type the user's computer name in the tool, and then reset the user's password on a domain controller in that user's site. Note Because of replication latency, domain controllers may store different information about the same user account. AcctInfo.dll displays information that is retrieved from a single domain controller. Where to Obtain the AcctInfo.dll Tool The AcctInfo.dll tool is included in the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the AcctInfo.dll Tool On the computer where you want to run Active Directory Users and Computers MMC Snap-in: Copy the AcctInfo.dll file to the System32 folder. At a command prompt, type regsvr32 acctinfo.dll, and then press ENTER. The AcctInfo.dll file is registered and is displayed on a user's property sheet in the Active Directory Users and Computers MMC Snap-in after you follow these steps. To use the Account Lockout Status button in the tool, verify that LockoutStatus.exe is in the Systemroot\System32 folder. If LockoutStatus.exe is not installed in this location, this button is unavailable. How to Use the AcctInfo.dll Tool To use the AcctInfo.dll tool, open the Active Directory Users and Computers MMC, right-click a user, click Properties, and then click Additional Account Info. An example of the information that is provided by AcctInfo.dll is shown in the following figure. Figure3 Main Property Box  The following figure displays the domain password policy information that you can view to determine the password policy that applies to the domain controller. Figure4 Domain Password Policy  Change Password on a Domain Controller in the User's Site The AcctInfo.dll tool allows you to increase the functionality of the Active Directory Users and Computers MMC by adding the ability to reset a user's password in that user's local site. When you reset the password in the remote site, you avoid replication delays that can occur before that user logs on. When you reset the password, you can also unlock the account and set the User must change password value. These options are in the Change Password On a DC In The Users Site box as displayed in the following figure. Figure5 Change Password On a DC In The Users Site  How to Remove the AcctInfo.dll Tool To remove the AcctInfo.dll tool, delete the AcctInfo.dll file from the Systemroot/System32 folder, and then type the following command at a command prompt: regsvr32 /u acctinfo.dll The EventCombMT.exe Tool You can use the EventCombMT.exe tool to gather specific events from event logs from several different computers into one central location. You can configure EventCombMT.exe to search for events and computers. Some specific search categories are built into the tool, such as account lockouts. Note that the account lockouts category is preconfigured to include events 529, 644, 675, 676, and 681. Figure6 The EventCombMT.exe Tool  Where to Obtain the EventCombMT.exe Tool The EventCombMT.exe tool is included in the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the EventCombMT.exe Tool You do not need to install this tool separately. When you install ALTools on the domain controller, EventCombMT.exe is also installed to the directory you specified during setup. How to Use the EventCombMT.exe Tool To use the EventCombMT.exe tool, open the folder you specified during setup for ALTools, double-click EventCombMT.exe, click the Searches menu, click Built in searches, and then click Account lockouts. When you do this, the events that will be pulled from the event logs are automatically displayed in the tool. These events are from all of the domain controllers in your environment. In addition to 529, 644, 675, and 681, type 12294 in the Event Ids box, and then click Search. The tool then searches the computers for these events, and then saves them to a .txt file that you specify. The NLParse.exe Tool Because Netlogon log files may become more than 10MB in size, you may want to parse the files for the information that you want to view. You can use the NLParse.exe tool to parse Netlogon log files for specific Netlogon return status codes. The output from this tool is saved to a comma-separated values (.csv) file that you can open in Excel to sort further. NoteThe return codes that are specific to account lockouts are 0xC000006A and 0xC0000234. The following figure displays the interface for the NLParse.exe tool. Figure7 Netlogon-Parse Return Status Codes  Where to Obtain the NLParse.exe Tool The NLParse.exe tool is included in the ALTools.exe package that is available at "Account Lockout and Management Tools" on the Microsoft Web site|http://go.microsoft.com/fwlink/?LinkId=16174. How to Install the NLParse.exe Tool You do not need to install this tool separately; when you install ALTools on the domain controller, NLParse.exe is also installed. How to Use the NLParse.exe Tool To use the NLParse.exe tool, open the folder you specified during setup for ALTools, double-click Nlparse.exe, click Open to open the Netlogon.log file that you want to parse, select the check boxes for the status codes that you want to search for, and then click Extract. After you do this, view the output from the NLParse.exe tool. Typically, you may want to look at both the 0xC000006A and 0xC0000234 code statuses to determine from where the lockouts are coming. The FindStr.exe Tool You can also use the FindStr.exe tool to parse Netlogon log files. FindStr.exe is a command-line tool that you can use to parse several Netlogon.log files at the same time. After you gather the Netlogon.log files from several domain controllers, extract information about a specific user account from the files (user1, error code 0xC000006A, or error code0xC0000234). You can use this tool to help you obtain output about a user, computer, or error code in the Netlogon.log files. Where to Obtain the FindStr.exe Tool The FindStr.exe tool is included in the default installation of Windows2000, Windows XP, and the Windows Server2003 family operating systems. No additional installation or configuration is required for the FindStr.exe tool. How to Use the FindStr.exe Tool To use the FindStr.exe tool, rename the Netlogon.log files, and then save the files to one folder. To parse all of the Netlogon log files, type the following command at a command prompt: FindStr /I User1 *netlogon*.log >c:\user1.txt The Replmon and Repadmin Tools If you have not already verified Active Directory replication on a domain controller, at a command prompt, type repadmin /showreps or replmon to verify that proper Active Directory replication is occurring. In many scenarios, you may find that you unlock an account but the new credentials do not work. This behavior typically occurs because of replication latency. Change the users password in their local site to avoid replication latency issues. Where to Obtain the Relmon and Repadmin Tools Both of these tools are included with the support tools on the Windows2000 CD-ROM. How to Install and Configure the Replmon and Repadmin Tools For more information about how to obtain and installing Replmon and Repadmin, see the Windows Support Tools documentation. Network Monitor Network Monitor is a powerful tool that you can use to capture unfiltered network communication. If the account lockout occurs because of a process or program and an account is already locked out on a specific client computer, gather network traces of all traffic to and from that client computer while the account is still locked out. The program or process most likely will continue to send incorrect credentials while trying to gain access to resources that are on the network. Capturing all traffic to and from the client may help you determine which network resource the process is trying to gain access to. After you determine the network resource, you can determine which program or process is running on that client computer. If you can narrow your search to a specific computer but the user account is not yet locked out, keep running Network Monitor until the lockout occurs for that user. After the lockout occurs, compare the time stamps of events when the in the Netlogon or Security event logs with the data that was captured in the trace. You should see that the network resource that is being accessed with incorrect credentials. After you identify a program or service as the cause of the lockout, view the software manufacturers Web site for known resolutions. This behavior typically occurs because the program is running with the currently logged on user's credentials. If a service is causing the lockout, consider creating accounts that are specifically for running services so user account password changes do not affect the services. Where to Obtain Network Monitor The full version of Network Monitor is included with Microsoft System Management Server (SMS). A limited version of the tool is included with WindowsXP and the Windows2000 and Windows Server2003 families. How to Install Network Monitor on Supported Operating Systems This section describes how to install Network Monitor on both the Windows2000 Server family and WindowsXP. Windows2000 Server To install Network Monitor on computers that are running Windows2000 Server: Right-click My Network Places, and then click Advanced. Click Optional networking components, and then click Management and Monitoring. For more information, see "HOW TO: Install Network Monitor in Windows2000" in the Microsoft Knowledge Base|http://support.microsoft.com/?id=243270. WindowsXP Network Monitor is included with the Windows support tools. For more information about how to install and configure Network Monitor on computers that are running WindowsXP, view the following articles: "How to Install the Support Tools from the WindowsXP CD-ROM" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=306794. Description of the Network Monitor Capture Utility on the Microsoft Knowledge Base|http://support.microsoft.com/?id=310875. How to Use Network Monitor For information about how to use Network Monitor to capture information, view the documentation that is provided with the tool or read "How to Capture Network Traffic with Network Monitor" on the Microsoft Knowledge Base|http://support.microsoft.com/?id=148942. Summary This document describes the reasons why you should take a structured approach to setting the account and password policy features. The document also provides information about the tools and log files that you can use to troubleshoot account lockouts. After you read this document, you should be able to determine from which computer the account lockouts are being generated, as well as the program or service that is generating the lockout. Appendix One: Additional References for Account Lockout For more information about how to lock down your environment, as well as for more information about security features that are not addressed in this document, see the following Microsoft Web sites: "Microsoft Solution for Securing Windows2000 Server" on the Microsoft TechNet Web site|http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/Windows/SecWin2k/Default.asp "Checklist: Create Strong Passwords" on the Microsoft Web site|http://www.microsoft.com/security/articles/password.asp "New Registry Key to Remove LM Hashes from Active Directory and Security" on the Microsoft Web site|http://support.microsoft.com/?id=299656 "HOW TO: Configure Remote Access Client Account Lockout in Windows2000" on the Microsoft Web site|http://support.microsoft.com/?id=310302 "HOW TO: Prevent Users From Changing a Password Except When Required in Windows2000" on the Microsoft Web site|http://support.microsoft.com/?id=309799 "HOW TO: Prevent Users From Submitting Alternate Logon Credentials in Windows2000" on the Microsoft Web site|http://support.microsoft.com/?id=310360 "HOW TO: Manage Stored User Names and Passwords on a Computer in a Domain in WindowsXP" on the Microsoft Web site|http://support.microsoft.com/?id=306992 "Best Practices for Enterprise Security" on the Microsoft Web site|http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/bpent/bpentsec.asp Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues You can use the information in this section to help you gather information before you start to troubleshoot account lockout issues. Collect the following information to troubleshoot account lockout issues: Client Platform If client account lockouts are occurring on a single, common operating system, there may be specific issues with the operating system. Different operating systems use different processes for name resolution and authentication protocols, and they have different levels of security, so there might be an infrastructure or program issue. For more information, see the Microsoft Knowledge Base article "Service Packs and Hotfixes Available to Resolve Account Lockout Issues" on the Microsoft Web site|http://support.microsoft.com/?id=817701. You should gather the following information in these situations: Do users log on to multiple computers at the same time? Are there any common patterns? For example: Do the computers have the same mapped drives? Do the computers have the same mapped printers? Do the computers have the same antivirus software? Do the computers use management software? Is another networking client installed on the computers? Is SMS installed on the computers? Does the network include a Wide Area Network (WAN)? If the computer is running Windows95, Windows98, Windows98 SE, or WindowsMillennium Edition, what is the version of the Vredir.vxd file? If the computer is running Windows95, Windows98, Windows98 SE, or WindowsMillennium Edition, is the Directory Services Client installed on the computer? Domain Platform When you know the domain environment, the security boundaries, and how the user is gaining access to the resources that are in other domains, you can better determine the cause of the account lockouts. You should gather the following information: The number of domain controllers, including operating system, location, service pack level, and so on. Is Active Directory and Netlogon replication occurring? What domain does the user log onto? List all domain trusts that the user uses. Is there a matching account with the same logon name in the trusted domain? Are there any third-party SMB servers running in the environment? Background Look at the client and the network resources that the user might be contacting to help you determine the cause of the lockouts. You should gather the following information: When did you first notice the lockouts? When did the lockouts start? What has changed in the environment (new programs, new network services, and so on)? Are there any identifiable patterns: After a password change? When the user logs on? When the user gains access to mapped drives? When the user uses Outlook? When the user uses Outlook Web Access? Are there no identifiable patterns? How many user accounts are locked out each day, a small group of users or a large group? Is there an account password policy? How many bad attempts are allowed before a lockout occurs? How much time must elapse before the count resets? What is the LockoutDuration registry value? Gathering Diagnostic Information Gather all of the different log files from Netlogon, Kerberos, and the event logs to help you determine the cause of the lockout. Diagnostic information that you gather from the computer from which the lockout is originating may help you determine the cause for the lockout. You should gather the following information: Netlogon log files Traces Event log files from client computers and domain controllers that are involved in the lockout     g h bc $DHko !" "+","D"E"%%))~..//,2l2G4c444E5P55 6n66~888-99999::2;H;J;V;W;g;v;w;;;;;;<<=>? ?DDD4Ejh3>*U6mHsH5 h3>* jU j\5\H*h\TO} 0 h  " tk gdgd&<q*F & FEƀF & FEƀF & FEƀ<GXl%F & FEƀF & FEƀ & FF & FEƀ4oF & FEƀF & FEƀ4[q*F & FEƀ F & FEƀ F & FEƀ 9 "##$i$kF & FEƀ %F & FEƀ i$$ %%3'q*(%F & FEƀF & FEƀF & FEƀ3'((o)))*-eI& & FEƀ.gdI& & FEƀ.gd.-._//k!I& & FEƀ.gdI& & FEƀ.gdI& & FEƀ.gd/j01n22>33G45hF & FEƀI& & FEƀ.gd5n677~88hF & FEƀ & FF & FEƀ8999m"J & FEƀ^J & FEƀ^F & FEƀ999;<i_] %&dPJ & FEƀ^J & FEƀ^<=0???X@@BD`E|EnFqomokoooao &dPF & FEƀF & FEƀ 4E5E6E]E^EFFFFVGlGnGzG{GGGGGGGGGHHHHHHHHHGI]IlI|IIIIIII=JGJJJJJJTLQ*QQQQQ#R2RQR`RRRfUhUqVVVVW'W0Z@ZZZZZ]]]] h0J!>* h>*H*5\5\\]] h3>*jh3>*Ujh3>*UNnFFDHpHHIIIJg_& & FgdI& & FEƀ.gdI& & FEƀ.gdIJJJLM3OkigiI& & FEƀ.gdI& & FEƀ.gd3OO^PQSFVWZ];^b^aqnlllllgel%gdC$F & FEƀ!F & FEƀ  ]]]:^;^r^^^^a_r___`$````*e,eZe\epeqeeeeeeeffggxgzgggggggi/iijyjkk$l3lqqrr#tctettmuuuuwww/x1xcx{{{&|(|h|j|}}}~_x>*PJ5PJ0J+ h>*5h>FCJaJ\5\hJB*phhJ hJ5Paa^ddd e%e*e+e,e6eYkd $$Ifl4Fd8 t0    44 lalf4 .$$Ifa$.$If. 6eIeZe[e\e`edeB<$Ifkd$$Ifl4r xdX8 t044 lalf4.$Ifdehelepeqexe{e~e?kd$$Iflr xdX8 t044 lal.$If$If~eeeeeeee?kd$$Iflr xdX8 t044 lal.$If$IfeeeEkd~$$Iflr xdX8 t044 lal.$Ife2fWffffgg .$$Ifa$.$If.gdC%Eƀggg+g@gUgmgxgygnhhhhhhh.$Ifkd^$$Ifl4F<t"P8 t0t"    44 lalf4ygzg~g".$Ifkd"$$Ifl4֞ <t"8 t0t"44 lalf4~ggggggg.$If$Ifggg%.$Ifkd$$Ifl֞ <t"8 t0t"44 lalggggggg.$If$Ifggg%.$Ifkd$$Ifl֞ <t"8 t0t"44 lalggggggg.$If$Ifgghh%#!kd$$Ifl֞ <t"8 t0t"44 lalhAjNklq*F & FEƀ$F & FEƀ#F & FEƀ"lDmn?ppq*(F & FEƀ'F & FEƀ&F & FEƀ%pqretmujF & FEƀ- & FF & FEƀ+mu1x(|!~q*F & FEƀ0F & FEƀ/F & FEƀ.xOÃŃKtҏ֏ij6I`ח~̘Ǟ۞CWBVQUs£ǣϣףߣ'KΤڤVZ~¥ӥmh]u h]u5>*\55\PJ5PJ h>*X!~Rq*(F & FEƀ3F & FEƀ2F & FEƀ1Rڊ,/kF & FEƀ/F & FEƀ6 (TgL & FC$Eƀ^L & FC$Eƀ^Trҏhf%J & FEƀ4^L & FC$Eƀ^ڑ8I:!92T)szvٝ?4D%C$Eƀ9ТQMeI& & FEƀ.gdI& & FEƀ.gd%\k!I& & FEƀ.gdI& & FEƀ.gdI& & FEƀ.gdmwզ !2W^ȧ0"*Nfԩة*9ptʫ 5NDHX^s*. !ķbgowǺOYnz45] 5\]h&{5\]h&{5\ h]u5Yyצ k!I& & FEƀ.gdI& & FEƀ.gdI& & FEƀ.gd 2}* /ܹ\%\Iq*F& & FEƀ.F& & FEƀ.F& & FEƀ.q*F& & FEƀ.F& & FEƀ.F& & FEƀ.4CSbsSmȽھۿ FO%}G (v Oiinz7Nku76 h&>* h7)5\] h$ >* hgr >*>* h@>*h@5\5Toľſ qomhh & FF& & FEƀ.F& & FEƀ. B l 6fF & FEƀ= & FF & FEƀ7 6ndqommmF & FEƀ?F & FEƀ>Bfq*F & FEƀCF & FEƀBF & FEƀAw>8cbmkDC$EƀF & FEƀD b]|mF & FEƀEF & FEƀDRo6-kF & FEƀYF & FEƀF-CoF & FEƀuF & FEƀZ=Nx%F & FEƀv &;7\u u}PU]`gn&-Zq|"5#6####)),,J5Q55688K8^8u9|999G GYHHHI9KKKLKgKNN"O] hw]>*hX)) h&>*5\5\>*Y\ukL & FC$Eƀ ^I& & FEƀ.gdI& & FEƀ.gdui` & Fh^hJ & FEƀm^J & FEƀl^JnC%Eƀ%I& & FEƀ.gdJ&k!I& & FEƀ.gdI& & FEƀ.gdI& & FEƀ.gd&\}4QnYH& & F C$Eƀ.% +J h  omkH& & F C$Eƀ.H& & F C$Eƀ.  ) H  q*(F & FEƀQF & FEƀPF & FEƀO    1 q*(F & FEƀPF & FEƀOF & FEƀN1 g  '   G   Wi`````^``  & Fh^hM & FhEƀ^hgdGC$Eƀgd #U$mHm"L<CEƀ  & Fh^h*&F & FEƀR  & Fh^h & "7##dJ & FEƀU^  & F^F & FEƀS#%&&&&&.$If.gdF & FEƀW&&&&EEG-$EƀIfqkd$$Ifl0p!pP04 lal&&&'-$Ifqkd$$Ifl0p!pP04 lal'''J'-$Ifqkd$$Ifl0p!pP04 lalJ'K'V'n'-$IfqkdG $$Ifl0p!pP04 laln'o'z''-$Ifqkd $$Ifl0p!pP04 lal''''-$Ifqkdu!$$Ifl0p!pP04 lal''(O(-$Ifqkd "$$Ifl0p!pP04 lalO(P([((-$Ifqkd"$$Ifl0p!pP04 lal((((-$Ifqkd:#$$Ifl0p!pP04 lal((()-$Ifqkd#$$Ifl0p!pP04 lal) ))2)-$Ifqkdh$$$Ifl0p!pP04 lal2)3)>)])EEG-$EƀIfqkd$$$Ifl0p!pP04 lal])^)j))EEG-$EƀIfqkd%$$Ifl0p!pP04 lal))))EEG-$EƀIfqkd-&$$Ifl0p!pP04 lal))**G++,@7 & Fh^hF & FEƀW%qkd&$$Ifl0p!pP04 lal,1.v.//01f]  & Fh^hF & FEƀ & Fh^hF & FEƀX%1g144J558K8u99_VVVVV " & Fh^hF & FEƀ\  & Fh^h & Fh^hF & FEƀZ 9;N>c>=@AB)CEdF& & FEƀ.F& & FEƀ. " & Fh^hEGGHHmF & FEƀ\%F& & FEƀ.HI_IIJhK M;MMqN>OP-PQ  & F^  & Fh^hF & FEƀ] "O>OOP,P`UUXXh[[^#^^^^^._?_.b3bIdNd4l9lamgmhmjmsmymmmmmmmmmmmmmmmmmmnn!n"n'n(nnnnnnnnnnnnnoooo,o-ohpipkplpzp{pEqFqIqJq[q\qqqqqq B*ph5\hw]\ >*mHsHmHsH mHnHsHXQQQRlS`UUVVjW X:XXXGYYh[[[C$  & F^  & Fh^hDC$Eƀ[[\^#^^^^^^^G_-$IfPkd['$$If08!8634a*$If.gd  & F^  & Fh^h G_H_L____(`WPkd=($$If08!8634a-$IfPkd'$$If08!8634a(`)`-`o`p`t``WPkd)$$If08!8634a-$IfPkd($$If08!8634a```aa!anaWPkd*$$If08!8634a-$IfPkd)$$If08!8634anaoasaaaaaWPkd*$$If08!8634a-$IfPkdr*$$If08!8634aaaa.bvbwb{bbWPkd+$$If08!8634a-$IfPkdT+$$If08!8634abbbbcc0cWPkd,$$If08!8634a-$IfPkd6,$$If08!8634a0c1c5cdd d)dWPkd-$$If08!8634a-$IfPkd-$$If08!8634a)d*d.dIdeeeeWPkdk.$$If08!8634a-$IfPkd-$$If08!8634aeeeeeefWPkdM/$$If08!8634a-$IfPkd.$$If08!8634affffffFgWPkd/0$$If08!8634a-$IfPkd/$$If08!8634aFgGgKgggggWPkd1$$If08!8634a-$IfPkd0$$If08!8634aggh&h'h+hhWPkd1$$If08!8634a-$IfPkd1$$If08!8634ahhhhhh*iWPkd2$$If08!8634a-$IfPkdd2$$If08!8634a*i+i/ihiiimiiWPkd3$$If08!8634a-$IfPkdF3$$If08!8634aiiiijjjnjjWPkd4$$If08!8634a-$IfPkd(4$$If08!8634ajjjkkkkWPkd{5$$If08!8634a-$IfPkd 5$$If08!8634akkkkkk4llWPkd]6$$If08!8634a-$IfPkd5$$If08!8634alllammmmm*$If.gdPkd6$$If08!8634ammmmmm1ckd7$$IfF !k46    34a-$Ifckd?7$$IfF !k46    34ammmn n"n(nnckdM8$$IfF !k46    34a-$Ifnnnnnn1ckd[9$$IfF !k46    34a-$Ifckd8$$IfF !k46    34annnooo-oipckd9$$IfF !k46    34a-$Ifipjplp{pFqGq1ckd:$$IfF !k46    34a-$Ifckdi:$$IfF !k46    34aGqJq\qqqqqprckdw;$$IfF !k46    34a-$Ifqqorprwwwixyx{;{|}}܀ÂRkmqxІbrs~EjlScdŒȌٌیHfk;EHT @I˘ΙЙ0J! h0J!>* h>*>*6]5\\5 B*phWprqrrHstOH& & F C$Eƀ.ckd;$$IfF !k46    34at;t`tyttp)$ & FF & FEƀ.F & FEƀ.H& & F C$Eƀ.tuu vYvvvwwhfdffF& & F Eƀ.F& & F Eƀ. " & Fh^hwix{|q)H & FC$Eƀ F & FEƀnF & FEƀm|܀oF & FEƀv%F & FEƀpRbEq*F & FEƀtF & FEƀsF & FEƀmES݌V}׎qomkikikik%F & FEƀvF & FEƀu *@fmF & FEƀF & FEƀfvʓq*F & FEƀF & FEƀF & FEƀʓ4ƔmF & FEƀ}F & FEƀ|;Hq*F & FEƀF & FEƀF & FEƀ~H@q*F & FEƀF & FEƀF & FEƀ@ЙYښlH& & F C$Eƀ.F & FEƀٛ;<= '+" LZ[Ǥڤ cmʨPeq}ʪFbc3qǰı]uP˴6]j|QhC>*UjhC>*U hC>* hC5 B*ph0J! h0J!>* B*ph h>*6 j<5U\5\5E!;=Sǟ'pnlnjddbnb%  @.F& & F Eƀ.H& & F C$Eƀ. N(N-\u'kH& & F C$Eƀ.H& & F C$Eƀ.  =kH& & F C$Eƀ.H& & F C$Eƀ.PةHoccca_ " & Fh^hgdH& & F C$Eƀ.H& & F C$Eƀ.Hy٪o'%H& & FC$Eƀ.H& & FC$Eƀ.H& & FC$Eƀ.3ı " & Fh^hF & FEƀ% ]Pf7UdF & FEƀ " & Fh^hF & FEƀUڶq*F & FEƀF & FEƀF & FEƀڶHbmq&J & FEƀ^F & FEƀF & FEƀmyiJ & FEƀ^J & FEƀ^J & FEƀ^rY~ֺ gF & FEƀ.%J & FEƀ^Pչ+WX~  $9PU_żQ[lľžz;<= 6IJ3BNVctz.9:\hCB*ph jfU jDU65 jqU jIRU 6B*ph 5B*ph0J! h0J!>* h>* B*ph5\H Qżľƾ1<>b0 " & Fh^h.F & FEƀ.0 .:giNr%.:ghi  LM2jw$BNTgv2B"A`/;L]em JLV"gq#ǿǿ h]>*>* >*B*ph5 B*^Jph56mHsH 5mHsH B*\ph 5B*ph0J! h0J!>* h>*hCB*ph B*ph\ jU\BT |2R"`/gH& & FC$Eƀ. " & Fh^hgLW"%@FN?F]& & FH& & FC$Eƀ.#%?@D>?BE"5PcVih\M h]h\M jUh\T5\CJaJ>* B*ph B*^Jph)UiH & FC$EƀH & FC$EƀJiJ & FEƀ^J & FEƀ^J & FEƀ^JtiJ & FEƀ^J & FEƀ^J & FEƀ^.>q*(F & FEƀF & FEƀF & FEƀ>5o(F & FEƀF & FEƀF & FEƀ#oq*(F & FEƀF & FEƀF & FEƀio(F & FEƀF & FEƀF & FEƀ(AXm"J & FEƀ^J & FEƀ^F & FEƀXiJ & FEƀ^J & FEƀ^J & FEƀ^Ejm&F & FEƀF & FEƀJ & FEƀ^jiJ & FEƀ^J & FEƀ^J & FEƀ^%exmF & FEƀF & FEƀ4gdF & FEƀ 1h/ =!"#$%Ddp2 D  C APW1b]ˌ`m`ٚ{"Gd;9D n1ˌ`m`ٚ{"Gd;PNG  IHDR/fPLTE 33ff3oo?yyL &&||R__?VV9f_rrLiiF99& YLL3Yf&&YYBrffL??/33&_̙|iLL9 rrV66,))#ZZMƳŲϿ773mmfLLI_Ͽ\L3iYB|Rե|=733 f3o?yLՂY6#ٌfiLܖsߟ⩌鼦ƳϿؼیii9&_?_fLrVV9rVfL3&YB9&L9I/3&?/&& l &_/  o//00??@@__``pp߀O@@pppooo```___PPPOOO@@@???000///  =bKGDH cmPPJCmp0712HsIDATx^흋E!%iM^zIVXbEekEEWUy494wmHroٛlOݽų%W%WXa< $g@rfC."RP'JmV`USY$h\2c DU!5cMe8BBb] #QWzRC<$?t!-Ԡ %Y‰G*YMWP)ii W&/ zc9$?(=w( n j!ix޴EE ﾇM/|8S@ %٥?$NPbev!DLu~5X=>!@$+BH>3)y[k!3 !C_A!yUֹ.UkE~d*B@@ th1!.R 0SϏ&J@H@TܡT5˓R I]fzЭx@jy*|Q!`A<$?E |uYCn^ <׮T=1ڔBbnڤbDF-vpJxS,Bس@r, $gș8C,Y gz}2gv-Եl4d,WkTY6QpBq?o%uoﺷcq*z'wI"@8Ju oul9i)o󺋜eಚy@$ ]wTPoN/`zU$\ {OWqߌ^ ap7AyR,3N aher\,~- ! ,toyT1: 4 wy8B<$ +@d d{W<I:}|_ PYkiwSi.o9}~Vh?$=YM 6/%ӟ]yp-W"gݖZQWX@q QAxYMÈJe,u"/v]Hr.{1EGxP$2V׃ӜYf$ɦM!"fsCHϊ/6?=Y+c~^Ow~xw$ 7~YvCyKV##?~% R{>mę̪Tncnh:0v2:#&*7&DI?᳞x&3˄w"@<o_߾nO>iQGuv\*/Nq"*!b/NϒBQ,DX+X{IXz9z{7 ̣)4p]Kxȿu1Xfդ\ҨR$1 g EW@(v\P jMUSt:H`ktxBD"@B.@Q^T2\'@@I$6t4<2f褄סc@9xN|5j[PCݦ pae @r oƵ=^ CKS3" H!iu•FCV Uei $:"h]BnCQQa3|Ƹ$4'H(Ȇ4sԩP\yK΢N8d{e\i$% ͇?T'95;,a *8#eҏ;%#ǞY7K'l՝_+SLڃDď\Y-C6κx`B,qmt ,琨z(X㇟g@B:8Ӊlk"id@,#RI%M q. I3t<6 (cQ:@RKq(O IN! ?w_xO{PMLקm#2Є=d'):@ipQ9bTV(d EЃCIݛ뉇:JaJ{!gwBc+i/򐥺r9'$ &K|3uCվQu (1<C.xxRgQg7յ3#E׉N WԁD?`ўv.RO [Y&I}ph`E!=$Bw XR!<(4~ʓ` t|bi deƛ) ]UgC:@n;ٰ7$ˋk Ll8R0$b%CnD0mo5C鲳yX7]hUb+ ,Q[1t$WtDkK /Hlr"QWa&em 9ȗԡ}󂍤Կe(1B%7@I(]1p_?@!!dQzT< Xk\~,yG0qr9:]nC"rjwnv=*rF\=^XO'&>ٶ̓P,F^d++B^ ޳_~*|=j^݂f X2^ ό?yZ9<>qLZGhpD ;-t8WX 鬕\Kc v;|EԳ!KN9qǏG6X k>t(ֺb(Y gu,!Z Nkj81 o8{Z_`^^V C WNَPf)1 d^ŞRכa +pؙ/2h=$-@9v Y&/7ҶtY KiҝıߛB&H~ikN0 MO󇺭}, !7fA $z@؍H*XImT@zcԭX M՛ƀĮx2R"g(|e ļZ@ebJ-X J2_1oc,%slR ZL3x);1=`%X rVYKȲϖZΤJ/bsHV:6^ $+MYWZ Q#5z@@Ύ7!vbQ2,Uᵘέ(Q AhsHV"HV:1dج@ZqZ\_hOC$h>s1+qҭ5oh6h@ o߾_t:f 9 yܥY|:@ ֳ5fc}Qzjű55S}}[8Kck֎fVo&-)]~BjS6x6z]2u矝ϲ=n=ݾn~ۥ_eWKK.g{sW~e+W_m~jdqn\/o7߸_߸Mܿ_/ηo6mt.w>ݾ/o/{ꇸpvoߺ;?vn۽vν~~=_=0Gqo?_k?~tqœt|?>ݞe{۳?{ߟ?}{=x{G۟qlge"O_d˸W/OO_|u4ۋWoN߼{u{6z6ߧw>54p8wgc>~xҖ8#~2濘Kb61:/}y܎/g{sr+Wkc>Ҙlg#Zm_qͯ#49{g#8k~2c樿5dPw➎;(wcG1<ǣQsQ_18`78oϟȩ#~/5o+|̗Wq1זc~?lo1g?o߽38-öQ˼1K̚kcOW+Weu63sv]7 @kX5L$h IX52 h@5k]h }+l L0H~{ OGyK$ 5k;$ @iΦ=IrAsXإ5W!c~ł` ,_L08+k|Rkgυb `?]X` k5} -@ ߿-=w6@|6` 5F%G Xɬ,N3gd` `7'7_c|Xט8,5k` 5="@0ao؁U8MjްpT ||sDLf7Bh >hǣF&|8M}tr 0'h(/$d^#ˀP oZ# v5Öa8/a7tfOA`7 |{+jNs}8*GsO[[8O}8*G5 @Q ؁V㎏ۃY>gZ8??̸\뻜mGOc??Vp7?`6flջ|E'tB磪x\~=@]!v0 @퍅?lt9K txD`;# [ W(#V/c 5TnBf&Ҙ+n\0Z>?;WrYf|ح;vwș>DKxj~jq*'W ]Y(?Cm1V P OLqV{gXJyv`+cGb$Ow&*cvJݘp/U8ӻnxWsⅇ@8_2V?.>N>U]=0\.a %՛zf>t>Z?ˍyaOcuAf<[~P Z%EL)@-[h[m@kެ9t2s ?i9 ͧճ(/P} гElE0U6X^q^W=uv%V?P.$aX=Smvv'ƹwtTjj8}8 vM q̟pTj{H@ɓ  GGG0"} h0J Y} ` .9 T/^)|]X}F0:H 0 pGvO\>T@X @?*84^NrKOE(Bf<}?djKjQ<@ [,Bi_lq>l&!O&n(/ø2nG5jݣ9<57Ԗ^B%'X/pӺ/C[B-T-zHCH*0:>PC VjKjQLE4S] @H}q&˯CQ1Ew?} i`+BrT+ʵx>L* Qص񧿚(>c @H PyW-Zy4mkewGU?_b0ՖHE @vk׫@i6gԥ7>VjKj GWGGGɠy\^]e-@2#fڗ{v4էmm$8㲶DQU_)̗ƹZ4'  @6c_@2@-IBpFBhqC-`Q?nw?j,vCn÷!Hg8%=]tCm/t7&q'mpC=pC oG|W~mTV{ 7T`m@0S>                            $                                                              8               taU@/$շhOP) {,$ Ng@} hֺ KX  T־{9A`@1 \+l Z6cWY~Nw`CW^Z > 7\J ~++j /_=?_6AIENDB`DyK www.somarsoft.comyK 4http://www.somarsoft.com/Ddc`  S <"AadditionalinfobFJ-c('[bR nFJ-c('[bPNG  IHDR b=sRGB pHYs+PLTE!k)s)k)k1s1s1{9{!9{!9!B)B)J1J)J1R1R9R9Z9ZBBBBZBcJcJcJkRkRsRkZsZ{Z{BcRsc{cckksss{ks{΄ք΄֌֌ތޔޔ甽眽眽MBIDATx ܶǑczmN$I:;9[Jc4=Y͈ȟ@H@r.; ip%++ս_<ü\?뇏G77O'Uyz[gOdzUygӼ<勗ū^.S]rK^(K-ߊY^r{^>Er6@ >(^{s eTeg[~?{ lɚx ]U_6@IR6@6@0U|i=msi Pm*6@//lV@@io MAA;ܖv@i<-5@s6@ 4J/WY?,F}_\KW*u_/=/l< (l< g$r'pڳ6IHvl)_gH?N w l 9ÆV56wAQwoέλRG*/$wo\TӴӫ[% rx[mtM-U+MN4օ L4TŮP— 4UP7U# f@Nԇ XkߗnVݤ*B @{(du4zsMw E&6 @ٜePJ]N􇦗L!M-$?w/ Nv z,8պ$LfjvC1(Gy6)cyDenFr,)8T;K;my[A I@uyh3?^ @8!BBZwL?P#;mt & =2 "2i{@̈*0$aw˥2\c ߭  RiO Ç@'W "E4`>6'a7aY+Z%=, ,g؆qzjQDGyx-1şsdp 3 2yg\dN9m2K3_93"\8n>P1Sl/_? 06GjX*#’`,02Rޑoj75 TvFjom?$9i gL:`WW0uZr50=:jSHPx])t =a:4<x]63d6"w[mPTk :rvA<;sF >Tξ`pʌ@XQp+8E  /h2g<IH\ٸ[ @ /7ޖf"Nm`$:H]8z?2ys8u22ouvTϏGK"3. lUN`2#e^m;8nс!u7(CE40p=3P0=<-gD8(IFt z^^HaAڷ C9v aL`#9=vヤ!:C 6.!@лcC|P О 1X#4bFa Cfv{ボ3 09<@j7 mK!tF92ボ8M%[mY2⎒w),A}S kY oXmK ۂЌ \8l #jx?- }\\P w9U=%,ptZGdw9 n 6dv,)mgN܎@d oZ. gyaH[0#pLv( ?!#Њ,@`` \X2q' ;Dc1I)3xoŐ-]>2`;^wUy]OQw9@w%K'&w;@t3/WzO e]mwn $ݲH%}7s|ãΧmsJw:%r @:-2)"{݉vA0rؽ=!0&&[5)!GMcͯ}R@8g5.G1@A@@Ï @P@.!XU̿+!recozXCM58S A'b.=ɀ<|]{ Tڑ|~tPԬT&mLE/_Ts?ެ7?i@,9# ;HtNVF[n$~g|s `.03 lr!CP!,a͍@6d79,̫3G!@Ǫ7k|J!f/6 @@@@@@o3V Ue ٥C$j@<r(įχ]R 0|>Epg"y/%*U9}@HP.,\$^Fb*/ȎΉ\F uH+@)&1C,dO1 +@,DF8{$yDHN@niq?X,]kA : ::*cS#hGA MЌ Ƞ-ȠiXѡa WdDA`!A`td(:Ƞ h 82?X,]kCаа2; ܺq_B<{] Ej ֭Sh1^p/AH/yx{C/fu6^ qȋ@8?VdG$Vbۋ r 1#I @SdXW8n&IC"3"|;#+xE3;X 4*2pXow它Μ'è dC+v&1 ;`(^@>T@5 0$ o,p,5`?k\13ɔD20dKL^u=O R``T>vg)Aj#%ţgϿ[E(EVݿM&p=M0R0Ԉn:6Ýj@>eкAj} 5fAq,u'/FIvrwysǠYNLN̐x qV (bIvD,^E[P4$KO C\ ewrW ǕKIq,,ww[;R!O/)OA8 .3`i"Ӎe, @6,@lV,gpxp63PvO +:ph߳Sx d`? NWegy79!5d2'4U׼sz.8N  ' >Չ~*ݮ]^- 糞+A/jgV 8 NZ!yLBe+G`i-|q)ْ яȪIENDB`NDdJ^  c :xjApwdsettingb]N0pkܰ2:yHΆx:r np]N0pkܰ2:yHΆPNG  IHDR*sRGB pHYs+JPLTE$k(s,s0{0s4{8{(k0s4s$s,s!8{!<{!8!<)A!A)E)E)I1I1M1M1Q9Q9U9U9Y9Y)M1Q)I9]BABBYB]BaBeJeJaJeJiRiRmJmRmRqZuZuZyRqRuZyZ}Zqc}c}cckckkkksss{s{{ks{΄քք֌֌ބ֌ޔތޔތ֔ތބΔ甶眺町眺眶  IDATxCGmUD-Br(Ҟb-xrjzfdOD k($dZ%+̏# =8g.Ӓ~s˅ 8,#.^4:vi|l|lb|bdiTtt|})a ^rX][k l56$[vU+?U*F=#`o_FS5o6/^<r^YGbo2}L8+  pqVq]+@uKRTG[K 3 r[5@F}m=[H'ZCV o2ݹRkgBUIes $9,3ãX^%*g@21 mߤ mͪo.|K(V-TIsJ!*(g[gDLG}U8JZR{V*A_~.唔7+:F\նzEM&pfyyhҮK eEhRĶȐJJ4e%W  a4܉@gy/@|܋3lOtK wk mL,C:+w}y__&е=gAbh? u쫫v/@H1p8iy#z^;A{AHZ v{< zƉFP!Mi5jv zn5ۦvǶ,^vFPm:|-+@KAM4-4ЂFP"Q;( Ʒ@"6R6j%"k;A-u:ht@+K*z @ѧ '}. +a͝ 8]T崉TȂCڲNS޾3ThNP\ @yԦ]+@k:A $ uBiR.IN] 8 }·> NPt<?0C 3Ciu7w`4Sytw7ʋD6Z;it} ;s=x b E$w˙x*@7t82(RN& b p˧OIS@uEW~*N6BMvWwp8ttP@|E 2DT;@qpQgg}s:|cP%談+Tp1^L(ADa1s_R< e9AGibB^8,2Pc @j鲿P f9')br!DQ]s3r6x'HV@O}n(D3|9tdmgbWr6 Б5@ ^99^^ oN՗GdhD7#'pc 9<) { ]10Zg(r,u@Ohw= U#GO|)0DVgTU P P?\(bPG'4]*IM*DV@* YRNjz/8 t qk0ݪ7bp<& ]&I) H/ކm=IENDB`"Ddq`  S <`AChangepasswordbnqU iʦR<J nBqU iʦR4g}.x_:||qS"-lx||Emhނ)\XAZ{ >i_WhKc(@)b%b(%4%}db;`|L|]$(57>UJL40!}5bc}z53>@< h{Tc;sg~}tcXc'rr.ob[s!4S} Y} =3.Lezc!h!0^`XY]W]뛺hkR&pW[ݿkXsW1kolM@Lͷ1v.-OЦ0ַrze n=SL2po<s`or`#;<-w1@%>#X`Xp^`c I `]…o8p4n=@t/-=@m`{kw'cyݕ*cL `\ <@T^ (chK[/=  } ~%pǽ1L Z P˽ `h)a @ X6ǤT :mрiFn xd>6D& ZzH^@\iiP&X DxT{J`#6ɑH@ƥ.:t~fkY{7{ς|%i~e`Úʽ&q7z7?9n+Kt4  F M>SS%#F ?@{JX'Dò0 D|PxW@H2M b z8`pǿ~@TPy(+ e |RAXiZ 0Nz>~0DHd`ey0J23 @}ko^6u6}`ORhX0? H ti/9{7Tn [_ʦO@5Cf}K<X>~`k}[z8hy}@߇`d2y,n|*>/lcU4ߋYe۰'fڱj|گϬs7]yX?jTji]$.Jd(? =b3[ؾ;V-n~V5lXT7=T!|14p9w_#6 Ö̪ۏ|a餯F< .U&K gV43!T)|7|B3 'gI AN-0k5A4v f`.Ԭ[2+@V rOp6 ը_aFᾧbt磾$agO~+6eYؾV n 0_L$+$ۘ߅ K İE%GrWO[X ^ @m7ؕin2cՁP ^"9L` @M_L\8K ^,,_?/j=т0rDA@+KERwɋ"^P[N6অ~و_y"q!m)]l|t [Ѣr YlY@^ ϛb^!$MOKB㹰Ț,_E4 nH' 'z @# ,SN5+3ee%4,Dqr&5br3fhL\q T 88ky2e}. n`/iGM4&YHzmm!/8n 4+_Ho pC ܗ=rFzM@ ܺuΝ;Joyj@؟g>OH{o,xɡGo{pvn1SZ>vЎ!'p)dRyTW~a mO mGmi>j .Dv+]jvX+}L+b e'=ڨgd?ORCɒ }x1{I}X8䔁zunI[U}⤚_Yޫ7n,9ꫯkJްl<9d(#~Ge#t FO~^^ݻµk.//[zP?y}dhXw!q֝( 8;zM0_Hzg/دެ*TzW{ /twyW^zwH8ᐔo~ڼ)B!@[F^}^>k ~w޹{sn߾-¬?c?ɼ^7^~틟ֶGS^wym/¶/Wy_W?/ރO?QtA@?D(O=W_}71WM A{_#U]c>C^yU/~"%|ұ @02$+SʛrU+&3|=y6k5N/s>×o~҃|S5Hؿ~W$w?c^o/f^xۃO9/=U$ ;+%(U5coܻgR\~5r޼w+ zWOG7~M2o~狏oRؿ{͛Oj?g>쏘F}?-C ~Td}ܤ MY96|k׮]\|/|Cڵ}`p|0l:k|w vXUo:t @C΀s؀7?я~ws?}S}7z,+,͒}y5+ @`:] mef{W~c쳟zN_]|wf@kϝ)2×g{O:*2c&N#<\M`L2o>TYNEJ@yw5^]cE}fu޸ݻf1 yֵkOyO߽{լm"XDE$\!7YY]*,_UYjQzZf=gyFhy/GXYWtwOβ츲 Iʯ;q %l%l:]UI IfW-ȵtyrWXW2/pf gGB8e2lf0QHӏeDzsKY>A tdU\t6Dz^77H{}H,8fg}c 6{s[diVzziVFMo#iʮ#@8 zO0aB" s.:/ʅ LM靺z #W'x@S@z^ H_8]xt,cKp@b:]봮#pjTދkWiT# XкtfDRnDw0WC  @@ހbz񢻚޼~ K;GmY5IB_2! M ^"ο*<SGzEԦmNY&b4RgQÉ8l5X/&"|z #F|$6D])7oX~ΨSI/B\o&rTzr)\ ge'q'x7ӗ[q][ Ti_$i WT#M\1(k+\R:1؂Gzwm Qzl`q A\,i-!,6R pn)R PL Mq2FlUm Xosu}|5E7cԃS666eEқEsX=-Ho"H}c7s|iX"mVX[[6QQ g7mGy⮍=<@nHy\W[S)W)%t\x}whFM?ϾūGdY7o;yLH靰R )B@Y:;yئt1eIzļ1\UʳL""T!V,_^uψ.#z|ۺRutn”? w$1_G)NFNSe'ap^B 弟@OEoruy<\tO{B<\-δ -'2g(/eɡj4|RD Y{Vmj6Ġ'&NŘ" *%v`XN*g7I}:M/+TKY`UGT#PPnjHoVmhg˲EzvQХ>`2Bru:@2:壝ϸځm4GԠiAb1sNl1&K2@Py\ HYG9Lҽ[*”dd"-qW'[L ܹpNizUa R4i @PzE*Ղs'Rg.t'Ltx\$? @h@ ׻䐭Cv s()S.MR4HF$Nmm" 5A`#<]/;]n_Ϊv;qo}]iTF̞Ӯ- ؃@zU 컧]_ M)*R(reۊ5qIm_Fi%ξKjпmGIhKGhq~'k5`3X͵T/) o\i^Ҿjq?jYrVXAe2[.ʖNY~o&zZIzR[D$љ=UME_&a+,Cvt>\mc{"y{G29: ~DJm?x\zϒS@zWsNORzIfEhV_/7efS QM8Y;sӂOl1eRӯ5=]2N`'# *{k73R?h?Է,L=s1vdx;SZIkp*å WU#Yji(e_z{OA=E5dvdXXKHAd*Eʌet5s]Gz#J9#rW,Ffr3no[\Vei_>CěƧ޺X e,HLS,KYn0;1aztb'zʫ Dn(yglH/a3JζQ@:ՖM@S#r̵ZbJA@L:_5"vŋq@su3iܛ{ț龽@ *<\df8? ͥbe3qӧS+~baiVCTӱNĤi=NZ^P3"XZrS'vHo3iph/ěbpAZ/:f{0#"C:һߙ NjYfGٳepn˶ ز ($Ho)$d 3Bֵ4B9bwjΫ_q ~pJS}yegঁ)fI ԑZgR*$ȤHLxS4 ֋o-]p&I ԑފg1S^%Dܫ5uˣ`7i ,uWVo!B EU AW {I -2c|9jAǴRqsW42$ @^v?bBnUiF, 'apgfltDoY qGWem ^ǖ4#&ɭGFeU6--oJǍ_5ɶ!ӵj6W$NK\+R%=l4-U'>cȟLA\lYNb5p>q@"#xrNESU7B @TSU7B @TSU$˺}Pv5^OLA@zǭS{^keaHlS&x@`HP1 @X&:&!fo x S vn3td#c";ltX#)ސEA@z<( @B mNYi  V .U#Pk6VC~YN)FH{Z>K"u^Q_7 o=K#N@zshӷKN;)]u@DZ:p@eʨKuh?kҸvY]S ! CTNI@u@;W}+2fLBDU6B@.{{,3;w\]]e'i &WL[vyyYܤW,u3[]SZ+;IӢ;e<(p#//s;QH)3вD `1RVl沞nE@..OuMV8\|,%4;w uסsm@D^O?{&@I꟢YkfK铃^:a`!Kc8MMgYUݽ~Ĉfָ*rDoʘӻK_~? " ^?|J%q׿#ōJ$p> J]EDD{DOds:KNfY F@7Qw=#r\(ajxNO=}8ZEƾ9-^&uWuQط8ed>:=b8EZq3'$'([̈́ia[]lnd]SZ+;IBzlUjM`FVS;`IiitVMYvCzO`v:N{JbIr'? @Ӭ  PN-gGN@@Y @\Ύ[P0%I ^^^m3XV[EVYe:gⲓӬZf<[}w2k|pNOR+&nDAeXV}ZUF= {P`6LJUu(Wwn:vRA靣Qy%JY GZRlF6ƳEw۱Y|SKEodEv'BSekf̾'\H,Z,$Y欦NbҴY[EqZՔ&`IiitVMYvCzO`v:N{JbIr'? @Ӭ  PN-gGN@@Y @\Ύ[P0%I ^^^m3XV[EVYe:gⲓӬZf<[}u2k|pNO_0Ua. Օ+dEE;"dP!B қKCp2NOs=Q P[(& GՁY oD:&=±0tky@zёqBjvu`Tni?.uD]%G靯N(L@8}0, N0H_pPp`?X9K#-% %0\*TWy^ܡޖ)`"vl>F]Yq{sC`\Hu $\1Y;j)}xO嶋h56ek2lU}{XHҖm ,{b$`HIL;w7Vk1Qku%ʺJvU}:SvCzͳxUjB8&]_vc!@`>LN&v]=8@@zS" ]WA|ꔈ @kHoՃs>35+x!B=;n"`ւul2CL݌GZ+kn,%gʶA|o(I/.=e"LA11p;'`|gv㼲7a ,)to[Y+v@&NJ -я9؎m>*8iK% 3*1e+.wNF9ݶ]LJhqo՚ﭏH)&b!'^8КB!b=;2Gt|}ڒ#8n8md:%j8Kth4Kqy^?ADy("a#|mG"h*U8׫# VM -^Vԭ2'Ho4F ebT|JxbYE"۱a2 AX O΀pz; v:W%Ap6)"C[ \NO^#StS%?ⱖ%gl8v'fK8tٗ.D)t@.LC7֛eޘ%̺Bfy:-irUY>m]O3b@ILU$Q/^Z`̕fkp8LM J@8LM J@8LM5؏-]5F[ :k`T#;SmK iQ2֗CB2XzAPka@z <)$ЦX٪oƐK˩z nGr = A։X.2+/iji<ʦp.xSިiR ^]'z{UO`QY9bQ\ݪaլ1LU0= G s@z_kG "Q)}\Q{د׽ R6nzi zoGyqD#{ieas62"j/t)(H+M̮7)F4)%fRqN8R\bJ'Oe碭kΞ'O[V4ř+}1cvwV.qQg"6}4qMDNShuI@#K-GJobbf aD b,[PdE`rV-`-tQŏu S*d0 p0GdKǷْ.IΦGFA@zi ަ)   @M MqS @ @S,6U32ww@;`" l]HrhvJ-0e-T`pfu~[O n :aG+8w!zw^ |'^Z ^vT%2"=qQg@H!)trD}'Q€@Ho2#{;c "E f80F%`f+=QfOct%Td f8P PN@Zpy9|lu9\)+X&P(AmTJis8|.(2u!(u/"Y'd+xcvZ  @a5}kU؁ ԙlK7_}Iī8ljMk^8D5hүV @@ wyE$-d۸$[J_9:SL pB;Jo~WEAT@@W{mVœ"PYz&&N[K/{Fj sVx~j 1[@jVvB%E{K5H)v&TgG%)Pغj^؁ÒDˉ& ?e%gABR޽A3Լ7aC`JO5'=g,~qSR=IP{*NR߄ T! =WI<<`dA-=6)s֪RG]z r!tN`7,t; YH @ȳ<6Yr. ^ _1bsjbDF@><Ǩ7~^; > )CJyrPtEK@g;4.pF%Qk!!I1p @z)Lo\y@#)N( !@`o;Jޮc 0"]@YF[|!@>lwۈLw߲5@@ڑw|n4 P@`.H @s$9K_ @q+*/g $`?K'8@@_d͋p @&E@w->vŋq@@_| J/!Q OySkU\5L[Vn2FɅRS 4% "vW8@Vgg!U@k c}bҋ t}k". mJ,v}p]#] JJ@ 8 }p5Wq)H$K6m)h"a.ű!(nJC -mϽ{s|<_  @iVT.BLWْ7uAA".;zLGV2Y#~Y?AJO '|0Ҡ!?%H OzMۊ+E[z@$?bKX;Qw3b$x0蘟2`->WYmqȖ /pèWA.ȲvvQtN`D e?\J?%CO  k,- R;gj`rz_ru)eqk,¹1:֍dKވߪl1vMfjɨziMl4KV撇9J)9U&a=7|@YY**D-(Ԓ81BBDV%e\W_JJמ9j#mAUTJl{U.eKobfc9mj2>,]RqL;)SN5!YJ׹p7ܲJ=q]:Zѫu?HD)#92tkaNm:Y,IfwV.Cp~n5h$6kاYWl/?`v5+6㿄M9*hJgeO=q_e0R*LMg$+9_ T`S"F҇Ifj8v?K̓ŵ#-a[}g@JŁ:q)zRQ8o9v.h~Y`w\u)k8Ղ4AVfOTA.d/bqiqU)m ;;_h[ g'T@Sj?!K+R)OPvN:7@`OĻz5;:ґ5BM Tq%xe WKw*agpݲ[ fė_z[pC6ިa }<|bi]mGᜯ)JW7`iB-m;N*aڕ}ٯw*5F~ƲL,%ʸ?=/){&0  ,uy6^T L kqzRG 띬B z'^C@@z'P Ad*p @wHo5!ttA.=2NyTyF؄z#pyy^zR{,/55 Ȥ1jVRJ%,j.wogZ齺…@cY׏һ[8it _0Vוu2.yb;. eT&`7q?[nfki߃(r$+Ȭ[{$g-eDdcXLWPE>q6Kq_FrE\LK!=y! @`n9H߯>hZJWF5 |qқ9h_*HSYJac%,81ެK#֪x{*)<鵝8pTY˸r 15b_c'A7vj!/9 Qvb9GjA4Y 4*@sKSIwia_'xܾg8hɿo]:VFI7_rO Y 4+Z78.2.xfu^GF˵Gn ; D Oz-判%Rb齯v;D7Y}Оռt| Rzߙi@@?I#v;N)#RcP?}"@?~B`t:>W<  VOqpcŸ65]mDM e)"Y֔=S0@zi̖Dfj@zkP ق׬Q:YuWk+N2FwiJ֬-$f%/xO@ܻ(g5G.V5{A!{?)wɆ[6N BSIon'lB|dռ(:Z>myvB^*eɂfw޽ے؟Pzۀ@<V3*l\zsZ#At=$ҒqB!J@$ZD-XIK Kn"0ՀsV$ J ˔\jп ~_]ߗui>*`9!'ML;ȀsǕk EwOPρyNt]޶) NO=} %Mi pzH @-5ң4@mV< 6JHWA^ZN !0^]]C LNbdJc6Io/(LIP"  f{" 3:( P5QzPx&O mJ!ZJ|#'In-޼κJ",ԭEAwnD@h@"ڻ]zCAR tNZWrcs^@ !IOs®2vAT^idldž@`D)jznr|8#tW%B}=Bo>ԑ^J.=o+ު D{?z T$g.?hWF0J]guEeD%{Z'R@ 8bXKT!\[M`x0R1<9 D gԀho$Ȫ}Bz&ߤA AR1sM'{]wl~yk*}/ ! 48eΖ4#G.عh*ec=Z6!!%5æUR c h8-Moқw70id+ py2#_/aB#^[Ft>)Ö 8'~A"h(Ӿ~H'V0 6ƍmj_JNypۯXΓ^_\TSVYGz_M@{fYJ#7?7+JjIV5A\zRH7oUnzí?4 8<>T @<*뵇mm։W ,gu=BN:& "P^o-ϰ@@ƀA @` ų% @y7eB齺AA n=\T!@H/- Д7A^ @))n   @@SHoS@@zi ަ)   @M MqS @ @@z0@K 4%6Ma 6@hJm @H/m Д7A^ @))n   @@SHoS@@zi ަ)   @M MqS @ @@z0@K 4%6Ma 6@hJm @H/m Д7A^ @))n   @@SHoS@@zi ަ)   @M MqS @ @@z0@K 4%6Ma 6@hJm @H/m Д7A^ @))n   @@SHoS@@zi ަ)   @M MqS @ @@z0@K 4%6Ma 6@hJm @H/m Д7A.t }zsg>/j2@NH EL޹s'Cz$d@@"~l&L2@DzK 4%6Ma 6@hJm @H/m Д7A^ @))n   @@S4k4- @g%` 7n5| @rϔ3IENDB`tBDd l0  # AbAZEHٴwﶴx_A_ nAZEHٴwﶴx_PNG  IHDR asRGBAmIDATx^]eU[),)! &D@ hrQq*}Ј)Ā߉ƈ0<*{ "+ +cYzwjYzk:sv|c<^ {]7!I@&p_|$/A ~? @D7#nnB3on}3ozB_kZzkwLʀ"b޼ͳkwOԫnP Pg#FWIty`AttDL6=0Kڅ|d w˶_?Գؒ1!+ V OΫK(Vk\U2xv7^SOWvПD{^xKo| zJ$A IPr}V).(JpX IK^ĂVr??w-o-kK+@g#wtl?Ǐ%[O{g%s~w^y3MGh#@0bjgRgI",4UģO?7`ybpa! ` AGS|ЍZxq(=rlQ}#~q'/pg?'?=9sǿ̯՗K  ǿx>g>|xoO='ǧ~I O? p'"1ݻ*Qp'W䓢۾-/4^7ß_oo<}|p}w~_~<oo~+p'^d_|God$U|_`8›OwCҡvZFŷ{OJ"DG3{ŀD˿5$_ᐓq%eJ") L#I4uE4Oĕē;㛾O}w;DxO} WVٮs )7ɸx_ Ih-@`]Re2OTzY$XQߜYOܓZ# px?ie=3OԒDGx}#ɚD=UV_U;WI?=_\7_/yw/Ō?u 'L,~}ŷ< /KJw x_~_$! K ;Xz&UŵyD:|32?t}_}Vk1j1O|׾/蓇W\z 6@#tCO]{ @#H#h @H0A!0IF,pݿGaA80F0O 'T &^IM}**PRgK]5\ pIxG{t'  0vաtuHmLZ6@86v0妋׏dc N$]S(7F(sF x % _xʤzJ IC@g#S`q "S`] pfC3w@g @8CB$h@ Hg2>BXH$ I QG@ t$T{=2-d]>YKBJVS"]TTAHڱ3Ԓu=8f[ѹ;EG@`S'IMkƺ٫>L  prKm=fbdZ]H<e"UrsRҪA%\HSd3k H3Fb$yvSxRGjֽwdr7q"!n^4],Q'm[{61oCĘ%"Sinbgܬw Z2H,Ґ mcl3 pf&dD3Yzgޔ`Uv>v[5XI;-a:7IA1]x!0'w$ Lpf3.hUWOqjqp.Ó5҇/6 @X4Ē$Xͽ,,<ȶm6\*UM iGdg]¥J/-1mvᡇ  p$Ar^n$dtsQeruzHR_J'̕r{.Np<# kvSfJw%tԑxe>z8 C DܴAWKDs`6 p67DISn: ,fqNx I!A@ $%  I>8@`9rv px$Ç!,'@XΎO$q  H $b Ib9;ZB8<C I,gGK@'0$eU~  p`CI"p dW^)l/h.`Fvsx4C%0$B/_ .mwZc\HYFVHYQˬꡄ  fI&X8Э*s`֩Jg!UJQ2M3 '0K[LfOU32_Kwc'I@` $ =pwN9c|̟[ a7c83YĥbSmK_@)YRTZɞ%1?E-F L+dK+Gi*:M|Ǥ3Mc6 8 $ pF$3F!8 $ pF$3F!8 $ pF$3F!8 $ pF$3F!8 $ pFCI"<8y';+>C8$W^)Qj)f fPYLT_fvYqTϏߤe9uI2$(MJJ߲>n`dIlL=Ѱ #o1v~lSlj<@{g_Ǹb$ufEǯ 1f2l$d6;ǬY 4ͻ$uM4ﳨeeVS%4CgiA0S#J㥍Genb7*j:@imڰ>n=*DJ>pӎJ*]VA 9lD ;~$Z_Izrdvr&#sm@%I=|2A"F @)$jST?'҆C86ıw$ $_ 0D`(I6d!i @#£+Ƈg:Hd+g?hs yU[]q  lnt*TRt%|ZB<8VvZ@,I峓i}SCjL +i-No?MmKM%_t-JՎgeF!V!0KspWqϯIG` rs-h͟Utٿ2x5I9G7fma@`7$ޮ#},V>΋}4},@ %Ij *7#!_f@l%Eƺw]j\-$ ).#-`fR]Jlq9icHL YRIǾι'W8{H[~d  c#ARt+ 83= 8 L~S2A鸸'p8I@`OC۰P{:C_##h P!GǣGNB`(InB8-iCHmFH@8-iCHmFH@8-iCHmFH@8-iCHmFH@8-iCDxp`Ovj[ LI`(I^ݽS򺹧ޱY6:]dkBؼ u#ƶΑ]Ž=/VMDU=FFa#`yByfO]7L5ԟ/;q e* E`$)=[O/tOTfID_qDUJdYT uy-{t-V5TlW?Oeu NH4 mӼDfqAĴԵhNJH&]= ̒$9ۗA#5RA̬ZbJ.WY7i-&i۬T>SQ\VFySofDU Xr#cBP1I2=LR=eTҠ%Iĉ2ʋ7)~<#4o%^bI:,"Ʀ *j%l$+ںd3 9Yđ׳d V QbJbŽ놃_8-6uTm]Yw I]].fN ̒$e r\k}S)xlXEڬL+ODMs[eAUYc _[ؒ:t~w{{{^A>L"גpP%ʍxDH]]'>/ e/S׌WKCTzS))dCZ feUaV-I,L:hMn#\fM-]@2WYʰ~n= 2NqX*v[#ݳ!?J-7=z ,JFBbʍ ZI8_M V+Btx8@FMG_ $ P$@`p@I1@XI3  I&8 @I- I4Q@Hh@4H 5B'0$>N6'0$ui׽wJ#EzFgCOV̙s)~A/&d*wCnI"t6** @E̎c'c۸qNۖ.{Ks{~/cz$=G}퀎. %I=ݬe:|da(JtՊrm6[S2ô&:db@`ְU>o BNq9{Qa[R+GeLJJcld>fIG㙩FJT ҕ*URƊ+% u6h˵ "V%+*Yjs0i0Kޥv6q8+ ld Vus{IsĮ,I"N1rO푉RZ';=@15Ϫ"d57D4X;=ĺ D^ ׉TfISA1FP B/Tm ^1袍Gy3`< G Njhxybu%Iԗ3¥b^\H[54ptѹki[\ lnr)\28lXvz!sB7" w [R{aW#_K2A(72r*~F߈vg),k.nHsWh8 Ѭ}:y6TE2`{ A1j K3XvQH F\۟b\_XR'Rg%+E`'4pއνThaP:v - ſisG %]xxuIPɦn!mKD貊(N=61kR]MZ`;~3RV9 9$aӡҫd/,z#OV۝ KS"0Caݡn']iv5S[H.+~B"F瞏߳ $ In F6VDLF&~Zok>M=631Jک}i5;:+bM): iiwb41#3ka:+EA+)]5ʈ-aOu~e^gcF-Q^M2i:̌ Π8 j$c iSa+QrKjf6ۦKUqY/A&=+B_x;MZ5!z'zҗTxgVʼn],hQ[Ѹ`DRJ̪bvz&X]0%v٨1ce #M(R$x_Ezݴ*;n6DIܰ g*y7u0 z-84Qdezi#>%q#Y]dX0 <7m2KK)46),޲]Ms祝5NZ؄5iپ6 FjzBELmM؂^LXѵA8$va)XҌǒ )kekhE&& tkjw[yv.;iaJaS%/b0W~lY8zj]ɯԞt2Ə롊=G[6u3J$CT[u>ҘN YK8ٞV?&]N3(8lL}j͆) 7W^~)~>}{{{^A>.H$TrBd .ݥm]Զ]Ӗ ?ZnzAHa0n. LB/N`h%|.irq@ZITe@ 0Zn: ,H @ I0 @+~f p$ӄG! I3  I&8 @I- I4Q@DxGp>ߩrZ@D.ZҸBݢʥ Y.JT8&-#'+m6LO*rRp1!҆xT-j^Y#,ݬӴytDO=ï)i sMuiTwұ-恃%Ì5ԑ%Kl.4ӳm6PciѬԙ52--VMGP5zRǛ k:'6=MΔƏbץڬ(S炁 })z@c/k8j 9m%IHNӗEΏ=WBޫ iô cIKz{+$c *z ksƋڙ?FzXZ&2,IQ"?}g0m LU547OHj0d%F@ hmYk̒$@m*PVWR_7bOavIJ}:'4X>d%5@=LHCn omS-aYVzdj39ӴIA5P]taRx(Aj1sqJSMcy^Di\@^{..ZMl$@ pPEK tG%J{"[ +BN ;~ა J>w;}1XJ\&dP@]ZIT.[ yK @`u$Ցq$K< :HQ@8Hlj%@XIbu( p$O N$:RB8qb'V'@X) !Ph;(@8$8V^)jn=)JV}Sd{g9ƼKxӘuI"hI^ )6ldxuFm kɛ2f4OwxP d .ĺzsXz,IBUլ?J%lE6YԦy1SkxRnNgh=ij4xIi^i\ā!0Kx,^-Dj_RXEmj*帬Ud-UĒR@I7.duT@zET͖5%x%I ipޔTSy:w%%fwoNlFi dZ[H6*N_Ab·` ?YO7ʹl{R$52t|B{t(x2 .SK+I`$QZO(UM9;;.@VM=M%y"MƺQu~tU˚gh27R w [Rٽ+z|D%Vg'8Ԡ{:- liTx1+gBVez]G0 hȤ\E{aMsyjuj/׮#ӡ`F8Kl1vo[ep :g% f3Q?G "~ J-7=z ,J1 &0$nooC5~\5"P*u)S9{-A- %B  % @ 5 $fA 5 $fA 5 $fA 5 $fA 5 %4; $tW^)OZGS@ˤV9#JI% KklPsN+_ 2=~Q)yzdI+x&Gtc72\ȤL}/Q8)o<2'ܥ zR;b!BvPzt@ E̒$&nENM^mGRKsZu@ؓޭPlX<ǕG BZN$RmA,?kgm5,,H:J{쩐\pArWwًSwu19>5 ܄+!-lI4_W?$Tr##.բrfǸ7jd┱Vl.YS Q5VM+'7>+͛+5LJ6c ?; ^<8dWNTLtؗvϵ d'8_,It90.Bd@؁@%I=| c[ Xt^$jST?C Vx*D8$QYCCO!P8 ܁ C$ "H@'J- I4Q@Hh@4H 5B'@gF @!@8Mq@?$<“ LA`(I+{wO٬'y&X^2opgil # +'0$aӡҫ!dldI^7.6BVk4CWJ`$rEcd'u u%I ̵@e4s>U*7bKub]Țat J_'[4VdNI[] %I\ly篸|U̓"UZ(%;VĚLNmd*PToll?SۢR:Ҧ6i^#!p$ /RY3ݲȌ28nFn?MUP~HBfI_<]6JkyÞ],K&׮"m]qAg 0KhG6 .Ř4#J'zʨ- 3Bd)I5- H-"m,exX !H2IB8"acĤ*;gY#EO\BuZmK(Ҁ}uE!NH&\`GѯRp>|6|%]DI8lG`1h" ?xAc* 5fസpDXvB oV.n@H`(ITk  % B $_ 0D$1M$q !$!|4 pl$c   I 1 c I;x@`Ib!I;@CDxF`Ov2 p9CI"$[yݻ{Zs70>NE`$?N GgfIrz{Ul?2Md&z$ce5GZYS&PgY5(g)[cifX (2@,I;*s_vf⺤T%J[ݵך2O].kjiJ#+Ҭ6ʒь_Tc%I4}:LF[Ydg1ZB]*\J`O8/ 2,IiblӫN Ͷ2ۚN6]6hK_\YD LX`y?76,Ͷ%> \ذɦ 80߻-?qÏ$¿- U<;qY/e"%Qݣ_Jfyqb̖֯w PZAm@0) Φ@l/$]@ M h$rӣrt4-Cf&0$Bm*Tc<_OA %Bt팰i %Rq@'!@8Iq$%h@$H' 4nBXB$m I$M@K$P   I$и @` j p$7!,!0$ƒGxh@J;%NT mݙh5ne 2h7;9Ųu^do72z[ %0$5aӡҫ!d츉 }RF2fi/=Y,E ɺVH;8J t@`$ Xvҍ)ɚR51mOʍi-&Udt8RYybRKqXU?=kd?ʆ UK*LjKq&Y#Eќ1)k^v$oquO`$xE0""=.[C+!-e/M3ʃ@fmA.Ԥ2Ua~ţ,,72i@`JA] h#=6+V,YK1zdyF6Xj7ïX.> ̒$,l^!,)^_xjbӁ&&2pzQX6(7mb\ic1e]ua3TH^W5gqiX"0K9B !lrK4\r?虈{7S=u}_:'I)ƍA֗eQj%\$W*ȵLZb7i$0K' gD/Vɝ]jb=ʳ^1#M[gb,NgV]º½(Fna^_@ ڌ7EKO gL։u:s*6aJƤ7F[ h +]Hq1*Foo+>l<#i+Yv>B`h%|.iB @`[$*k# B`ܴ( 9 $ VAIb0` 9 $ VAIb0` 9 $ VAIb0` 9 $ VAI">UB{b$0Xt!@[=#mN<& = pI}ƒd+{wjxQye ~Ȥ;;M1m|zKqߑ\~tM2ԝ~}l+MAoOJ{k&xd}|t'Kz֒)ep>Z~xMYQrE3*OPLڍ I"kMkYTۺw AID@&I!s>ύO\t X&FnRYKUZN o8 mņU%%YnUz{FVVN, \P]X'IPiwSR& ċmRI̶ͶPUj*K6pY=<R^#,Qkju*9ꎚm- c:k:I@ .EZ{6 *$ n(!֬(Ub`ŨRY%MvJ]{ڪ)S%tİ]z:Y.lw]!|rC ?5B &!Nt)eкR󁜑VzO1ג.]gL.d+3%K3qlO俒Mz$OC86ıw$ $_ 0D$1M>* d M>@_|$ @;I ^C@J $N@E$  $ OD?3Z@8 iB $i<;ws= /lz~p1pxTf~L!Ikll#$08 HsWf @Ib``  $f@Ib``  $f@ђN9&¼)~t< :FV*Ig! ȲV3 ZFp$qar^#p$ATK'cżnչ0GJWa#]v"I| zbWz%xiF{%s{M9# [$ 2 ͭ|$,RIM*ځt]rsc,KI@H@8oh~{o'oG<I<Ƽy.={H])peuwb8dW 4N%$p9tĜԒ)h߳85$%s_TCM)rQS;~yDv(:ӊB 2Q{Bb\{j?~og$Lb ۍh>JbXrtz&T$晣yĜ U I\u0HE; &@a< m uhz។/*8T =|0{.?(5Iu.x  $ܨv@3 aG10@%׌ @( I08 @$ ~$i$Nj O$όNC$qP( ~$~f p$ӄG! I3  I&8 @I- I4Q@Hh@4H 5B'@gF @!@8Mq@?D?3Z@8 iB $i$Nj O}N_y}p/qT(mHIENDB`6X@X Normal5$7$8$9DH$OJQJ^J_HmH sH tH f@f Heading 1+&d(d@&PR5CJ\aJ\@\ Heading 2'&d(d@&PRCJaJ:@!: Heading 3@&CJaJ:@!: Heading 4@&CJaJ2@A2 Heading 5@&2@A2 Heading 6@&D@D Heading 7$@&5B*\phJ@J Heading 8$$@&a$5B*\phl @l Heading 9,h9,Third Subheading d@& CJ^JaJDA@D Default Paragraph FontVi@V  Table Normal :V 44 la (k(No List HH  Balloon TextCJOJQJ^JaJ,O, abstractO bulleted list 1z & Fh>ThTf^h`:O": abstract bulletO2 alpha list 1f & F>Th.TfBOBB bulleted list 2 ^OAR alpha list 2f & F>Th.TfBOAbB bulleted list 3 8^8Oar alpha list 3f & F>Th.Tf"O" art(O( bylineHOHcode]OJQJ^JmHnHuO code list 1v & Fh>T.Tf]^hBOB code list 2]^B'B Comment ReferenceCJaJ44  Comment Text@j@ Comment Subject5\FV@F FollowedHyperlink >*B* ph:U@: Hyperlink>*B*Y(phO" list para 1r" & Fh>T.Tf^hO!2 list para 2g#>T.Tf^:O1B: list para 3 $8^8rOr note Char Char<%hhx<$d&dNP]h^hOb numbered list 1f& & F>Th.TfBOarB numbered list 2 '^BOqB numbered list 3 (8^80O0 table code)TOT table head*@&dP5CJ\aJBOB table in list+h^hBOB table rule,&d$P$<O< table text-xCJaJ<O< table title.H5\(O( term 1/0O0 term 2 0h^h0O0 term 3 1^ZO!Z note Char Char CharOJQJ^J_HmH sH tH 4@24 Header 3 !4 @B4 Footer 4 !`^@R` Normal (Web)55$7$8$9DH$CJOJQJ^JaJ J}0h"tk &<GX4[9i 3 o!!!"%&_''j()n**>++G,-n.//~00111113450777X88:<`=|=n>>D@p@@AAIBBBDE3GG^HIKFNORU;VbVYY^\\\ ]%]*]+],]6]I]Z][]\]`]d]h]l]p]q]x]{]~]]]]]]]]]]2^W^^^^____+_@_U_m_x_y_z_~________________________``AbNcdDef?hhijelmm1p(t!vw{R}}~Rڂ,/(Tr҇ډ8I:!92T)szvٕ?49КQM\yמ 2}* /ܱ\IoĶŷ B l 6ndBfw>8cb]|Ro6-C=Nx\uJ&\}4QnY+Jh)H1g'GW#U$ m   H m  "   L<*&7JKVnoz O P [       ! !!2!3!>!]!^!j!!!!!!""G##$1&v&''()g),,J--0K0u113N6c6=89:);=??@@A_AABhC E;EEqF>GH-HIIIJlK`MMNNjO P:PPPGQQhSSSSTV#VVVVVVVGWHWLWWWW(X)X-XoXpXtXXXXYY!YnYoYsYYYYYYY.ZvZwZ{ZZZZZ[[0[1[5[\\ \)\*\.\I\]]]]]]]]]^^^^^^F_G_K______`&`'`+```````*a+a/ahaiamaaaaibjbnbbbbccccccccc4ddddaeeeeeeeeeeeef f"f(fffffffffggg-gihjhlh{hFiGiJi\iiiiipjqjjHkl;l`lyllmm nYnnnooipstwxz{R|bES݄V}׆*@fvʋ4ƌ;H@БYڒ!;=SǗ'N(N-\u' =PءHy٢3ĩ]Pf7UڮHbmyrY~ֲ QŴĶƶ1<>b0߻ μͽ.:giNrT |2R"`/gLW"%@FN?F]&UJt.>5#oi(AXEj%ex0000000000000000000  0  0  0  0 0  0  0  0 0 0 0  0  0  0  0  0 %0 0 0 00 0  0  0 0%0000 .0 0  &0  &0  &0  &0  &0  &0 0 0 00n*(0n*0>+ 0>+ 0>+ 0(0n*0/ 0/ 0/ 0/ 0/ 0/ 0/%0/0/ 0/ 0/0/0070708080800=0=0>0=0@ &0@ &0@ &0@ &0@ &0@0@0=0E 0E 0E0E0E0E0E0E0EH%0E(0E0yV0=0Y0Yx.0YX.0Y .0Y .0Y 0Y .0Y .0Y .0Y .0Y .0Y 0Y .0Y 0Y0Y0Y.0Y 0Y .0Y 0Y 0Y 0Y .0Y 0Y .0Y 0Y 0Y 0Y .0Y 0Y %0Y0=X0p^.0p^.0p^ .0p^ .0p^ 0p^ .0p^ .0p^ .0p^ .0p^ .0p^ .0p^ .0p^ 0p^ .0p^ 0p^ 0p^ 0p^ 0p^ 0p^ .0p^ 0p^ .0p^ 0p^ 0p^ 0p^ 0p^ 0p^ .0p^ 0p^ .0p^ 0p^ 0p^ 0p^ 0p^ 0p^ .0p^ 0p^ 0=0` 0`` 0`` 0`` 0 `` 0!`` 0"``(0``0}h 0#}h 0$}h 0%}hh 0&}hh 0'}hx 0(}h 0)}hx 0*}hp 0+}hp0x0}x0}0}x0}x05(05000 0, 0- 0. 0/ 00 01%0%00(050v0v0v(050_0_0_0_(050000(050000000}0%0 &0 &0 &0 &0 &0 &0 &0 &0(00I0I(00=0=(00"0"0}0%0(00̩%0̩(00Ƭ%0Ƭ(000}0B0B &0B &0B &0B &0B &0B &0B &0B &0B(0B0 02 03 040 05 060}0Ϻ(0Ϻ00 07 08 09(0Ϻ0۾0۾0۾ 0:۾ 0;۾ 0<۾ 0=۾0۾(0Ϻ000}000000v0v00 0> 0? 0@(00(000v0\ 0A\ 0B\0\0\ 0C\ 0D\(0\008000%0(0\0{0{ &0{ &0{ 0E{ 0F{ 0G{ 0{ &0{%0{0{%0{0{0{ &0{ &0{ &0{%0{0{(0\00000v0(000 &0 &0 &0800 0H 0I 0J0 0K 0L 0MH008 08 08 08 08 08 0808 08 08 08 08 08 0808 08 08 08 08 08 0808H00 0 X0 0  0 0 X0 0z 0z0z0zX0 0 0000 0N 0O 0P 0Q 0R 0S8003.03.03.0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303-03-0303%03800" 0T" 0"%0" 0U" 0" 0V" 0" 0" 0W" 0" 0" 0X" "0" "0" "0" "0" "0" "0"0"(0060606 &06 &06 &06%0606 0Y6 0Z68060[A 0[A 0[A0[A8060JE 0JE 0JE0JE8060DH0DH 0DH 0DH0DH0DH8060M 0M 0M 0M8060GPH0GP0Q 0Q 0Q8060S0S 0S 0S8060TV.0TV*0TV*0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV0TV-0TV-0TV-0TV0TV8060d.0d*0d*0d*0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d-0d-0d-0d0d00j &0j &0j 0j 0j 0j "0j &0j &0j "0j0j0j0n0n 0[n 0\n 0]n 0^n%0n 0_n%0n 0`n 0an 0bn 0cn 0dn%0n0j0(00(00(00Lj00$ 0e$ 0f$ 0g$ 0h$ 0i$ 0j$0$0$0 0k 0l 0m 0n 0o 0p 0q 0r(00$(00(00 &0 &0 &00.000$0{0{%0{0{%0{0{0{(0{0f(0{0F0F &0F &0F &0F(0{0( &0( &0( &0( "0( "0( "0((0{0 &0 &0 &000$0%0(00L(003(00 0s "0 0t "000$00 0u 0v 0w 0x 0y 0z 0{ 0| 0} 0~ 0 0 00%0(00(00 0 000(00.000.008000.00(00| "0|0$0U.0U0U(0U0(0U0 (0U00$0W%0W0W.0W0W(0W0(0W0(0W030$0'(0'0(0'0$ "0$0$0/(0/0(0/00$0I0I0I0I(0I0p(0I0`80`0  &0  &0 000 0 0(000000 0 0 0 0 0 0 0 000000 0 0 0 0 0 0 0 0 0 0 000 0 0 0 0 0 000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000 0 0 00@0@0@0@0@40@00Tg 0hFNORU;VbV*]+][]\]p]q]]]]]__y_z_______ 6-}4JKnoO P     ! !2!3!]!^!!!!!VVGWHWWW(X)XoXpXXXYYnYoYYYYYvZwZZZZ[0[1[\\)\*\]]]]]]^^^^F_G_____&`'`````*a+ahaiaaaibjbbbccccccddeeeef fffffggihjhFiGiiipjqj>;00 䲹>;00>;00>;00>;00>;00>;0 <;0<;0<;00<;00<;00<;00 H>;00 >;00 >;00 >;00 >;00 >;00 >;00 >;00 (>;00 >;0 0 >;00 >;0 0 >;00 >;00 >;00 >;00 X>;00 >;00 >;00 >;00 <;00<;00<;00>;00>;00 H<;00<;00<;00>;00<;00 >;00>;00>;00>;00>;00 >;00>;00>;00>;00>;00 >;00 >;00 (>;00 >;00 H>;00 >;00 >;00 >;00 >;00 >;00 pF>;00 >;0 0 F>;00 >;0"0 F>;00 >;0$0 S>;00 >;0&0 TS>;00 >;0(0 S>;00 >;0*0 S>;00 >;0,0 S>;00 >;0.0 x>;00 >;000 >;00 >;020 >;00 >;040 >;00 >;060 X>;00 >;080 tK>;00 >;0:0 K>;00 >;0<0 K>;00 >;0>0 L>;00 >;0@0 TL>;00 >;0B0 L>;00 >;0D0 L>;00 >;0F0 >;00 >;0H0 >;00 >;0J0  >;00 >;0L0 @ >;00 >;0N0 x >;00 >;0P0 >;00 >;0R0 >;00 >;0T0 >;00 >;0V0 X >;00 >;0X0 Ը>;00 >;0Z0 HԸ>;00 >;0\0 Ը>;00 >;0^0 Ը>;00 >;0`0 Ը>;00 >;0b0 (ո>;00 >;0d0 `ո>;00 >;0f0 ո>;00 >;0h0 ո>;00 >;0j0 ָ>;00 >;0l0 @ָ>;00 >;0n0 8>;00 >;0p0 p>;00 >;0r0 >;00 >;0t0 >;00 >;0v0 >;00 >;0x0 P>;00 >;0z0 >;00 >;0|0 >;00 >;0~0 >;00 >;00 0>;00 >;00 h>;00 >;00 >;00 >;00 >;00 >;00 >;00 >;00 P>;00 >;00 >;00 >;00  4E]xm4"OqP:# #+0:\w<4i$3'-/589<nFIJ3Oa6ede~eeegyg~gggggghlpmu!~T \ 6b-uJ&  1 &#&&'J'n'''O((()2)]))),19EHQ[G_(``naab0c)defFggh*iijklmmnnipGqprttw|EfʓH@HUڶm 0gJ>Xj     !"$%&'()*,-./123456789;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvxyz{|}~<5=]=bXXl,b$BU#4S@0(  B S  ? _Hlt38262307 _Hlt38099323 _Hlt33590756 _Hlt41151821 _Hlt41151822 _Hlt36534824 _Hlt36534825 _Hlt19092584^*_*CGG@@@@@@@@_*`*DGG+#R*C#Rl*C#Rd >#R\+C#R @#R|E#R C#RlC#RC#RC#RC#RC#R, C#R&C#Rd#RdC#R@#R+=#RL,=#RX#R+*urn:schemas-microsoft-com:office:smarttags PersonName8*urn:schemas-microsoft-com:office:smarttagsdate8)*urn:schemas-microsoft-com:office:smarttagstime<*urn:schemas-microsoft-com:office:smarttagsmswterms=*urn:schemas-microsoft-com:office:smarttags PlaceName=*urn:schemas-microsoft-com:office:smarttags PlaceType9*urn:schemas-microsoft-com:office:smarttagsplace 12142200121285DayHourlsMinuteMonthtransYear++) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) ) )       )   )   )     )   @*e*11UU;VKV>GrGsGGGHH,Hfj''11;;(B,BTGUGKINI UU[]\\\^^Z|`|X\VZ[aAGqTYEN//.2/233q@s@>GHH,HVVhereoowwxy~~VX#&]dĸҸûɻAL }333333333333333333333333333333333333333333333333333333 *!*E*E*l*l*>+P+d+d+..11555556 66]7j777==F3GU:V\`]c]d]g]h]k]]^_``+cNcefhhhhttttttttցׁށ߁Tr8I./33^^נؠNNff55NN֮ͫޮ 6f] AXXzz)*\EFKOHYHKz P [      !>!^!j!!!tNNVVHWLWWW)X-XpXtXXXY!YoYsYYYYYwZ{ZZZ[[1[5[\ \*\.\]]]]]]^^^^G_K____`'`+`````+a/aiamaaajbnbbbccccccddeeee f(ffff-gjh{hGi\iii`lloo{{@fvʋʌʌьҌیی huڒ$1;\u*H7UHĶ߻VW5<i(A%8xx)W?^-.4m ^-RZmdGYmd'Kmdn(zzNDa X'mdX)^-60md|K3z0W4md=6mdZ!]!^!j!!!!!!VVVVVGWHWLWWWW(X)X-XoXpXtXXXXYY!YnYoYsYYYYYYYvZwZ{ZZZZZ[[0[1[5[\\ \)\*\.\]]]]]]]]]^^^^^^F_G_K______`&`'`+```````*a+a/ahaiamaaaaibjbnbbbbcccccccccddeeeeeeeeeeef f"f(fffffffffggg-gihjhlh{hFiGiJi\iiiiipjqj@//09//@UnknownAuthorGz Times New Roman5Symbol3& z Arial5& zaTahoma71 Courier?5 z Courier New;Wingdings"1htfv׳u*II!4d 2qR?Account Lockout Whitepaperh                  Oh+'0  0 < H T`hpxAccount Lockout Whitepaperccoccocco Normal.dotkorm42mMicrosoft Word 10.0@ U@:ֳ @n@D> >IMicrosoft Contributors 0 < H T`hpxAccount Lockout Whitepaperccoccocco Normal.dotkorm42mMicrosoft Word 10.0@ U@:ֳ @n@D> >IMicrosoft Contributors8 _PID_HLINKS_AdHocReviewCycleID_PreviousAdHocReviewCycleID_ReviewingToolsShownOnceA  Rhttp://www.somarsoft.com/b#(http://support.microsoft.com/?id=817701DJ~GRev  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./012456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F+>Data 1Table3WordDocument"JSummaryInformation(DocumentSummaryInformation8CompObjj  FMicrosoft Word Document MSWordDocWord.Document.89qRoot Entry F0aData 1Table3WordDocument"J  _PID_HLINKS_AdHocReviewCycleID_PreviousAdHocReviewCycleID_ReviewingToolsShownOnceA  Rhttp://www.somarsoft.com/b#(http://support.microsoft.com/?id=817701Oh+'0 SummaryInformation(DocumentSummaryInformation8CompObjj  FMicrosoft Word Document MSWordDocWord.Document.89q՜.+,D՜.+,\ px  ee Account Lockout Whitepaper Title