Read-Only Domain Controllers and Account Lockouts

Hello again - Bob Drake here. Today I will be talking about a particular behavior with account lockouts that might be seen with the introduction of “Read-Only Domain Controllers” (RODC's) in Windows Server 2008. Windows 2008 RODC’s are domain controllers that can authenticate users and computers, but hold a read-only copy of Active Directory. This means that any changes (or writes) made to Active Directory must then be forwarded to a writable domain controller. Traditionally, account lockouts happen for many different reasons; with RODC’s there are a few added layers of potential issues that can complicate the efforts of resolving lockouts.

The first step in understanding account lockouts is to thoroughly read through our TechNet whitepaper “Windows Server 2003 Security Guide”. In this guide, Microsoft points out the recommended settings to have a secure lockout policy. Unfortunately many customer implementations are configured with settings that cause “false lockouts”. The information suggested in this document is applicable to all Active Directory versions, not just 2003. False lockouts are accounts that lock out due to user error rather than application error. For instance, the recommended “lockout threshold” is to be set at 10 or higher:

“Account lockout threshold setting value to 50 for the Legacy Client and Enterprise Client environments, which should provide adequate security and acceptable usability. This value will prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack as described earlier. However, this guide recommends that you configure this policy setting value to 10 for Specialized Security - Limited Functionality environments.”

Traditionally floods of false account lockouts are resolved by installing the “account lockout tools” and following the steps outlined in the TechNet article which describes how to use the tools.

** Special note here: Do NOT install the Account Lockout DLL on an Exchange server since it may prevent the Exchange store from starting **

Once the tools are installed you can view the properties of the account password information directly on the user object in Active Directory Users and Computers:

As seen it matches what the default domain policy is set to:

In normal 2003 environments users authenticate with a local domain controller within their site. With the introduction of RODC’s, the authentication is a little different. There is a new password feature built into Windows Server 2008 called “Password Replication Policies”. The particular thing to point out from this article is:

“An administrator can, for example, specify in advance any accounts that an RODC will cache. This way, the RODC can authenticate those accounts, even if the WAN link to the hub site is offline.”

• If an account password has been allowed to be cached, then they can authenticate even if the WAN link is down.
• If an account password has not been allowed to be cached, then they will not authenticate if the WAN link is down.

I recommend extensive consideration and planning to determine the best solution for which accounts will be cached with considerations given to WAN links and reliability. Pay particular attention to the three solutions:

• No accounts cached
• Most accounts cached
• Few accounts cached

When a user logs into a computer located in a site where there is an RODC and the user’s password is not cached, the RODC in turn will make a request to a writable Windows Server 2008 domain controller (For more information on RODC’s and how they differ from writable domain controllers). If this writable DC is out of site and possibly over a WAN link, this could become a bandwidth issue, and potentially cause logon failures if it is an unreliable link. See the section “Password Replication Policy in operation . If the users password is allowed to be cached, after authenticating the user, the RODC with then requests a password replication and pulls the password into cache. There are a couple of cool methods on pre-populating the password cache:

• Method 1: Open Active Directory Users and Computers from a writable domain controller, right click the RODC and go to properties. Select the “Password Replication Policy” tab then the advanced button. Once the next box opens, user accounts can be added by using the “Prepopulate Passwords” button and selecting the users from Active Directory:

• Method 2: Using the “Repadmin” utility from the support tools (this tool is built into Windows Server 2008 but can be downloaded for Windows Server 2003 here), and run the following syntax:

repadmin /rodcpwdrepl [DSA_List] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished Name> <User2 Distinguished Name> …]

Success!

Cool Tip: If you have set up an RODC or you are taking over an RODC implementation and want to manage the users that have been authenticated to it with as little administration as possible you can use the “Repadmin” command to make your life easier:

Repadmin /prp move <rodc> <group>

The move command will send all the security principals from the “Authenticated to” list to the specified group that you name. If the group that you name does not exist, it will create the group on the fly, and also adds the group to the “Allowed List”… check it out:

Notice that it asked to move all the security principals from the “auth2” list to the group I created “2008authlist” and created the group for me. This allows me to keep track of who authenticated in 2008, and manage that group automagically by sending all the users who authenticated to my RODC to a security group that I can control. From here I can run an LDIFDE command against the new security group and output its contents for auditing purposes:

Now getting to the account lockout portion and what administrators may run into. Let’s take a look at the following potential scenario:

• User who has not been able to cache their password since a WAN link was down (IE: an executive visiting an offsite branch location)
• The account lockout threshold is set at “3” on the Default Domain Policy.

NOTE: I went with the account lockout threshold set at three (3) to show that when the threshold is set lower than the recommended setting of 10, there is a potential for false lockouts to occur. In this scenario the WAN link goes down, and the user tries their password more than 3 times incorrectly, causing the account to lock out. The real problem was not the threshold but the WAN link, but since the threshold was set too low, another issue happened.

• The WAN link from the remote site goes down and the only available domain controller is the RODC

No user passwords are cached on the 2008 Core RODC as seen:

User “Bob Drake” logs attempts to log into the RODC when the WAN link is down and gets the following:

First problem: Since the RODC needs a writable Windows Server 2008 Domain Controller, it fails the authentication and gives the error that the domain is not available.

Second Problem: Since we chose not to cache the user’s password in advance the user fails to log in.

To address the issues, and administrator changes the “Password Replication Policy”, allows for the user account password to be cached and resolves the broken WAN link:

So the user “Bob Drake” logs in again successfully and the password is cached:

Now going back to the scenario, let’s say that the WAN link goes down (remember our account lockout threshold was set at 3) and the user types his password wrong three times causing his account to be locked out on the RODC. Note that it does not show in the GUI on any of the domain controllers:

2008 standard domain controller:

2008 RODC:

From the users view of his account that is locked out:

If we connect to the RODC using ADSIEDIT and take a look at two accounts side by side, we can see that the user account “Bob Drake” is locked out even though normal tools do not show it:

Note: The “LockoutTime” is stored in NT System Time format. To convert to a readable format you can use the w32tm command (w32tm /ntte):

When this occurs, there is no way to “unlock” the user’s account using normal methods like Active Directory Users and Computers. This is a unique case now since the user will be complaining that his account is locked out, but the administrators that look at the account do not see it as locked account. Other users continue to work (as long as the passwords were cached) providing they have not attempted three bad passwords making it appear that there is no other issue expect the account authentication lockout. A domain administrator would look at this and may be stumped on how to unlock the account.

To get the account unlocked the WAN needs to be restored, which will allow for the user to authenticate again without doing anything else. Under normal account lockout methodology, the user’s bad password count would normally get replicated to the other domain controllers in the environment, but not the case here. Simply restoring the WAN link will then reset the bad password attempt to zero (0) and the account will no longer be locked out, allowing the user to attempt login again.

In a situation like this where a company has implemented a RODC in a branch site, has a restrictive password policy set at the domain level, or an unreliable WAN link - they might want to consider creating an alternate “Fine Grain Password Policy”. This will allow a policy to be set that has a higher account lockout threshold than the default domain policy as well as a higher precedence. This way, when users at the branch office mistype their password more than three times, it will not lock the account out like the rest of the domain (or at least till they hit the higher threshold).

New OU Fine Grain Password Policy with higher threshold and precedence:

To conclude, I highly recommend reading through the documentation about implementing Read-Only Domain Controllers (and possibly how site topologies work). If you know you have an unreliable WAN link, or there are strict password policies set at a domain level, you may want to reconsider the implementation of an RODC to accommodate your environment and make the RODC transition go smoothly.

-Bob Drake