However, Microsoft did just release SP2 for Windows Server 2008. Can IT get just as excited about the new server OS?

Here are five great things about Windows Server 2008 and information that will help you decide if upgrading is worth it.

1. Virtualization

Server 2008 comes with Hyper-V a virtualization technology that runs natively on Server 2008. New licensing terms that better align with business in the real world are a huge plus, but the improvements don’t stop there.

While load-balancing is probably still usually best done via a hardware solution, the virtualization in Server 2008 provides numerous opportunities to give flexibility to those with large or complicated infrastructures. Being able to create a new virtual server running a software upgrade or new install on it while leaving the old one completely functional is an enormous boon to the savvy IT department.

If there is any trouble with the new virtual server, the old virtual machine is rolled back in its place, allowing for more testing or troubleshooting while having to worry about neither too much downtime, nor taking too long to roll out new systems caused by “over-testing.”

2. Core Server Installs

Sometimes all you need is a server to sit there and handle just one little thing, and nothing else. In times past, that meant “wasting” a full server installation to handle little, but critical tasks. Securing those servers and then keeping all the patches and upgrades current often seemed like more trouble than it was worth.

Thanks to Core Installations of Server 2008, you can create a Windows Sever that not only does just one thing, but is only capable of doing that one thing rendering it a much less vulnerable system whether to bugs or attacks.

Even better, Server 2008 is smart enough to only bother applying patches that apply to what is actually installed and running on the core server which eliminates numerous updates from ever having to run (and possibly harm) these core servers.

3. Read Only Domain Controllers

Somewhere along the line, domain controllers ended up scattered across many enterprises primarily for speed and fault-tolerance purposes. Generally, while perhaps a slight overkill in many situations, this practice was relatively harmless.

Then, somewhere along the way, the physical security of domain controllers became an uncontrollable factor as remodels or personnel changes left domain controllers sitting under the receptionist’s desk or in the corner of a conference room. While not a widely used tactic, compromising a domain controller and then using its replication features to infest an entire Active Directory with numerous administrator level accounts became a real fear.

Fortunately, the Read-Only Domain Controller solves this problem by allowing for placement out in the field beyond the control of corporate IT but without the ability to send any junk data back into the main network.

4. PowerShell

Real administrators never stopped using the command line to manage servers. Between scripting repetitive or error prone tasks, to just flat out getting something done fast without having to load up any point and click GUI — firing off commands with a few keyboard strokes has always been useful.

But, with PowerShell even admins who gave up the command line are coming back. Doing something to multiple servers is easier than ever with PowerShell. And even better, those 2:30 AM pages from the monitoring system can be addressed remotely from the command line without even putting on your robe, especially if you pre-write some scripts before anything happens.

5. TS RemoteApp

When I first read about TS RemoteApp I was underwhelmed. Frankly, I liked the idea of having a remote desktop and then picking and choosing what to run there. Apparently, that is a system admin mentality.

For users, nothing could be more confusing that having a remote desktop in addition to the local one. After the 800^th user asked me which desktop was their “real” desktop, I realized the value of TS RemoteApp.

With RemoteApp, an application is run remotely, just like the old days, but the big difference is that it launches straight into the application, no desktop, no “second” double-click, no confusion about where the files “really” are located.

Windows Server 2008 Upgrade Is Worth It

Add in all of the performance and stability improvements that Server 2008 brings to the table and you have yourself a solid server OS upgrade.

Many companies will follow the tried and true method of upgrading as new hardware comes online. However, there are many instances in which certain applications, certain server functions, and certain servers outside of the corporate IT server rooms would benefit from an upgrade to Server 2008.

In those cases, it is worth it to schedule upgrades ahead of the hardware lifecycle. Also, with server power increasing faster than many enterprises take advantage of it, waiting for a hardware based need might mean waiting too long.

A smart solution is to evaluate your current server environment and evaluate which servers could benefit most from an upgrade to Server 2008 because of additional needs or limitations that the current servers have. Once those servers have been taken care of, move on to your newest and most powerful servers.

Chances are that they are not being fully utilized. Those servers are prime candidates for Hyper-V and taking on more functionality and responsibility. The same servers will of course be the ones the furthest away from hardware needs based upgrades as well.

Working ahead on sever OS upgrades in this manner can shorten the overall migration time while still providing minimal disruption to the currently functioning server environment, and that is a Win-Win for everyone involved.

Related posts:

• Overview of Server 2008 R2 — The Half Version Upgrade
• Windows Server “LongHorn” Certification Upgrade
• Install Read-Only Domain Controller on Windows Server 2008

RODC is also useful in situations where you have poor network bandwidth, a computer without the resources needed for a full install of Server 2008, or when you don’t have a user with enough expertise to have access to the domain-wide AD DS database.

Do you need a full Domain Controller for a branch office of 5 people? No, you really don’t. Using Windows Server Core and RODC you can create an great experience for your remote users that’s more secure and cheaper to implement.

Today I’m going to show you how to turn your Server Core into a RODC. This is going to be a little different than deploying RODC on a full install of Server 2008 that Coach showed you because we’re restricted to the command prompt.

Free Instant Download

Download this video in high-quality WMV format

Or, download in iPod/iPhone format to watch on the go

Related posts:

• How to Setup & Utilize Remote Administration on Server 2008 Server Core
• How to Activate a Newly Installed Server Core Edition of Server 2008
• Lesson 6: Windows Server 2008 RODC – Read Only Domain Controllers

These are just some of things we’re going to be covering today. I will also explain the requirements for an RODC and walk you through the steps to deploy RODC on your server.

Here’s what’s covered in today’s video:

• What is an RODC — RODC allows users to authenticate against a read only copy of the Active Directory in a remote location; I’ll explain in detail when it is best to use RODC
• Advantages of RODC — I’ll also go over the main advantages of using RODC, whether you can use it with Server Core and what you can do to increase protection
• Deploying RODC — next we’ll go over what you need to install RODC and all the steps involved in doing a full installation
• RODC Role Installation — using our Verde Petra scenario we will go ahead and install the RODC role on our server so you can see all the steps in action
• Password Replication Policy — you get to decide who gets to log in to the RODC and who does not so here I’ll show you how to specify the Password Replication Policy
• Pre-Populating a Password — next we’re going to pre-populate our RODC with a password from one of the employees from our scenario

Free Instant Download

Download this lesson in high-quality WMV video format

Or, download in iPod/iPhone format to watch on the go

Related posts:

• Install Read-Only Domain Controller on Windows Server 2008
• Lesson 8: Windows Server 2008 Terminal Services
• Lesson 4: Windows Server Core and DHCP Servers in Server 2008

When Active Directory was first introduced in Windows Server 2000 it quickly became the most widely implemented Network resource management system in use.

By providing a single logon process from the Windows logon prompt on the client side for authenticated access to all resources locally and on the network as well as a single point of administration, it is hard to argue with results.

The first version of Active Directory used an access control list (ACL) to provide an object based method of managing access to network resources.

Still not every business’ needs were met with the initial release of Active Directory.

Certificate Services, Windows’ method of determining access to web based resources such as email, and Microsoft Metadirectory Services (MMS), Windows’ method for providing central access to multiple network directories, were both separate components from Active Directory.

Here and Now …

When Microsoft released Windows Server 2003 Active Directory’s prominence was secured by adhering to the demands of customers for better integration with other network security components.

Microsoft improved the way Active Directory and Certificate Services worked together. MMS was replaced with Microsoft Identity Integration Server (MIIS), which provided even better integration with other directory types.

Additional features were added in the first revision of Server 2003 such as the Authorization Manager and Windows Rights Management Services (RMS).

The Authorization Manager introduces role-based access control (RBAC) which provides the ability for Administrators to group permissions based on job roles allowing for users to be associated with multiple job roles.

RMS provides the administrator with the ability to associate usage polices that adhere to the new information protection laws to resources. RMS works together with Certificate Services and IIS to uphold its policies on the local network and the World Wide Web.

In Server 2003 Revision 2, Active Directory Federation Services (ADFS) and Active Directory Applications Mode (ADAM) were introduced.

ADFS extends the convenience of Active Directory’s single sign-on authentication to the web by creating a single user session that can be used across multiple web applications.

ADAM was introduced so directory-enabled applications could take advantage of Active Directory’s access control without requiring an actual domain or domain controller.

Windows Server 2008

In Windows Server 2008 Active Directory has continued on its path of integration with its latest family of components. Active Directory components are now available as server roles, which I have listed below:

• Active Directory Domain Services (AD DS)
• Active Directory Certificate Services (AD CS)
• Active Directory Lightweight Directory Services (AD LDS)
• Active Directory Federation Services (AD FS)
• Active Directory Rights Management Services (AD RMS)

As you have probably noticed, the server roles listed above all contain Active Directory in the name. The new Active Directory roles provide the same functionality of the many identity access components from previous Windows Server versions, but with new names.

Active Directory Domain Services (AD DS)

Active Directory Domain Services is the new name for Active Directory Directory Services and remains the core Active Directory Component. Aside from the improvements to the user interface, there are four major improvements to AD DS which I will go over below.

• Read-only domain controllers (RODC) – provide reliable security to insecure environments by replicating a writable domain controller.
  
  Changes cannot be made to a RODC and only the user credentials used with the RODC are stored on the server. This makes it so the whole directory would not need to be rebuilt if security on the RODC were to be breeched.
• Auditing enhancements – there are now four different auditing categories: Directory Service Access, Directory Service Changes, Directory Service Replication and Detailed Directory Service Replication.
  
  This allows for better event searching and logging policy management.
• Granular password and account lockout policies – domains are no longer limited to a single password or lockout policy. Multiple policy objects can now be saved to a domain and applied to groups or users.
• Restartable AD DS – you can now perform maintenance on AD DS by simply stopping the Domain Controller Service.
  
  Before you had to reboot the machine and start in Directory Services Restore Mode to perform maintenance which led to more down time.

Active Directory Certificate Services (AD CS)

Certificate Services is named Active Directory Certificate Services in Server 2008. There are several notable improvements to AD CS. I have listed the major changes below.

• Certificate Web enrollment support improvements – the ActiveX control for Web enrollment, XEnroll.dll, has been replaced with the COM control, CertEnroll.dll. The new control is more secure and manageable.
• Network device enrollment support – AD CS now provides built in support for issuing certificates to network devices to allow applications using the device to interact with other network entities.
• Online certificate status protocol (OCSP) support – Server 2008 includes this as an optional role service.
  
  OCSP checks a certificates status for revocation prevent clients from having to download the entire certificate revocation list, thus improving network performance.
• Enterprise PKI (PKIView) – PKI Health has a new name and can now be used as an MMC snap-in. This tool is used for troubleshooting and monitoring the health of certificates and certificate authorities.
• CAPI2 Diagnostics – a new PKI troubleshooting feature that performs highly detailed logging for several validation processes.

Active Directory Lightweight Directory Services (AD LDS)

Active Directory Lightweight Directory Services (AD LDS) is the new name for Active Directory Application Mode (ADAM).

AD LDS is essentially the same as ADAM except for it is now available as an in-box role in Server 2008 where it needed to be downloaded from the Microsoft Download Center in Server 2003.

As mentioned previously, but referring to ADAM, AD LS is a stripped down version of AD DS designed to be used in applications. Many CRM and HR applications use Active Directory for storing their data. AD LDS can be used instead of AD DS making it possible for these applications to be used without needing to configure access to network resources.

Active Directory Federation Services (AD FS)

The name for Active Directory Federation Services (AD FS) remains the same, save the addition of a space in the acronym.

AD FS allows for businesses to set up trust relationships with other directories, thus enabling the other directory’s user’s credentials to be used across directories. While there is little change to the name, a couple notable improvements have been made which I will go over below.

• Federation trust import/export support – before the process of configuring federation trusts was a long manual process. The manual process is still long, however once set up; settings can be exported and then imported to other AD FS Servers.
• AD FS deployment limiting – a group policy can be applied to disable deployment of AD FS servers on Windows Server 2008.

Active Directory Rights Management Services (AD RMS)

The follow-up to Windows RMS is Active Directory Rights Management Services (AD RMS).

The purpose of AD RMS remains the same as its predecessor. It is now integrated with Office 2007 and Internet Explorer 7 for securing sensitive information hosted on the server. For example, rights can be applied to emails to prevent recipients from forwarding messages.

AD RMS is available as a role in Server 2008 and now includes an MMC snap-in for administration as opposed to a Web-based interface.

Still More to Come …

The Preceding components are the five Active Directory components released in Windows Server 2008. This year, MIIS has been updated for Server 2003 under the title Identity Lifecycle Manager. An updated release for Server 2008 code-named Identity Lifecycle Manager 2 is currently in beta.

Notable new features available to this release include administration from a GUI and SharePoint Services as well as an approval request process for content available from Office 2007 applications. You can find out more about Identity Lifecycle Manager 2 here.

While it would be nice to have had the release of Identity Lifecycle Manager included with Server 2008, it goes to show you that Microsoft knows it’s work is never finished and will keep improvements to Active Directory coming.

Related posts:

• Server 2008: Active Directory Certificate Services
• Server 2008: Install Active Directory Certificate Services
• Windows Server 2008: Install Active Directory Domain Services

However, there is one important factor to keep in mind. A RODC can only be installed into an existing Active Directory Domain with at least one full (non-read-only) Windows 2008 Server Domain Controller.

The reason is that the RODC is a new feature to Windows 2008 and it needs at least one DC to understand what it is doing in order to function properly.

Once the decision has been made to install a RODC the next decision is whether to install on a full-install or core-install of Windows 2008 Server.

The RODC is primarily aimed at providing additional security on an Active Directory Database for a server that is not physically secured. Installing a RODC on a Core Install of Windows 2008 provides no additional physical security.

It is actually a fair assumption that if someone is savvy enough to break into a stolen server that they also are capable of working most of their tricks from the command-line. So, while a Core Installation does increase security by having a smaller attack footprint, this level of security is separate from that provided by a RODC.

Although, it can be tempting to consider a Core Installation for remote RODC installs to lower the amount of patches and updates that need to be installed. However, it is important to remember that if there is no technical staff on-site, it can be much more difficult to walk someone through any procedures that must be performed locally if the non-technical person has to use the command line.

Installing RODC on a Core Server Install

There is only one way to install RODC role on a Core Server installation. The dcpromo.exe command runs on the GUI-less version of Windows Server 2008.

Using an answer file for the command makes the process much easier than trying to get all the switches just right in the command line.

Although there are many settings available depending upon your particular infrastructure, just basic information is required to complete the command:

• an account with permissions to do what you are trying to do
• the name of the Site
• the database and log paths
• and whether or not to install DNS.

Many people will put a “yes” for RebootOnCompletion. If you are doing an actual unattended promotion then that would make sense.

If you are sitting at the console, I prefer to manually reboot the server so that I can take as much time as I want to study what is on the screen if there is an issue.

Regular Installation

On a full install of Windows Servers 2008, there is of course a GUI tool to help with the process. The Active Directory Domain Services Installation Wizard handles the installation of RODC.

Type “dcpromo” at a command prompt to start the wizard. The first screen will ask you whether you want to use an existing forest, or create a new domain in a new forest. Since you must join an existing domain with a RODC, the choice is obvious.

Next you’ll be asked for a username and password. The account must be a member of Domain Admins in order to create a Read-Only Domain Controller.

Next, you’ll choose the site you wish to join.

So far, this is all the same as a regular Domain Controller install. Under “Additional Options” is where you actually choose to make this a Read-Only Domain Controller installation.

Next, choose the paths for installing the components, or just click Next to use the defaults. Once the confirmation screen appears, you are all set.

In this case, you might as well check “Reboot On Completion”. Unlike in the command-line environment, here in the GUI-world if something goes wrong you’ll have all the time you want before clicking on OK or Next to analyze what happened.

It’s Five O’clock Somewhere …

Your RODC is now installed. Congratulations! If it’s late enough in the day, or if your boss has already gone home, then head on out to happy hour.

If it’s still morning, or this is the third day this week you’re leaving early, then go get a cup of coffee. Either way, you’ve earned it.

Related posts:

• Lesson 6: Windows Server 2008 RODC – Read Only Domain Controllers
• Windows Server 2008: Install Active Directory Domain Services
• Server Core Install vs. Full Install – Let’s Get Ready to Rumble!

In addition, it can provide a way for local administrator privileges to be assigned to a user that you need to be an administrator at the local level, but who you do not want to allow a backstage pass into the domain-wide AD database via replication.

However, because the RODC intentionally limits its participation in the enterprise-wide AD structure, it is wise to limit its use to only those times when the additional level of security is required.

Let’s Get Physical

First thing is first. Microsoft has spent the years since the release of the first Windows NT products building up a full scale security model around the Windows Server products. However, security is a mission that never ends.

The hackers don’t sit around eating cold pizza and wearing their thumbs out on Xbox moaning about how they can’t use the buffer overflow trick to gain access to secure systems anymore.

Instead, they sit around eating cold pizza and wearing their thumbs out on Xbox while wondering what would happen if they could somehow parse a command string with a hex editor when the command is actually expecting ASCII text … Or at least that’s what it looks like on YouTube.

I wouldn’t know because I wear a white hat (but not after Labor Day), I don’t have an Xbox, and I have some sort of genetic defect that prevents me from using both my thumbs and index fingers at the same time. Thus, since the days of Playstation and its accursed F1, F2 buttons, I have been relegated to the last kid picked for dodge ball status of video games.

One of the new frontiers of security concerns is theft of computers with important data. You’ve heard all about the many laptop thefts. The RODC exists so that you won’t start hearing about all of the Domain Controller thefts.

Don’t Break It To Save It

The Active Directory system is setup to be a robust and fully scalable way to implement security throughout your enterprise. Past versions of Windows Server products suffered from various scalability issues.

One of those issues was caused by the original domain model that had only one Primary Domain Controller operating with many Backup Domain Controllers. The problem was that too much activity had to take place on the Primary Domain Controller.

In an enterprise with several hundred or even thousands of Backup Domain Controllers, the Primary Domain Controller spent so much time replicating that it could be overwhelmed and unable to handle other requests flooding in. The solution was to distribute the responsibilities of the Primary Domain Controller to many servers instead of just the one.

So, in a regular AD environment, Domain Controllers replicate with each other, eliminating the bottleneck at the single replication point. The system has been more robust ever since.

The RODC acts in many ways like the old Backup Domain Controller. It only replicates back to a more powerful Domain Controller. RODCs do no replicate amongst themselves. Implementing too many RODCs without enough regular DCs can trigger a similar problem to the old Primary-Backup paradigm because too many RODCs will be overwhelming the too few DCs. So, while your AD might be more secure, it will be less usable.

So, how do we choose between installing a RODC and a DC? First, keep in mind that RODCs do not provide greater protection for network based attacks. A RODC only provides more security should someone gain physical access to the server, usually through theft. For those servers locked into secure racks in the nice, cool, monitored, server room this shouldn’t be an issue.

When servers are installed elsewhere, usually remote sites, then we need to evaluate the situation. Who will be watching and maintaining these servers?

Are they trained IT administrators who know how important the servers are?

Or are they financial analysts who think all servers look like the WOPR?

In other words, how hard would it be for someone to walk in off the street and trick the employees into access, or how hard would it be to slip in through the back door that is never locked?

We aren’t talking about master cat burglars who defeat laser beam security systems by memorizing the timing of the laser beam sweeps. (By the way, if you are going to go through the trouble of installing a laser beam security system, would it really be all that hard to put in some sort of random number generator so the pattern can’t be memorized? I’m just saying.)

How to decide when we should install a Windows 2008 Server as an RODC? A simple checklist should cover most scenarios:

• If the server is stored in an open or unlocked area — install RODC
• If the server will be installed at a location without trained IT personnel — install RODC
• If the server is stored in a locked area, but personnel other than systems administrators also have access to the area — consider installing RODC
• If the site will have more than two Domain Controllers — then limit installs of RODC
  
  RODC will not replicate with each other, only with Domain Controllers. Each RODC at a remote site is one more server using the WAN link for replication. For one or two servers, this probably won’t have a noticeable impact, but you don’t want twenty RODCs using your WAN link for replication.
• If the server is stored in a secure server room or other area with restricted access — do not install RODC

Pretty easy, right?

Settle Down Mel …

Systems administrators tend to be clever people. When talking to them about physical security and the RODC they start to imagine all the ways someone could possibly come after their servers, and because sys admins also tend to be movie buffs, things start to get a little crazy.

In the movie Conspiracy Theory, Mel Gibson’s character balances a bottle on the doorknob.

That way, if anyone tries to get in, the bottle will fall, and he’ll have time to slip out the escape hatch and burn down his apartment.

If this is starting to sound like a good idea for your server areas, then it is time to take a deep breath and re-center.

Ommmmm. Ok, that’s better.

While the threat of a stolen server is real, it isn’t something that roving gangs of ninjas engage in on a nightly basis.

If someone breaks into your server room through the ventilation system, disables the alarm, repels down ropes, and loads your servers into phony ambulances for transport, there is probably a bigger problem than the security of your AD infrastructure. The FBI, NSA and the rest of the king’s horses and men will probably be helping you put your network security back together again.

If a delivery man with a delusion of grandeur walks off with a Domain Controller after saying "Candy-gram" to the receptionist — that is what the RODC is for.

Remember, just because someone takes your sever doesn’t mean that it sings like a canary. There is still a login screen, encrypted data, file permissions, and a host of other security measures standing in the way of the would-be pirates. The delivery man has several long nights ahead of him and when he finally gets anywhere, your AD database will have updated so many times that what he has on the RODC won’t be worth much.

So, implement good security and use the RODC where it makes sense and you can feel secure that you have done a good job with your infrastructure.

But, on your way home tonight, I’d make an extra U-turn near the freeway to make sure no one is following you before you go home and crank out your secret leaking newsletter. After all, maybe they are after you …

Related posts:

• Don’t Worry He Can’t Write: The Story of the RODC
• How to Setup & Utilize RODC on Server 2008 Server Core
• Lesson 6: Windows Server 2008 RODC – Read Only Domain Controllers

The computer systems for the XYZ Company were managed by professionals whose full-time job was to install, configure, and maintain the systems.

So if Joe in accounting had a problem with his computer he would call you or Ted, or one of the other admins, and you would stop by Joe’s desk on the way back from grabbing a bagel in the company cafeteria.

If the XYZ Company got big enough it would open up another office. Management would decide which employees should be in which location.

Accounting might stay in the original headquarters while you and the marketing group moved to the new location ("So long, Joe.")

Along the way, things changed …

Companies needed not just two or three big offices, but maybe two or three big offices and DOZENS of smaller offices. Some of those offices might have just a handful of employees.

Your average Sys Admin would get pretty bored maintaining just eight computers. The XYZ Company is not interested in paying for a fully qualified systems administrator for a dozen offices if they aren’t going to be fully utilized.

So, IT responsibilities get handled by a technician or in some cases by Rob, the contracts guy.

Now, Rob is a good guy. He makes sure the Nowhereville office’s contract get approved quickly, and he also manages the local softball team.

His wife is the manager at the local grocery store/video store/bowling alley/Post Office.

The thing about Rob is, that although he is a good guy and can change a printer toner in less than eight minutes, he doesn’t really know a lot about servers.

So, when the professional looking gentleman in the uniform that looks kind of like the ones the phone company guys wear shows up to make the network faster by tuning the Domain Controller, well … Rob points him in the direction of the "big computer" and offers him a cup of coffee.

You Ain’t Got a Thing If You Ain’t Got Physical Security

Microsoft has spent millions of dollars and many years working on the security for its Windows Server products. These days, a Microsoft Server is about as secure as any server can be; that is if you are coming at it from over the network.

With the proliferation of remote offices for companies both big and small, there are more and more computers out there. The workstations are secured in their own way, and if one is compromised by theft or a local administrator run amok the damage is limited to whatever was on that system.

There really is no way to leverage a single computer into enterprise access once the system has been removed from access.

But, the Computer Grinch is not so easily defeated, and one day he got an idea, a really fantastically rotten idea. If he got a Domain Controller he could take as much time as he wanted to get inside at the goodies, and when he did, he would have a way into your whole enterprise right in his hairy green hands.

For a smaller organization it might be possible to rebuild the Directory for security purposes, but for a large organization with hundreds or thousands of man-hours in the design, development, and implementation of a complex Active Directory, that isn’t a viable option.

Just hoping that the Computer Grinch doesn’t work something out isn’t very viable either.

Reading, No Writing, Rithmitic

Although this scenario sounds a bit far fetched, computer hackers aren’t just going to go away. And with good full scale attacks becoming harder to implement thanks to the growing use of firewalls, secure server systems, and even savvier users, the idea of walking off with a domain controller starts to look a little bit better.

So Microsoft has developed the Read-Only Domain Controller. The Read-Only Domain Controller (RODC) is pretty much the same thing as a Writable Domain Controller as far as your users and their resources are concerned. Where it is different is in how its AD database is handled.

Here is a quick point of terminology. Microsoft considers a regular "writable" domain controller to be a Domain Controller. A non-writable domain controller is a Read-Only Domain Controller.

So, if you see the phrase "Domain Controller" it means a full writable Domain Controller. Only if you see the words "Read-Only" or the letters RODC should you think "read only."

The RODC allows your enterprise to put a controller in any office regardless of the level of security that office has. If you want to put a RODC underneath the receptionist’s desk or next to the vending machine, that’s fine. (It’s not great, so if you have a better spot then use it.)

A RODC contains, as one might expect, a Read-Only Active Directory Database, but it isn’t as simple as it sounds.

For starters, the database isn’t really read-only in the traditional sense. The data can be, and is, updated. It is just that the updates only come in one direction: FROM the other domain controllers.

So, any changes that might be made by someone using a compromised local administrator password or a disgruntled field technician won’t be replicated back into the Enterprise. The damage is limited to the RODC.

This means that even if a domain controller was stolen there is no need to change your entire Directory because every second the stolen domain controller is off the network, its database gets staler and staler until it is completely worthless even to the most talented of hackers.

This level of security also provides a way around that nasty problem of needing someone to handle something locally on a domain controller that requires an administrator password like installing a driver or replacement hardware.

In Server 2003 giving someone an administrator password on the domain controller means giving the full access to the enterprise’s Active Directory. While Mr. Local is politely saying, "Ok. Yeah. Ok," to your directions over the phone, he could be giving his user account admin rights. Or, if he’s a little smarter making a new hard-to-spot account with admin rights. Neither one is a good thing.

On the other hand, while giving someone a local admin password to a RODC does give them full access to that machine, it stops there. No changes that are made while in the RODC get propagated back to the enterprise, so your guy gets nothing out if it.

Not a Problem

The most common thing I hear when people learn about the Read-Only Domain Controller is that physical security of the Domain Controllers isn’t a very big problem. I always respond with one word, "Yet."

In the end, the RODC solves a fairly uncommon security issue, that of domain controller theft, and a slightly more common security issue of employee tampering.

It’s likely that neither causes your organization much trouble today, and that is a good thing. By implementing the Read-Only Domain Controller now, you can make sure it stays that way.

And, isn’t it nice to be out in front of the danger instead of catching up?

Related posts:

• To RODC or Not To RODC, That Is the Question
• How to Setup & Utilize RODC on Server 2008 Server Core
• Server 2008 Active Directory: Adding a Child Domain