Read-only Domain Controller
Let us talk about branch
offices. Most of you have them in your environments. If your environment
is centralized administratively, you probably find them hard to deal
with in many ways. One key struggle revolves around being able to
provide local authentication capability while still maintaining
centralized administration and security.
For users to gain access to
the network-based resources, authentication of the computer and user
accounts must occur. In an environment that has deployed Microsoft AD
DS, authentication is the responsibility of Domain Controllers (DCs).
They each house a locally stored writable copy of the directory content,
and through replication, they share changes among themselves.
Most branch offices of
significant size place an administrator between a rock and a hard place.
For instance, if a branch office were to become isolated from the rest
of the corporate network, chances are that local productivity within the
site will be dramatically impacted. So, the motivation exists to ensure
that local authentication is available by placing a DC locally in the
site.
Traditionally,
all DCs house password information for domain accounts and are used to
validate log-on attempts to the domain and access to network resources.
To allow for continued autonomy of a branch office facility, an
administrator will often deploy a DC into the local site. This ensures
that if the network connectivity back to the centralized environment
were to fail, the site can still function independently to a certain
extent.
If the branch office does not
have full-time administrative staff, placing a DC in the local facility
can present security risks and concerns as well as create additional
administrative overhead. One of the largest risks presented has to do
with the accessibility of a key network asset. If the local DC
were to be stolen or compromised, the attacker would have all of the
domain accounts and passwords at their disposal to attack.
Onto the scene enters the
Read-Only Domain Controller (RODC). With the release of Windows 2008,
Microsoft introduced the concept of the RODC. RODCs make it less of a
security risk to place DCs in a branch office scenario since they are
not writable copies of the directory. Many of the features of the RODCs
allow administrators to customize the behavior of the RODC depending on
the needs of the particular branch.
When administration is
centralized, often one of the challenges associated with using RODCs is
deploying them. Without administrative staff in branch offices, it is
often the job of a centralized admin to get out to the branches to
perform maintenance and build tasks. With Windows Server, you can choose
to deploy RODCs in two stages. The first stage requires Domain Admin
permissions and is performed from Active Directory Users and Computers.
To stage the computer account in AD, you must right-click on the DCs OU
and select Pre-create Read-only Domain Controller account ..., as seen in Figure 1. This will launch the AD DS Installation Wizard and will allow you to complete the first stage of deploying a new RODC.
Figure 2
displays the portion of the Installation Wizard which allows you to
specify the administrative account or group in the organization that is
authorized to complete the RODC installation. The user account specified
does not have to be a Domain Admins member, and often times, local
administrative staff who work in the branch offices are ideal candidates
for this task. The second stage of installing the new RODC will be
handled by the specified account. Essentially, as part of the prestaging
process, the account is granted rights to execute dcpromo.exe on the
target RODC and complete the AD Installation Wizard. Additionally, the
same selected account will be granted local administrative permissions
on the RODC once installation is complete.
Network Policy and Access Services
When providing your user
base with remote access mechanisms, the foremost focus tends to be on
authentication. The concern is that unauthorized users will gain access
to the internal network and cause some damage or theft. While this is a
valid concern and a real security threat to every environment allowing
remote access today, there is another often overlooked security threat
looming nearby.
While
user authentication gets all the attention, a security concept that
often falls through the cracks is device access. This is a focus not on who is access the network, but from what device
are they accessing the network. The reason this is important is because
without validating the client that is being used to dial into the
remote access mechanism, there is not a way to protect the network from
the security state that the client might be in.
Most VPN software is a load and
go process. Even though many VPN providers allow for the configuration
of additional security measures within their VPN software, such as
computer certificates, not many customers actually deploy them. With
focus commonly on the user, it is often that two-factor authentication
is deployed, but machine authentication is often an afterthought.
So
with publically downloadable VPN software in one hand and the Internet
facing VPN URLs in the other, users are often able to connect to the
company Intranet through VPN tunnels from machines that are not a part
of the domain environment. Since these rogue machines are not a part of
your domain environment, they do not fall under any type of centralized
management policies. Therefore, their patch state is unknown, their
antivirus software is a mystery and whether or not they are crawling
with Trojans and worms is a mystery. Yet, you are allowing these
machines connectivity into your Intranet environment each and every day.
To assist administrators with
addressing the issue of these intruding rogue workstations, with the
release of Windows 2008, Microsoft introduced the Network Policy and Access Services role. This role includes the following components, all wrapped up in a single role:
Network Access Protection (NAP)
Network Policy Server (NPS)
Routing and Remote Access Service (RRAS)
NPS and RRAS are not new to
Windows and have been around since the days of Windows NT 4.0. NPS is
the Windows 2008 rebranded name for Internet Authentication Services
(IAS), representing Microsoft’s rendition of Remote Authentication
Dial-In User Service (RADIUS). While RRAS, was just plain old RAS with
Windows NT 4.0. The new kid on the block for Windows 2008 was NAP.
NAP allows administrators to
decide the required minimum health state of a client machine before it
is allowed to complete its connection to the internal network. By being
able to dictate acceptable compliance settings through System Health
Validators (SHV) and then utilizing those SHVs to create health
policies, administrators now have the authority to block machines
identified as “out of compliance.”
SHVs allow administrators to configure the following characteristics to be included in health policies:
Health policies are
utilized as part of network policies within Network Policy and Access
Services to allow or deny access to the network, therefore, a machine
that was not running the most recently Critical security updates, or had
out-of-date antivirus software, could be denied access into the overall
network.
