In recent years, one of the most debated topics among Windows administrators has been branch office security -- specifically involving configuration. While various publications have presented arguments on how branch offices should be configured, I have yet to see anything that has swayed me once and for all. However, a new feature in Windows Server 2008 may change all this.
The arguments in favor of using domain controllers
Performance is one of the main reasons people recommend using domain controllers in branch offices. Unless a branch office has its own domain controller, users have to send LDAP queries across the wide area network (WAN) for all Active Directory-related functions. This tends to cause performance problems because everyone in the office is sharing a limited amount of bandwidth. If there is a domain controller in the branch office, though, all traffic related to AD will be mostly related to Active Directory replication. All LDAP queries generated by the users will be resolved by the local domain controller.
The other major argument in favor of using domain controllers in branch offices has to do with reliability. Imagine what would happen, for instance, if a branch office with no domain controller lost connectivity to the WAN. Users would not be able to log on to the network, and those who were logged on would not be able to perform any Active Directory functions. This risk can be mitigated by having domain controllers in your branch office.
The arguments against using domain controllers
The primary arguments against using domain controllers in branch offices have to do with cost, administrative burden and security. Naturally, there are going to be acquisition costs associated with purchasing the necessary server hardware and software licenses. Likewise, an administrator will initially have to provision the server and travel to the branch office from time to time to perform repairs or maintenance (which also adds to concerns about cost).
 |
|
|
|
|
Often, a branch office will simply lack the physical security necessary to adequately protect the domain controller.
|
|
|
|
|
|
|
|
|
|
Security is a different issue altogether. Often, a branch office will simply lack the physical security necessary to adequately protect the domain controller. In fact, I could tell you some serious horror stories about this very issue. In one office I visited, a server was in the janitor's closet right next to the mop sink -- and the closet door wasn't even locked! In another office, the server was on the floor next to the receptionist's desk. This wouldn't have been so bad if the plug for the server wasn't wired to the light switch. Every night when the receptionist would leave, she would turn off the lights and crash the server.
My point is that in many branch offices, there is a total lack of physical security. Often, there is nothing stopping someone from literally picking up the server and walking out the door with it. Likewise, I found that branch offices usually do not have a dedicated administrator, or if there is a "computer person" in the office, he or she has only the most basic skills. The thought of granting such a person domain admin rights is pretty scary.
Read-only domain controllers
It's amazing how things can go full circle. In the days of Windows NT, only the primary domain controller could be written to and all of the backup domain controllers were read-only. In Windows Server 2008, Microsoft has gone back to using this model, at least partially. Although Windows Server 2008 still uses the same multimaster replication model for domain controllers that it used in Windows Server 2003 and Windows 2000, it also supports a hardened read-only domain controller model.
As was the case with Windows NT backup domain controllers, read-only domain controllers cannot be updated directly. They only receive updates from a writable DC. Read-only domain controllers are ideal for branch offices because the Active Directory database is resistant to tinkering.
Read-only domain controllers address the issue of poor physical security. Normally, a read-only DC contains a full copy of the Active Directory database, but not the authentication credentials. This means that if someone were to steal the domain controller, the only accessible password would be the local administrator's (which does not grant access to the domain). Therefore, if you are using read-only domain controllers in your branch office, users will still have to query a writable domain controller across the WAN for their initial authentication.
Unfortunately, that's just the price you pay for security. If a WAN connection is really slow or unreliable, however, there is a way to cache user credentials on a read-only domain controller. In such a case, the Active Directory database is still hardened against tampering, but if someone physically steals the server, that person could potentially get access to account information.
|
| Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal website at www.brienposey.com. |
|
