(2008-03-21) Switching Between A RODC And A RWDC
Posted by Jorge on 2008-03-21
A DC (for both RODCs/RWDCs) can be (un)assigned the GC role by just configuring a checkbox in Active Directory Sites And Services or using REPADMIN or some other tool that configures the feature. To switch between a RWDC and a RODC (or the other way around), you must always first demote, reboot and promote to whatever you want.
However, the RODC is untrusted. The RWDC is very trusted. From a security perspective I do not recommend to promote any server to a RWDC that was an RODC or a member server when:
- it was previously managed by a non-domain admin
- the server did not have any physical security
- the server was from a network perspective located in an unsecure network segment
- everything else that is non-trusted or insecure
Why? Because if the member server or the RODC has been compromised before the promotion, the person/thing (probably a hacker or a non-Domain Admins or malicious software) causing the compromise can become a domain/enterprise admin by using the power of the RWDC after the promotion to a RWDC.
So, if you do not trust the member server and/or the RODC that should become a RWDC, rebuild it from scratch! And after doing all this, don’t allow physical access or interactive logon access to ANY non-Domain Admin for ANY RWDC. The same is true for backups, snapshots and IFM sets from ANY RWDC!
I would not have any problems when the switch goes from a RWDC to a RODC. But, what is the world without having good friends watching over your shoulder? Thanks Dean!
I was made aware of a scenario that could occur when you want to switch from a RWDC to an RODC. "Now what" you may thing? Well, during the demotion of the RWDC to a member server or a stand alone server the writable NTDS.DIT file is removed/delete. So? Let’s say it becomes a stand alone server and the Domain Admin wants to replace the RWDC with an RODC using a staged (delegated) demotion . The Domain Admin performs the first stage by pre-creating the RODC objects in AD and delegated the second stage to a NON-Domain Admin. The NON-Domain Admin logs to the stand alone server for the second stage. The NON-Domain Admin hates the other Domain Admins because he is not a Domain Admin or for whatever reason he would do anything to become one or just do some damage to the environment. Because the Domain Admin knows the stand alone server WAS an RWDC, the NTDS.DIT is still on the hard disk of the server and could be recovered using whatever UNDELETE/RECOVERY software that recovers deleted/lost files. From the recovered NTDS.DIT he could hack his way into the NTDS.DIT and extract the password hashes. Having the password hashes he could crack the password hashes to real passwords and misuse them. But why all the trouble and work? Why not just use the password hash with a "RUNAS-like" tool? That kinda software is also available on the internet!!! In the end he is able to misuse the password hash of the Domain Admin accounts and do all kinds of stuff that can turn into one heck of a nightmare!
So what can you do? After the demotion of the RWDC, do not hand-over the server to the NON-Domain Admin right away. Use the CIPHER tool (by default in the OS) to really remove data from unused disk space. The command for that is: CIPHER /W:<(Top)Folder that contained the NTDS.DIT>
 Regarding staged/delegated promotions for RODC see my slides from DEC 2008 and TechDays 2008 which you will find on my blog in different posts
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########