This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
A read- only domain controller (RODC) is a new feature of Active Directory domain services (AD DS) in the Window Server 2008 operating system. An RODC are additional domain controllers that host complete, read-only copies of the partitions of the Active Directory Domain services (AD DS) database.
Active Directory Domain Service
The RODC's main purpose is to improve security in branch offices. In branch offices it is often hard to get the physical security needed for an IT infrastructure, especially for Domain Controllers that contain sensitive data. Often a DC can be found under a desk in the office. If someone gets physical access to the DC, it is not hard to manipulate the system and get access to the data. The RODC solves these issues.
The essentials of RODC are:
Read-Only Domain Controller
Administrative Role Separation
Read-Only Domain Controller
RODC holds a non-writable and read-only copy of the Active Directory database with all objects and attributes. RODC only supports uni-directional replication of Active Directory changes, which means that the RODC always replicates directly with the Domain Controllers in the HUB site. This means that changes that a malicious user makes at branch locations cannot corrupt the forest because they are not replicated back unidirectional.Â Â
The RODC will perform normal inbound replication from the HUB site for Active Directory and DFS changes. The RODC will receive everything from Active Directory but sensitive information, by default accounts such as Domain Admins, Enterprise Admins and Schema Admins are excluded from the replication to RODC.
If an application needs write access to Active Directory, the RODC sends an LDAP referral response which automatically redirects the application to a writable Domain Controller, located in the main HUB site. The RODC is also capable of running the Global Catalog Role for faster logon if needed.
This is a big advantage for branch offices, because if someone gains physical access to the server or even steals it, the person might be able to crack the passwords on the user accounts in AD, but not any of the sensitive accounts - since they are not located on the RODC.
This also means that those sensitive admin accounts are not able to log onto the RODC if the WAN link to the main HUB site is unavailable.
To implement RODC in your environment, you need your domain and forest at Windows Server 2003 mode and the DC running the PDC emulator needs to be running Windows Server 2008.
Figure A: Replication to RODC
Administrative Role Separation
You can delegate local administrator permissions for the RODC server to any user in Active Directory. The delegated user account will now be able to log onto the server and do server maintenance tasks, without having any AD DS permissions and the user does not have access to other Domain Controllers in Active Directory, this way security is not compromised for the domain.
WithÂ Role SeparationÂ you canÂ delegateÂ the local administrator role of an RODC to any domain user without granting that user any user rights for the domain or other domain controllers.Â This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver. Â However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain.Â In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain.
So, a member of the Domain Admins group will create an RODC account by using the ActiveÂ Directory Users and ComputersÂ snap-in.Â Right-click the Domain ControllersÂ OU and clickÂ Pre-create Read-only Domain Controller accountÂ to launch the wizard and create the account.Â When you create the RODC account, you can delegate the installation and administration of the RODC to a user a user or better a security group. On the server that will become the RODC, the user who has been delegated the permissions to install and administer it can then runÂ dcpromo or UseExistingAccount. AttachÂ at a command prompt to start the installation wizard.Â
An RODC deployment can beÂ completed inÂ two stages by different persons.Â You can use the ActiveÂ Directory Domain Services Installation Wizard to complete each stage of the installation.
TheÂ first stageÂ of the installation creates an account for the RODC (pre-staging) in ActiveÂ Director Domain Service
TheÂ second stageÂ of the installationÂ attachesÂ the actual server that will be the RODC to the computer account/object that was previously created for it.
During thisÂ first stage, the "AD installation wizard" records all data about the RODC that will be stored in the distributed ActiveÂ Directory database, such as its domain controller account name, database and log file location and the site in which it will be placed. This stage must be performed by a member of theÂ Domain AdminsÂ group.Â The user who creates the RODC account can also specify at that time which users or groups can complete the next stage of the installation.
TheÂ second stageÂ of the installation can be performed by any user/group who was delegated the right to complete the installation when the computer account was created.Â This stage doesÂ notÂ require any membership in built-in groups such as the Domain Admins group.Â Â
If the user who creates the RODC account does not specify any delegate to complete the installation (and administer the RODC), only a member of the Domain Admins or Enterprise Admins groups can complete the installation.
By default the RODC doesn't store any user or computer credentials, except the computer account of the RODC itself and a special "krbtgt" account that each RODC has.
The RODC can however be configured to cache passwords, this is handled by the Password Replication Policy. The Password Replication Policy determines if replication from the writeable DC to the RODC is allowed for the user or computer credentials. If a certain user is allowed, the user's credentials are cached on the RODC at login. When an account is successfully authenticated against the RODC, the RODC attempts to contact a writable Domain Controller at the HUB site. If a password is not cached, the RODC will forward the authentication request to a writeable DC. The DC receiving the request recognizes that the request is coming from an RODC and checks with the Password Replication Policy.
The benefit of Credential Caching is that is helps with password protection at branch offices and minimizes exposure of credentials, in case the RODC is compromised. When using Credential Caching and if an RODC is stolen, the user account and computer account can have their passwords reset, based on the RODC they belong to.
Credential Caching can be left disabled and this will limit the eventual exposure, but it will also increase WAN traffic, since all authentication requests will be forwarded to the writeable DCs in the main HUB site.
In addition to the RODC, it's also possible to install a DNS service. An RODC is able to replicate unidirectional all DNS application directory partitions, including Forest DNS Zones and Domail DNS Zones. A DNS server running on an RODC doesn't support dynamic updates. But clients are able to use the DNS server to query for name resolution.
Since the DNS is Read-Only, clients cannot update records on it. But if a client wants to update its own DNS record, the RODC will send a referral forward to a writeable DNS. The single updated record will afterwards be replicated from the writable DNS server to the DNS server on the RODC. This is a special single object (DNS record) replication, to keep the RODC DNS servers up-to-date and give the clients in the branch office faster name resolution.
RODC is limited in that it can only support a subset of the roles and functionality normally supported on window server 2008. For example, RODCs- based server can support for any of these technologies that interface with Active Directory Domain Service: ADFS, DNS, DHCP, FRS V1, DFSR (FRS V2), GP (Group Policy), IAS/VPN, DFS, SMS (System Manager Server), ADSI queries and MOM(Microsoft Operations Manager).
With Windows Server 2008, Active Directory Domain Services (AD DS) are now stoppable and restartable. This means that you can stop the AD DS to perform tasks and maintenance, which in prior versions of Windows Server required a reboot into Directory Services Restore Mode (DSRM). This is an excellent feature for scripting and automating those tasks.
The possible states for AD DS are:
AD DS - started
AD DS - stopped
AD DS Restore Mode (DSRM)
It's a benefit that tasks that used to require a reboot to take the AD DS offline are now available directly from the console. This gives administrators some flexibility towards maintaining and performing offline AD DS operations more quickly.
Even though a RODC can replicate data (schema, configuration, application partitions, PAS-GC) from domain controllers running Windows Server 2003, it canÂ onlyÂ replicate data or updates of the domain partition from a domain controller running Windows Server 2008.
For this reason, a writable Windows Server 2008 based domain controller should be placed or available in the nearest site (lowest site-link cost) in the RODC topology.
Fine-Grained Password Policies
The Windows Server 2008 operating system, you could have only one password and account lockout policy per domain, which applied to all users in the domain. These policies were specific in the Default Domain Policy for the the domain. As a result, organizations that wanted different password and account lockout settings for different sets of users had to either create a password filter or deploy multiple domains.
You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain. For example, you can apply stricter settings to privileged accounts and less strict settings to the accounts of other users. In other cases, you might want to apply a special password policy for accounts whose passwords are synchronized with other data sources.
The following individuals should review this information about fine-grained password policies:
Information technology (IT) planners and analysts who are technically evaluating the product
Enterprise IT planners and designers for organizations
Administrators or managers who are responsible for IT security
With Fine-Grained Password Policies the following settings are available:
Enforce password history
Maximum password age
Minimum password age
Minimum password length
Passwords must meet complexity requirements
Store passwords using reversible encryption
Account lockout duration
Account lockout threshold
Reset account lockout after
Fine-Grained Password Policies can be applied to user objects and global security groups. It's not possible to apply them to OUs.
To use Fine-Grained Password Policies the domain functional level must be at Windows Server 2008.
Windows Server 2008 Read-Only Domain Controller Benefits
A new type of domain controller configuration in the Windows Server 2008 operating system that makes it possible for organizations to easily deploy a domain controller in locations where the physical security of a domain controller cannot be guaranteed. An RODC hosts a read-only replica of the Active Directory directory services database for a given domain. Before the release of Window Server 2008, users who had to authenticate with a domain controller, but were in a branch office that could not provide adequate physical security for a domain controller, had to authenticate over a wide area network (WAN). In many cases, this was not an efficient solution. By placing a read-only Active Directory database replica closer to branch users, these users can benefit from faster logon times and more efficient access to authentication resources on the network, even in environments with inadequate physical security to deploy a traditional domain controller.
With the exception of passwords, the Active Directory Domain Services database on an RODC contains the same objects and attributes that a writable domain controller contains. However, the Active Directory Domain Services database on an RODC is a read-only database. This read-only database on an RODC is a fundamental security feature to mitigate risk in the event of a compromise of an RODC.
In the event that an RODC is compromised, an attacker would not be able to make changes directly to the Active Directory Domain Services database that is stored on the RODC. This is pivotal in situations where physical security cannot be guaranteed because gaining physical access to a writable domain controller can put your entire forest at risk.
Because objects are not changed directly on RODCs, and RODCs contain a read-only database, an RODC will not initiate replication changes. Furthermore, no domain controller will pull replication changes from an RODC. As such, Active Directory Domain Services in Windows Server 2008 uses unidirectional replication for RODCs. RODCs will always receive updates for Active Directory Domain Services objects from a writable domain controller.
Unidirectional replication also applies to SYSVOL replication through the Distributed File System (DFS). This can help to reduce the number of domain controllers that you need to deploy in the hub site. The total number of connection objects that have to be created is also reduced by about half, because inbound connection objects do not have to be created on the hub domain controllers for each branch domain controller. Consequently, you do not have to plan for as much configuration of hub site Windows ServerÂ 2008 domain controllers as compared with WindowsÂ ServerÂ 2003 domain controllers.
This can also help to reduce the end-to-end synchronization time for an enterprise. Writable domain controllers in the hub can be configured to replicate updates to a higher number of RODCs concurrently. This can help to implement security changes, such as updates for fine-grained password policies or updates to the RODC FAS as more rapidly.
RODCs have the ability to provide improved logon times by virtue of credential caching, which is the storage of user and computer credentials. The Password Replication Policy for an RODC in a given branch office can be configured to cache the credentials of all users and computers that reside in that branch office. After one of these users or computers is successfully authenticated, the RODC will contact a writable domain controller to request a copy of the credentials. If the RODC's Password Replication Policy permits the caching of the credentials, the RODC will cache the credentials and subsequently directly service that authentication requests until the credentials change.
In addition to improved logon times, credential caching also provides further security enhancements. RODC's Password Replication Policy permits credentials to be cached, the credential caching will not occur until the user or computer successfully authenticates against the RODC. This minimizes the cached credentials that are stored on RODCs. Furthermore, if an attacker gains access to an RODC, the attacker can only attempt to crack the cached credentials. Password Replication Policies are fully configurable; you can allow or deny the caching of passwords for users and computers by each RODC.
Windows Server 2008 Read-Only Domain Controller Disadvantages
There have been several different options for managing branch offices. One of the more common ways of dealing with branch offices is to keep all of the servers in the main office, and provide the branch office user connectivity to those servers through a WAN link. By using this method of the most obvious disadvantage to is if the WAN link goes down then the users who are in the branch office are unable to do much of anything, because they are completely cut off from all of the server resources. Even if the WAN link is functional though, productivity may suffer because the WAN links are often slow and easily congested. Another option for dealing with branch offices is to place at least one domain controller in the branch office. Often times, this domain controller will also act as a DNS server and as a global catalog server. That way if the WAN link goes down, the users in the branch office will at least be able to log into the network. Depending on the nature of the branch office user's jobs, there may also be other servers located at the branch office.
The disadvantage is the cost. Let say placing servers in branch offices requires the organization to shell out money for server hardware and for any necessary software licenses. There are also support costs to consider. An organization needs to determine whether they want to hire full time IT staff to support the branch office, or if they can deal with the amount of time that it takes the IT staff to travel from the main office to the branch office when onsite support is needed.
RODCs are just like any other domain controllers, except that the Active Directory database is not directly writable. Placing an RODC at a branch office does not get rid of Active Directory replication traffic, but it does reduce the workload of the bridgehead servers because only inbound replication traffic is allowed.
Therefore, RODCs may also improve security because people at the branch office cannot make any changes to the Active Directory database. Furthermore, no account information is replicated to RODCs. This means that if someone were to steal a RODC, they would not be able to use the information that they get off of it as a means for hacking user accounts. The fact that user account information is not written to RODCs also reduces the amount of replication traffic that flows across the WAN link, but it does mean that with some exceptions user authentication.