Read Only Domain Controllers

What Is an RODC? 

Read-only domain controllers (RODCs) are a new feature of Active Directory Domain Services (AD DS) in Windows Server 2008. RODCs are additional domain controllers for a domain that host complete, read-only copies of the partitions of the Active Directory database and a read-only copy of the SYSVOL folder contents. By selectively caching credentials, RODCs address some of the challenges that enterprises can encounter in branch offices and perimeter networks (also known as DMZs) that may lack the physical security that is commonly found in datacenters and hub sites. RODCs also offer a number of manageability improvements that are described in this guide. This section describes how RODCs work with the rest of the Active Directory environment, the main differences between RODCs and writable domain controllers, and the RODC features that can help resolve a number of security or manageability issues.

Prerequisites for Deploying an RODC 

 Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012   Ensure that the forest functional level is Windows Server 2003 or higher, so that linked-value replication (LVR) is available. This provides a higher level of replication consistency. The domain functional level must be Windows Server 2003 or higher, so that Kerberos constrained delegation is available. If the forest functional level is Windows Server 2003, the domain functional level of all domains in the forest is Windows Server 2003 or higher.  Constrained delegation supports security calls that must be impersonated under the context of the caller. Delegation makes it possible for applications and services to authenticate to a remote resource on behalf of a user. Because it provides powerful capabilities, typically only domain controllers are enabled for delegation. For RODCs, applications and services must be able to delegate, but only constrained delegation is allowed because it prevents the target from impersonating again and making another hop. The user or computer must be cacheable at the RODC for constrained delegation to work. This restriction places limits on how a rogue RODC may be able to abuse cached credentials.  Run Adprep.exe commands to prepare your existing forest and domains for domain controllers that run Windows Server 2008 or Windows Server 2008 R2. The adprep commands extend the Active Directory schema and update security descriptors so that you can add the new domain controllers. There are different versions of Adprep.exe for Windows Server 2008 and Windows Server 2008 R2. For more information, see Running Adprep.exe (http://go.microsoft.com/fwlink/?LinkID=142597). 

   1.  Prepare the forest and domains. There are three adprep commands to complete and have the changes replicate throughout the forest. Run the three commands as follows:             >>>>>  Prepare the forest by running adprep /forestprep on the server that holds the schema master operations master (also known as flexible single master operations or FSMO) role to update the schema.         >>>>>>   Prepare the domain by running adprep /domainprep /gpprep on the server that holds the infrastructure operations master role.      >>>>>>>  If you are installing an RODC in an existing Windows Server 2003 domain, you must also run adprep /rodcprep. 

2. Install Active Directory Domain Services (AD DS). 

Deploy at least one writable domain controller running Windows Server 2008 or Windows Server 2008 R2 in the same domain as the RODC and ensure that the writable domain controller is also a DNS server that has registered a name server (NS) resource record for the relevant DNS zone. An RODC must replicate domain updates from a writable domain controller running Windows Server 2008 or Windows Server 2008 R2.   An RODC that runs Windows Server 2008 R2 can replicate the domain partition from a writable domain controller that runs Windows Server 2008 or Windows Server 2008 R2. But if an RODC that runs Windows Server 2008 R2 is added to a domain that has only a writable domain controller that runs Windows Server 2008, the RODC logs Event ID 2916 in the Directory Services log. This error can be disregarded, and it will not appear if there is a writable domain controller that runs Windows Server 2008 R2 in the domain.  For fault tolerance, deploy at least two writable domain controllers running Windows Server 2008 or Windows Server 2008 R2. An RODC can use the second domain controller for failover if the first domain controller is not available. The registration of the name server (NS) resource record is necessary to allow dynamic updates to replicate to the RODC by using a replicate-single-object (RSO) operation. 

FSMO Roles

Flexible Single Master Operation Roles (FSMO)

                      Active Directory has five special roles which are vital for the smooth running of AD as a multimaster system. Some functions of AD require there is an authoritative master to which all Domain Controllers can refer to. These roles are installed automatically and there is normally very little reason to move them, however if you de-commission a DC and DCPROMO fails to run correctly or have a catastrophic failure of a DC you will need to know about these roles to recover or transfer them to another DC.

The forest wide roles must appear once per forest, the domain wide roles must appear once per domain.

The Roles    There are five FSMO roles, two per forest, three in every Domain. A brief summary of the role is below.

The Five FSMO roles are:

1. Domain Naming Master 
2. Schema Master 
3. PDC 
4. RID 
5. Infrastructure Master 

PDC Emulator  

The holder of the PDC Emulator role is responsible for the following tasks within a domain where it is authorative for:  

• Provide time service. An accurate time syncronisation is necessary for  Kerberos authentication. Per default, all Windows clients in a domain retrieve their time from the DC owning the PDC Emulator role in their domain. In a multi-domain environment, each PDC Emulator in a domain syncronizes its time with the PDC Emulator at the root of the AD forest. The root PDC Emulator is configured to gather the time from an external source. Windows DCs automatically follow this hierarchy, while Samba DCs ntpd must be configured accordingly.  
• Password changes performed by other DCs in a domain are replicated preferentially to the PDC Emulator.  
• All functionality provided by an NT4-style PDC, is handled by the PDC Emulator. Nevertheless, an AD DC owning this role, is something completely different than an NT4-style PDC! Windows 2000 or later clients don't use that functions.  
• Account lockouts are processed by the PDC Emulator.  
• Authentication failures on any DC in a domain caused of a wrong password are forwarded to the PDC emulator, before the password failure message is reported to the user.  
• The Group Policy Management Console contact the DC owning this rule per default.  

In large environments, the DC owning the PDC Emulator role, can have high CPU utilization because of pass-thru authentication, password changes and time sycronisation.  

There is one PDC Emulator per domain.  

This DC should, if possible, be available all the time, because an accurate time on all machines in a domain is required for Kerberos. If your clients are configured to use a different time source and you don't have pre-Windows 2000 clients, then the temporary absence may be less critical.  

RID Master  

The RID Master role owner is responsible for answering RID pool requests from all DC within a domain. It is also responsible for moving objects into another domain and removing them from a domain.  

All security objects like e. g. user/machine accounts and groups are identified by an SID. The objects SID containts the domain SID, which is equal for all objects within a domain, and an RID, that is unique in a domain.  

To allow security objects to be created on all DCs, each contain a so-called RID pool. This is a range of, per default, 500 domain-wide unique RIDs, assigned from the RID Master to each DC. If a security object is created on a DC, then the RID is taken from this pool, to ensure, that it's unique in the domain. If the threshold falls below 50%, then the DC send a RID pool request to the RID Master. This assignes unallocated RIDs and responds them to the requesting DC.  

There is one RID Master per domain.  

This DC must be online when a new DC is promoted in a domain, to assign a RID pool. Also it must be available, when existing DCs update their standby RID pool.  

On the other side, if the RID Master is offline, then it's only possible to create new security objects on each DC, until it's local RID pool is empty. If the RID pools on all DC gets empty, then no further objects can be created. Also it's not possible to join additional DCs while the RID Master of a domain is offline.  

Infrastructure Master  

The DC owning the Infrastructure Master role is responsible for updating objects SID and Distinguished Names in a cross-domain object reference. This is used for example, if a user from one domain is added to a security group of a different domain.  

There is one Infrastructure Master per domain.  

Even if a Infrastructe Master is irrelevant in a forest with just one domain, the role exists. If this DC is temporary offline, then cross-domain changes aren't possible. 

Schema Master  

The DC holding the role Schema Master is the only one in an Active Directory forest, that is allowed to update the directory schema. Once the update is completed, the changes are replicated to all other DCs in the forest.  

The schema partition, which is existing on all DCs, is named „schema naming context“ and located in CN=schema,CN=configuration,DC=<domain>. Updates are done only on the Schema Master.  

There is one Schema Master per forest.  

This DC must be online when schema updates are performed.  

Domain Naming Master  

The holder of this role is the only DC, that is responsible for changes in the forest-wide domain name space. This means that this DC is the only one which can add or remove a domain, trusts to external directories and application partitions to/from the forest.  

The domain naming information are stored in the partition „Configuration Naming Context“ in CN=Partitions,CN=Configuration,DC=<domain>. This partition exists on all DCs, but is only updated on the Domain Naming Master.  

There is one Domain Naming Master per forest.  

This DC must be online when trusts are established with external directories and domains and application partitions are added/removed to/from the forest.  

Important Note :

Unless there is only one DC in a domain the Infrastructure role should not be on the DC that is hosting the global catalogue. If they are on the same server the infrastructure master will not function, it will never find data that is out of date and so will never replicate changes to other DCs in a domain.

If all DCs in a domain also host a global catalogue then it does not matter which DC has the infrastructure master role as all DCs will be up to date due to the global catalogue.

How Kerberos authentication works?

The Kerberos protocol gets its name from the three-headed dog in Greek mythology.

The three components of Kerberos are:

· The client requesting services or authentication.

· The server hosting the services requested by the client.

· A computer that is trusted by the client and server (in this case, a Windows Server 2003 domain

controller running the Kerberos Key Distribution Center service).

Kerberos authentication is based on specially formatted data packets known as tickets. In Kerberos,

these tickets pass through the network instead of passwords. Transmitting tickets instead of passwords  makes the authentication process more resistant to attackers who can intercept the network traffic.

Key Distribution Center

The Key Distribution Center (KDC) maintains a database of account information for all security principals  in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user's logon password.

Kerberos authentication process:

In a Kerberos environment, the authentication process begins at logon. The following steps describe the Kerberos authentication process:

1. When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long term keys for every principal in its realm.

2. The KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.

Note: Kerberos implements secret key cryptography, which is different from public key cryptography in that it does not use a public and private key pair.

3. The client computer receives the information from the KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.

Important: When a client receives the session key and TGT from the server, it stores that information involatile memory and not on the hard disk. Storing the information in the volatile memory and not on the hard disk makes the information more secure, because the information would be lost if the server were physically removed.

4. When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.

5. Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client

needs to access resources. Each ticket contains the name of the user requesting the service, the

recipient of the request, a timestamp that declares when the ticket was created, and a time duration

that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared

between the client and the server so they can securely communicate.

6. The KDC takes the server's ticket and encrypts it using the server master key (KB). Then the KDC nests the server's ticket inside the client's ticket, which also contains the KAB. The KDC encrypts the wholething using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.

7. When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the server's ticket. The user cannot read the server's ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server's ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.

Migrate Windows Server 2003 to Windows Server 2008

Step by step guide for upgrading Active Directory from Microsoft Windows 2003 to Microsoft Windows Server 2008 

Warning: What You Need to Know Before Upgrading to Server 2008 

There are a few things you should be aware of before starting the upgrade process: 

1. 2003 Servers should be patched to at least SP1 
2. Small Business Server 2003 and 2003 R2 upgrades are not supported 
3. You can’t upgrade to Server Core 
4. Exchange Server 2007 will not take an in-place upgrade. This is very important, because if you try it will break things. What you need to do is a Mailbox Migration to do this kind of upgrade with Exchange 2007 

---------------------------------------------------------------------------------------------------------

  Preparing your Active Directory infrastructure for upgrade to Windows Server 2008 includes the following tasks:  

• Prepare Windows Server 2003 forest schema for a domain controller that runs Windows Server 2008 
• Prepare Windows Server 2003 domain for a domain controller that runs Windows Server 2008 

Note: Review the list of operations that Adprep.exe performs in Windows Server 2008, and test the schema updates in a lab environment to ensure that they will not conflict with any applications that run in your environment. There should not be any conflicts if your applications use RFC-compliant object and attribute definitions. For a list of specific operations that are performed when you update the Active Directory schema, see Appendix of Changes to Adprep.exe to support AD DS in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=122499). 

You can also test the Active Directory upgrade in a test environment with all the applications configured for testing purposes. 

 Forest Schema preparation 

Before you can add a domain controller that is running Windows Server 2008 to an Active Directory environment that is running Windows 2000 Server or Windows Server 2003, you must update the Active Directory schema. You must update the schema from the domain controller that hosts the schema operations master role (also known as flexible single master operations or FSMO). If you are performing an unattended installation of Active Directory Domain Services (AD DS) with Windows Server 2008, you must update the schema before you install the operating system. For normal installations, you must update the schema after you run Setup and before you install AD DS. 

Use the following procedure to update the Windows Server 2003 Active Directory schema for Windows Server 2008. 

Membership in Enterprise Admins, Schema Admins, and Domain Admins for the domain that contains the schema master is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 

To prepare the forest schema for Windows Server 2008  

  

1. Log on to the schema master as a member of the Enterprise Admins, Schema Admins, and Domain Admins groups.  
2. Insert the Windows Server 2008 DVD into the CD/DVD drive. Copy the content of the \sources\adprep folder to an Adprep folder on the schema master.  
3. Open a command prompt, and then change directories to the Adprep folder.  
4. At the command prompt, type the following command, and then press ENTER:  

adprep /forestprep 

1. (Optional) If you plan to install a read-only domain controller (RODC) in any domain in the forest, type the following command, and then press ENTER:  

adprep /rodcprep 

1. Allow the operation to complete, and then allow the changes to replicate throughout the forest before you prepare any domains for a domain controller that runs Windows Server 2008.  

  

Domain Schema preparation 

After you prepare the forest, you need to prepare any domain for which you plan to install a domain controller that runs Windows Server 2008. 

Use the following procedure to prepare a Windows 2000 or Windows Server 2003 domain for Windows Server 2008.  

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.  

To prepare a Windows 2003 domain for Windows Server 2008  

1. Identify the domain infrastructure operations master role holder as follows:  
   • In the Active Directory Users and Computers snap-in, right-click the domain object, click Operations Masters, and then click Infrastructure.  
2. Log on to the infrastructure master as a member of the Domain Admins group.  
3. Insert the Windows Server 2008 DVD into the CD/DVD drive. Copy the content of the \sources\adprep folder to an Adprep folder on the infrastructure master.  
4. Open a command prompt, and then change directories to the Adprep folder.  
5. Type the following command, and then press ENTER:  

adprep /domainprep /gpprep 

1. Allow the operation to complete, and then allow the changes to replicate throughout the forest before you install a domain controller that runs Windows Server 2008.  

After the forest and domain based schema is prepared, new Windows Server 2008 based domain controllers can be added to the domain. 

Install Active Directory on Windows Server 2008 

Install Active Directory Domain Services (AD DS) on a Windows Server 2008–based member server that is located in the domain by using the Active Directory Domain Services Installation Wizard (Dcpromo.exe). After you install AD DS successfully, the Windows Server 2008–based member server will become a domain controller. You can install AD DS on any Windows Server 2008–based member server that meets the domain controller hardware requirements.  

You can install AD DS using the Windows Server 2008 Windows interface. The Windows interface in Windows Server 2008 provides two wizards that guide you through the Active Directory Domain Services (AD DS) installation process. One wizard is the Add Roles Wizard, which you can access in Server Manager. The other wizard is the Active Directory Domain Services Installation Wizard (Dcpromo.exe), which you can access in either of the following ways: 

• When you complete the steps in the Add Roles Wizard, click the link to start the Active Directory Domain Services Installation Wizard.  
• Click Start, click Run, type dcpromo.exe, and then click OK.  

Membership in the local Administrator account, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 

To install AD DS on a Windows Server 2008–based member server: 

1. Click Start, and then click Server Manager. 
2. In Roles Summary, click Add Roles. 
3. If necessary, review the information on the Before You Begin page, and then click Next. 
4. On the Select Server Roles page, select the Active Directory Domain Services check box, and then click Next.  
5. If necessary, review the information on the Active Directory Domain Services page, and then click Next. 
6. On the Confirm Installation Selections page, click Install. 
7. On the Installation Results page, click Close this wizard and launch the Active Directory Domain Services Installation Wizard (dcpromo.exe). 
8. On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next. If you want to install from media, or identify the source domain controller for AD DS replication as part of the installation of the additional domain controller, click Use advanced mode installation. 
9. On the Operating System Compatibility page, review the warning about the default security settings for Windows Server 2008 domain controllers, and then click Next. 
10. On the Choose a Deployment Configuration page, click Existing forest, click Add a domain controller to an existing domain, and then click Next. 
11. On the Network Credentials page, type the name of any existing domain in the forest where you plan to install the additional domain controller. Under Specify the account credentials to use to perform the installation, click My current logged on credentials or click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that can install the additional domain controller. To install an additional domain controller, you must be a member of the Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click Next. 
12. On the Select a Domain page, select the domain of the new domain controller, and then click Next. 
13. On the Select a Site page, select a site from the list or select the option to install the domain controller in the site that corresponds to its IP address, and then click Next. 
14. On the Additional Domain Controller Options page, make the following selections, and then click Next: 
    • DNS server: This option is selected by default so that your domain controller can function as a DNS server.  
    • Note: If you select the option to install DNS server, you might receive a message that indicates that a DNS delegation for the DNS server could not be created and that you should manually create a DNS delegation to the DNS server to ensure reliable name resolution. If you are installing an additional domain controller in either the forest root domain or a tree root domain, you do not have to create the DNS delegation. In this case, click Yes and disregard the message.  
    • Global Catalog: This option is selected by default. It adds the global catalog, read-only directory partitions to the domain controller, and it enables global catalog search functionality.  
    • Read-only domain controller. This option is not selected by default. It makes the additional domain controller read only.  
15. If you selected Use advanced mode installation on the Welcome page, the Install from Media page appears. You can provide the location of installation media to be used to create the domain controller and configure AD DS, or you can have all the replication done over the network. Note that some data will be replicated over the network even if you install from media. For information about using this method to install the domain controller, see Installing AD DS from Media. 
16. If you selected Use advanced mode installation on the Welcome page, the Source Domain Controller page appears. Click Let the wizard choose an appropriate domain controller or click Use this specific domain controller to specify a domain controller that you want to provide as a source for replication to create the new domain controller, and then click Next. If you do not choose to install from media, all data will be replicated from this source domain controller. 
17. On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume and folder locations for the database file, the directory service log files, and the system volume (SYSVOL) files, and then click Next.Windows Server Backup backs up the directory service by volume. For backup and recovery efficiency, store these files on separate volumes that do not contain applications or other nondirectory files. 
18. On the Directory Services Restore Mode Administrator Password page, type and confirm the restore mode password, and then click Next. This password must be used to start AD DS in Directory Service Restore Mode (DSRM) for tasks that must be performed offline. 
19. On the Summary page, review your selections. Click Back to change any selections, if necessary.To save the settings that you have selected to an answer file that you can use to automate subsequent Active Directory operations, click Export settings. Type the name for your answer file, and then click Save. When you are sure that your selections are accurate, click Next to install AD DS. 
20. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish.  
21. You can either select the Reboot on completion check box to have the server restart automatically or you can restart the server to complete the AD DS installation when you are prompted to do so.  

Additional Reference Links: http://blog.zwiegnet.com/windows-server/migrate-server-2003-to-2008r2-active-directory-and-fsmo-roles/ 

http://blog.pluralsight.com/upgrading-to-server-2008-from-server-2003