You can specify a delegated RODC administrator during an RODC installation or after it.
During the RODC installation, you can set the name of the
account in the Active Directory Domain Services Installation Wizard, at
the command line, or in an answer file. In the wizard, set the name of
the account on the
Delegation of RODC Installation and Administration
page, as shown in the following figure. If you are performing a staged
RODC installation, this page appears when you precreate an RODC account.
For more information about precreating an RODC account, see see
Performing a Staged RODC Installation (
http://go.microsoft.com/fwlink/?LinkID=103323)
If you are installing an RODC at the command line or by using an answer file, add the
/DelegatedAdmin parameter to specify the delegated RODC administrator.
To specify the delegated RODC administrator after installation, you can use either of the following options:
-
Modify the Managed By tab of the RODC account
properties in the Active Directory Users and Computers snap-in, as shown
in the following figure. You can click Change to
change which security principal is the delegated RODC administrator. You
can choose only one security principal. Specify a security group rather
than an individual user so you can control RODC administration
permissions most efficiently. This method changes the managedBy
attribute of the computer object that corresponds to the RODC to the
SID of the security principal that you specify. This is the recommended
way to specify the delegated RODC administrator account because the
information is stored in AD DS, where it can be centrally managed by
domain administrators.
-
Use the ntdsutil local roles command or the dsmgmt local roles
command. You can use this command to view, add, or remove members from
the Administrators group and other built-in groups on the RODC. For more
information about syntax and examples for using this command, see local
roles (http://go.microsoft.com/fwlink/?LinkId=120147).
Using
ntdsutil or
dsmgmt
to specify the delegated RODC administrator account is not recommended
because the information is stored only locally on the RODC. Therefore,
when you use
ntdsutil local roles to delegate an administrator for the RODC, the account that you specify does not appear on the
Managed By
tab of the RODC account properties. As a result, using the Active
Directory Users and Computers snap-in or a similar tool will not reveal
that the RODC has a delegated administrator.
In addition, if you demote an RODC, any security principal that you specified by using
ntdsutil local roles
remains stored in the registry of the server. This can be a security
concern if you demote an RODC in one domain and then promote it to be an
RODC again in a different domain. In that case, the original security
principal would have administrative rights on the new RODC in the
different domain.
You can only specify one security principal to be the
delegated RODC administrator. As a best practice, you should create a
security group for each RODC and assign that group to be the delegated
administrator. Then, you can add individual user accounts to the group,
and each user can manage the RODC.
Using a security group helps you manage administrative
permissions on the RODC more effectively and helps you avoid logging on
to the RODC by using privileged account.
For example, suppose that you have two RODCs named RODC1 and RODC2, as shown in the following table.
Server name
|
RODC1
|
RODC2
|
Managed by
|
RODC1Mgrs
|
RODC2Mgrs
|
Members
|
StanB (the name of a user account in this branch)
KarenC (the name of another user account in this branch)
|
PeterH (the name of a user account in this branch)
DavidK (the name of another user account in this branch)
|
In this example, RODC1Mgrs and RODC2Mgrs are the
respective security groups that are the delegated administrators for
each RODC. The membership of each group is comprised of the appropriate
user accounts from the respective branch office.
Typically, a domain administrator can manage an RODC
remotely without logging on to the RODC directly. In the rare case that a
domain administrator must log on to an RODC, the administrator should
create a temporary domain user account just for that purpose and add it
to the delegated RODC administrator group account. The administrator can
log on to an RODC using that domain user account instead of a domain
administrator account and eventually delete the temporary account
afterward for improved security.
Because you will deploy RODCs in locations where they
might be compromised, you should manage them in the same way as you
manage other potentially nonsecure computers. Always treat an RODC as
though it is not secure. You should never log on to it—locally or
remotely with Terminal Services, by using highly privileged
credentials—such as Domain Admins or Enterprise Admins.
An attacker can use a compromised RODC that has a highly
privileged account password to perform malicious operations in the
forest. Even use of a smart card cannot mitigate the logon risk because a
compromised RODC would have access to the security context and could
use it maliciously.
It is not necessary for a compromised RODC to have cached
the password of a privileged account to use that account maliciously.
In addition, you do not want an administrative workstation to be
authenticated by an RODC that you do not trust. Although you cannot
control which domain controller authenticates the administrative
workstation, RODCs do not register service (SRV) resource records for
other sites. As a result, RODCs do not authenticate workstations from
other sites. If the administrative workstation that you log on to is not
in a site with an RODC, it cannot be authenticated by an RODC.
Therefore, as a best practice, you should not log on to any workstation
with a privileged account in any site that has an RODC—or log on to an
RODC locally—unless you fully trust the RODC.
So that the delegated RODC administrator can log on to
the RODC when the wide area network (WAN) link to the hub site domain
controller is not available, the delegated RODC administrator account
password must be cached on the RODC. Note that the delegated RODC
administrator account is not allowed to be cached on an RODC by default.
Therefore, you have to modify the default PRP to allow the password to
be cached, cache the password, and the recache it after every password
change for successful logon to the RODC when the WAN is not available or
a writable domain controller cannot be contacted. You must do this for
every member of the security group that you specify as an administrator
of the RODC.
Note 
This method of using WSUS is also appropriate for
organizations that have high-cost or low-bandwidth links to the
Internet. Downloading updates for all Microsoft products throughout an
organization can be bandwidth intensive. This method enables
organizations to download updates one time and then distribute updates
locally by using inexpensive removable media. For more information about
this scenario, see 
Tip 
You can also use the repadmin /prp command to delete the security principals from the msDS-AuthenticatedToAccountList attribute or from the msDS-RevealOnDemandGroup
attribute that is associated with the RODC. Note however, that this
action only clears the value from the attribute; it does not clear the
cache on the RODC.