More on Euro DEC Part Deux..

One of my favorite sessions was given by Jorge de Almeida Pinto, a well known DS MVP, whose blog is one of the most interesting reads on AD on the web.

His talk was on Read Only Domain Controllers (RODCs); what they are and the challenges in managing them. I'll try and give a précis of his session here.

The challenges RODCs attempt to resolve are:

• DCs in insecure locations like remote branch offices
• Storage of credentials on DCs in these locations
• Non-Domain Admins might be delegated tasks on the DC or manage a server role or LOB applications

All these could potentially compromise the security of Active Directory.

Even with the "read only" nature of an RODC, it is NOT the same as an NT4 BDC:

• An RODC should always be considered as Untrusted.
• Its main goal is to improve security and mitigate risk
• Role is promoted and not assigned (like the GC role)
• Preferred in perimeter networks
• Still need to be managed with patches, hotfixes and backup.

To tell you how different they are:

• They have an RODC “filtered attribute Set” ; a negative list of attributes not replicated to RODCs
• The Krbtgt account is unique for each RODC. So it can issue its own Kerberos tickets without compromising domain security.
• They are not members of “strong” security group memberships like Enterprise Domain Controllers.

Prerequisites for installing RODCs

- Forest Functional Level 2 (WS03)

• This is required for:

1. Constrained Delegation for Replication
2. Linked Value Replication

- ADPREP/RODCPREP

• Executed on the Domain Naming Master FSMO (not mandatory, but preferred as it contacts this FSMO role)
• Updates the permissions on application partitions for an RODC to be able to participate in replicating those (contacts an application partition replica)
• Only needed when upgrading from W2K3 AD, not W2K AD (W2K does not support app partitions).

In earlier betas, there was a requirement for the WS08 DC, which must exist, to be the PDC FSMO role holder. This is no longer the case in the RC0 release. Can be any writable WS08 DC.

Installation is by GUI or the Command Line using DCPromo.

Issues regarding Installation of RODCs

• The delegation of the permission to install an RODC cannot be done securely. Don’t do it.
• Trust people who install RODCs!
• Use a 2 stage process instead:
• Trusted Admin Installs RODC
• Delegated Admin joins to domain

RODCs can be Installed From Media

• Passwords can be removed
• Attributes belonging to the Filtered Attribute Set are removed
• Media valid: Best Before < Creation date + Tombstone Lifetime

RODCs only replicate their own Domain NC with a WS08 DC

• Reason is: WS03 DCS do not recognize the WS08 RODC password policy (they are unable to restrict the replication of certain passwords).

The Challenges

• Unidirectional Replication. No changes (AD DS & DFS) are written to the RODC therefore writable DCs that are replication partners do not have to pull changes from the RODC and do not create inbound replication objects from RODCs (less work for Bridgehead servers).
• This can create an inconsistent view of replication connection objects depending on which DC has the focus.
• No automatic deletion of Lingering Objects on an RODC. Use: Repadmin /removelingeringobjects
• RODC “Filtered Attribute Set”
• Set of attributes in the schema for domain objects that will not replicate to an RODC
• If DC is compromised and it tries to replicate attributes defined in the filtered attribute set from a WS08 DC, the replication request is denied.
• If the DC tries to replicate from a WS03 DC, the request CAN succeed.
• MAKE SURE FOREST IS AT FFL3 IF YOU WANT TO USE RODC FILTERED ATTRIBUTE SETS
• System-critical Attributes cannot be added to the RODC filtered attribute set (a system-critical attribute has a schemaFlagsEx attribute value equal to 1)
• LDAP writes to an RODC are referred to a writable DC; even to a WS03 DC.
• More than 1 RODC in a specific site will lead to inconsistent logon experiences and is not supported.

Special Write action on an RODC:- password changes

1. User in site with RODC changes password
2. RODC refers password change to writable WS08 DC
3. RODC inbound replicates the password using the “replicate single object” method.

RODC caches, by default, 2 passwords:

1. The RODC computer account password
2. The Kerberos account password

If an accounts password is not cached and the user tries to logon, the request is referred to a writable DC.

2 minutes later, or thereabouts, the RODC tries to inbound replicate the password from a WS08 DC which recognises the request is from a RODC and consults the Password Replication policy in effect for the RODC.

The Password Replication Policy determines if the creds can be replicated to the RODC and if so, the writable WS08 DC sends the creds to the RODC.

Next time the user tries to logon, the RODC services the request and signs the users TGT with its krbtgt account. Till the users password changes.

When a TGT is signed with the RODCs krbtgt account, the RODC knows it has a cached copy of the creds. If another DC signed the TGT, the RODC refers the request to a writable DC.

By limiting Credential caching to only users and computers who have logged on to the RODC, the potential risk to the Forest is limited.

Managing Password Replication Policy

1. Using ADUC on a writable WS08 DC – properties of the RODC computer Account, the PRP tab
2. Repadmin /PRP

To force replication: Repadmin /rodcpwdrepl

To remove a password from a RODC:

Because an RODC is considered untrusted, the concept that a password can be “removed or purged” from it is insecure.

1. Change/reset/expire the password immediately
2. Or wait for it to expire.

When caching accounts on an RODC make sure Computer and user accounts for the site are cached.

How to Deal with a Compromised RODC

When a RWDC is stolen, the immediate threat is all account credentials in the forest can be compromised.

Ulf backed this up by informing of a test he ran for a bank which showed they could crack all passwords of varying complexity and less than 8 chars in length within 2 hrs

To attempt to recover from the loss of a RWDC, you have to:

1. Clean the metadata of the stolen DC
2. Reset the password of all user accounts in the Domain
3. Reset the domain wide KRBTGT account twice.
4. Reset all DC accounts, all server accounts, all client accounts and all trust. Twice.

All very hard work and you still need to be aware of synched accounts or passwords in other Apps, systems, Domains or Forests.

To recover from a compromised RODC, you have to:

1. Delete the krbtgt_instancename account of the RODC
2. Cleanup AD metadata
3. Reset all cached user and computer accounts

And all this can be done from the ADUC mmc when deleting the RODC account. The cached user and computer accounts can also be exported to a file.

With these RODC concepts, it can be seen how the branch office infrastructure is being better secured whilst trying to improve management.

Microsoft, we hear, are even experimenting with the idea of having an RODC on the Internet. All good stuff I say!