Active Directory RODC password 저장 방법

한국에서는 거의 사용하지 않는 RODC(Read-Only Active Directory)는 기본적으로 RWDC가 존재해야지만 운영이 가능한 AD 시스템 입니다. RODC 단독으로 사용이 불가능한 이유는 RODC는 기본적으로 사용자 Password 정보를 cache 하지 않도록 되어 있기 때문 입니다.

또한 처음 계획대로 RODC를 배포 했다가 RODC 배포 장소의 규모나 역활이 벼경되어 RODC를 RWDC로 변경해야할 경우 보통 AD 서버를 재설치를 통해 RWDC로 변경을 많이 합니다. 이런 부분 때문에 RODC 사용은 가급적 하지 않았던게 사실이고, 가끔 RODC를 배포 후에 다시 RWDC로 전환을 위한 문의가 많은 편 입니다.

이와 관련해서 약 9년 전에 MS Directory Services Team에서 아래와 같이 해결 방법을 제시하고 있어 AD 재설치를 통한 RWDC 전환 이외에 다른 방법을 제시해주고 있어 많은 도움을 받았던 기억이 있습니다.

Reference Site: https://goo.gl/CxW4KH

아래 내용은 위 Reference Site 내용을 발췌한 내용으로 참고 하시기 바랍니다.

Hello there. Bob Drake here to discuss how Windows Server 2008 “Read Only Domain Controllers” (RODC’s) authenticate users differently from the way Windows Server 2003 and Windows Server 2008 standard domain controllers do. The “Read Only Domain Controller” is new to Windows Server 2008 and allows for the installation of a domain controller to accommodate common scenarios where users are authenticating over a wide area network (WAN) or there is a physical security concern for the domain controller, such as installations at branch office locations. Another new feature to Windows Server 2008 RODC’s is “Password Replication Policy” and depending on how they are configured determines how an RODC authenticates a user.

To understand the authentication difference between a standard domain controller and an RODC, we need to review the “How interactive Logon works” and “Kerberos authentication” TechNet articles. In the section Domain Login (How interactive logon works article), a user’s credentials are received by Winlogon and passed to the LSA (local security authority) which negotiates Kerberos and contacts the domain controller. The domain controller then returns the logon success to the local computers LSA which generates the user’s access token. The Kerberos authentication is seen in the following diagram (taken from the Kerberos authentication article):

To see the authentication on the wire, we would need to install a network capture application such as Netmon3.1 (or Wireshark, Ethereal, Packetyzer). In the following network trace, we see a client machine authenticate to a domain controller and is granted access with the “KRB_AS_REP” and “KRB_TGS_REP”:

Now let’s take a look at the “Password Replication Policies” and how they affect the RODC authentication behavior. With the installation of an RODC, there are four new attributes and two built-in groups to support RODC operations:

• msDS-Reveal-OnDemandGroup. This attribute points to the distinguished name (DN) of the Allowed List. The credentials of the members of the Allowed List are permitted to replicate to the RODC.

• msDS-NeverRevealGroup. This attribute points to the distinguished names of security principals that are denied replication to the RODC. This has no impact on the ability of these security principals to authenticate using the RODC. The RODC never caches the credentials of the members of the Denied List. A default list of security principals whose credentials are denied replication to the RODC is provided. This helps ensure that RODCs are secure by default.

• msDS-RevealedList. This attribute is a list of security principals whose passwords have ever been replicated to the RODC.

• msDS-AuthenticatedToAccountList. This attribute contains a list of security principals in the local domain that have authenticated to the RODC. The purpose of the attribute is to help an administrator determine which computers and users are using the RODC for logon. This enables the administrator to refine the Password Replication Policy for the RODC.

• Allowed RODC Password Replication Group. This group is added to the msDS-Reveal-OnDemandGroup.

• Denied RODC Password Replication Group. This group is added to the msDS-NeverRevealGroup.

Note: The “Allowed RODC Password Replication Group” has no members by default, and the “Denied RODC Password Replication Group” contains all the ‘VIP’ accounts (Enterprise Administrators, Cert Publishers, Schema Administrators, Etc). As with most things, Deny always trumps Allow.

Using the commands for “Repadmin.exe” (this is built into Windows Server 2008) an administrator can modify the Password Replication Policy groups. To view the current PRP for a specified user:

Repadmin /prp view <RODC> {<List_Name >|<User>}

The following shows the settings for the groups on the RODC through several commands:

Awesome information here! We can see who is on the allowed list (msDS-RevealOnDemand), who is on the deny list (msDS-NeverRevealGroup), who is actually revealed (msDS-RevealedList) and who actually has authenticated to the RODC (msDS-AuthenticatedToAccountlist).

The configuration of a Password Replication Policy is pretty straight forward. Open Active Directory Users and Computers snap-in and select the RODC in the Domain Controllers organizational unit. On the “Password Replication Policy” tab, there are the two groups: “Allowed RODC Password Replication Group” and “Denied RODC Password Replication Group”. A user can be added to either of the desired groups.

Another really cool feature is the “Prepopulate the password cache for an RODC” button. This button (pictured) allows an administrator to pre-add users that will be authenticating to the RODC.

An administrator could also use the “Repadmin” utility to populate the password cache with the following command:

Repadmin /rodcpwdrepl [DSA_LIST] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished name> <User2 Distinguished Name>…].

The following shows the user “Ned Pyle” being added to the password cache using Repadmin:

So how does this affect the RODC? When a user authenticates to an RODC a check is performed to see if the password is cached. If the password is cached, the RODC will authenticate the user account locally. If the user’s password is not cached, then the RODC forwards the authentication request to a writable Windows Server 2008 Domain Controller which in turn authenticates the account and passes the authenticated request back to the RODC. Once the user account is authenticated, the RODC makes another request for the replication of the user’s password in a unidirectional replication providing the account has been configured to allow replication.

This finally brings us to seeing the difference in authentication. For the following NetMon 3.1 trace, I have configured a user account whose password has been denied replication to the RODC. The user authenticates to the RODC (2k3DOM2k8DC2) and the RODC forwards the request to the writable domain controller (2k3DOM2k8DC). We see the extra traffic since the user’s password has not been cached:

For the last trace I have allowed the user password to be cached by configuring the Password Replication Policy. The user authentication is the same as above, with the exception to what the RODC does after authenticating the user. Now see the RODC make the request for the user’s password to be replicated, but in subsequent logins the password replication request would not be seen since it has been cached:

Note: If the Wide Area Network (WAN) is down and the user account and password has NOT been cached, then the user account will fail to authenticate.

To wrap it up, when a user account is not cached, the RODC forwards the authentication to a writable Domain Controller which does the authentication. If the Users password is allowed to be cached, then the RODC will pull that through a replication request. Once the user has been authenticated, and their password has been cached, any subsequent login can then be handled by the RODC alone. Some people may see an increase in Wide Area Network (WAN) traffic with the introduction to an RODC, but after caching user passwords there should be a significant reduction in traffic and a more secure environment. In my next blog I will discuss how account lockout thresholds affect this process and what Administrators might run into with them.