Branch Office Services
Designing the Active Directory Structure for Branch Office Administration
The first issue to
consider in the branch office is the establishment of the proper level
of access and authority for the branch office administrator. The branch
office administrator is generally less skilled and less trusted than the
administrators in the corporate HQ. Branch office administrators are
responsible for lower-level administrative functions related to
application installation, performing operating system and application
updates, and restarting servers and domain controllers (DCs). However,
the branch office administrator is generally not authorized to perform
Active Directory–related administrative functions. Because branch office
administrators are not as skilled or as trusted as the HQ
administrators and because they typically are responsible only for their
local branch office systems, it is generally not desirable to add the
branch office administrators to the Domain Admins group or to other
domain-related built-in groups. This is usually too much privilege.
As in Windows
Server 2003, you can use the Delegation of Control Wizard in Windows
Server 2008 to delegate preconfigured levels of privilege at the Active
Directory site, the domain, and the
organizational unit (OU). Several additional preconfigured levels of
privilege have been added at the domain level to the wizard in Windows
Server 2008.
Because the branch
office almost always represents an Active Directory site, it might seem
that the Delegation of Control Wizard should be used at the site level
to delegate privilege to the branch office administrator. However, the
preconfigured privileges available at the site level number exactly
one—Manage Group Policy Links, just as it was in Windows Server 2003.
The Delegation of Control Wizard enables you to create custom tasks to
delegate, but when privilege is delegated at the site level, the branch
office administrator’s level of authority would approximate that of an
Enterprise Admin. Enterprise Admin is far too much authority for the
branch office administrator and is usually not a good choice for
delegation in this case.
If the branch office is
configured in Active Directory as its own domain, the branch office
administrator can be granted Domain Admin status in his or her home
domain. This might or might not be too much authority because members of
the Domain Admins group can write GPOs, delegate authority, and define a
great deal of policy and control over the domain. Delegation at the
domain level would require a skilled and trusted branch office
administrator. If the branch office administrator is up to this level of
challenge, responsibility, and authority in the enterprise, in which
the branch office is its own domain, making the branch office
administrator a domain administrator in his or her home domain could be a
viable option.
It is generally better
to delegate administrative authority at the lowest possible container
within the Active Directory structure—the OU. For more granular
administrative control, create an OU for each branch office and delegate
authority to the branch office administrator at the OU level. Then
place all local branch office users and computers into the proper branch
office OU. At the OU level, the Delegation of Control Wizard has about a
dozen preconfigured levels of privilege. Members of the Enterprise
Admins group can still create and link GPOs at the Site level, with the
optional “Enforced” setting enabled, for high-level, enterprise
administrative control. Members of the Domain Admins group can also
create and link GPOs at the domain level, again with the optional
“Enforced” setting enabled, for high-level administrative control.
Note: Domain restructuring
Windows
Server 2008 provides for domain restructuring in an entirely new way.
Branch offices are often isolated from the main office not just
geographically but financially (like a different cost center) or
administratively (politically), with different network administration,
and they might even have different requirements regarding security and
compliance concerns.
No matter how the
branch office is configured within Active Directory, the branch office
might be restructured to better fit the business needs of the enterprise
with the control and administration models supported by the different
Active Directory containers.
Although
you can use delegation of authority at the site, domain, or OU to
provide administrative control over member computers and users, what
about the domain controller that is physically located in the branch
office? Domain controllers should never be moved from the Domain
Controllers OU. How can the local branch office administrator manage
that operating system and applications? You don’t want the local
administrator working with Active Directory, but you need his or her
help in maintaining the server operating system underlying Active
Directory. Windows Server 2008 introduces Administrator Role Separation
specifically to address this issue.
Administrator Role Separation
A new feature of
Windows Server 2008 is the ability to delegate local administrative
privilege on a domain controller (DC). This grants the delegated user or
group local administrator privilege on the server, with the ability to
log on to the server, update drivers, and restart the server, but
disallows them from being able to manage Active Directory or the
Directory Services. This is called Administrator Role Separation.
You must perform
Administrator Role Separation delegation on a server-by-server basis.
The delegated user or group will not have any administrative privileges
on other DCs in the domain. To implement Administrator Role Separation
on a single DC, at a command prompt, type:
DSMGMT.exe
and press Enter. At the DSMGMT prompt, type:
local roles
and press Enter. You can type a question mark (?) to get help at any level in the DSMGMT application. Next, type:
list roles
to view the possible delegations on the server. Now, for the delegation, type:
add <domain>\<username or group name> administrators
You should receive the following response:
Successfully Updated Local Role
Next, to confirm the delegation, type:
show role administrators
You should see the user or
group that has been delegated the Administrator Role Separation role.
Keep in mind that this grants the delegated user or group administrative
privilege only on this one DC. To grant administrative privilege to the
branch office administrator over users and
computers in the branch office, you will also need to delegate
privilege at the site, domain, or OU level for the branch office, as
appropriate.
Components and Services in the Branch Office
The branch office
typically has relatively few users, relatively few computers, a smaller
budget for information services, reduced network infrastructure devices
(like servers and firewalls), and, most unfortunately, lesser security
and less-skilled administration. The users in the branch office will
still need access to enterprise resources, along with a reasonable level
of performance, coupled with an appropriate level of security for the
information systems. Furthermore, there might be the need to provide
additional infrastructure in the branch office to remain in compliance
with industry regulations and laws. There needs to be a balance between
the needs of the users in the branch office and the cost of providing
infrastructure, support, performance, and reliability for the network.
It is not prudent business practice to “just throw money” at the issue,
hoping that the complaints and other problems go away.
Consequently, a branch
office will need an infrastructure to provide information services. This
section will explore some of the options and discuss the benefits,
along with the price you’ll pay to implement the service in the remote
and potentially unsupported and nonsecure branch office. As a branch
office grows, the need for local services and support also grows.
Following is a list of information system components and services that
might be desirable in the branch office:
Client computers
Servers
Member or standalone, to support services like File Services, Print Services, and other infrastructure services
Full server or Server Core installation
Domain controller (DC)
Global catalog (GC)
Operations master roles
Domain Name System (DNS)
DHCP
Multisite cluster nodes
Distributed File System (DFS) or Distributed File System with Replication
Routing and Remote Access Services
Windows Server Update Services, to provide Microsoft operating system (OS) and application updates
Windows Server Virtualization (WSv) services
In addition, the
branch office will typically need at least one firewall/router and a
wide area network (WAN) link to provide connectivity to the HQ networks,
as well as to the Internet. A more detailed discussion of the elements
on this list follows.
The branch
office network typically connects to the HQ over dedicated WAN links,
like a T1 or a T3, or they connect through VPNs over the Internet’s
public network. In either case, for performance and reliability reasons,
it is often desired to place network infrastructure systems in the
branch office.
Windows Deployment Services
What is the
value of a branch office without computers? How do you get those
standardized operating system and application installations to the
branch office? Microsoft has redesigned the earlier Remote Installation
Services (RIS) in Windows Server 2008 to enhance the remote deployment
and reimaging of computers using preconfigured images complete with
applications and settings. Windows Deployment Services (WDS) is a server
role that can be added to any Windows Server 2008 server.
WDS is optimized to
deploy Windows Vista and Server 2008, but it can deploy earlier versions
of Windows operating systems. It relies on preboot execution
environment (PXE) technology and requires Transmission Control
Protocol/Internet Protocol (TCP/IP) connectivity between the WDS server
and the target client. WDS can deploy remote clients using multicast
transmission to deploy an image to a large number of client computers
simultaneously.
Windows Server 2008 Server—Member or Standalone
In the enterprise,
the most common deployment of client and server class computers is to
make them members of the domain by joining them to the domain. This must
be done on the local computer, by script, or by answer file during an
unattended installation. Joining these systems to the domain implements
the administrative control desired (required) by the administration and
by the enterprise security policy. The majority of administrative
control is accomplished through the GPO within Active Directory. The
benefit to the user of the system is single sign-on to access resources
enterprise-wide. The impact of joining the domain for a computer is
giving up administrative control of the computer. The administrators in
the enterprise now own the control of the system.
For the
administrator in the enterprise, almost the only circumstances in which
it might be desirable to have a company computer remain a standalone
system and not join the domain is when there is little or no need to
access enterprise resources and when there is significant risk of the
computer being compromised. The compromise could be physical theft or
access, or it could be an attack through the network.
Windows Server 2008 Server Core
Server
Core is the securest installation of Windows Server 2008. Server Core
installs a minimal operating system, providing minimal services and
applications, with no Windows shell and a limited graphical user
interface (GUI). This reduces the maintenance, the management, and the
hardware requirements of the server. (Server Core requires only about 1
GB of hard disk drive space for installation and about 2 GB for ongoing
server operations.)
Perhaps more
significant, Server Core reduces the attack surface of the server,
making it the securest installation of Windows Server 2008. It is
designed as a bastion host or hardened server, already minimizing the
attack vectors of the operating system. Almost always, the way that a
hacker is able to compromise a computer is through vulnerabilities in
services and applications (program code) running (in memory) on the
computer. These vulnerabilities are inherent in all program code. By
reducing the number of services and applications that run on a computer,
you are reducing the number of attack vectors available to the hacker.
This is exactly what Server Core does. It operates with a bare minimum
of services and programs running in memory.
Furthermore, if the
hacker can break into a running process, the hacker’s level of privilege
is that of the user account that initially launched the compromised
process. After a hacker accesses a computer through one of the
vulnerabilities in running program code, the hacker’s next objective is
to elevate his or her level of privilege in order to acquire greater
control over the computer. This is commonly accomplished by triggering
the execution of a service (or other process) that runs at a higher
level of privilege. Because vulnerabilities are inherent in all program
code, the hacker now breaks into the process that runs at the higher
level of privilege, acquiring a higher level of privilege on the
computer. Again, because Server Core has a reduced set of services and
applications installed and available on the computer, the hacker has
fewer targets with elevated privilege to execute and exploit. This
reduces the likelihood that a hacker can elevate his or her level of
privilege on the Server Core server, keeping the hacker at a lower level
of privilege. These are the principal mechanisms that make Server Core
the securest implementation of Windows Server 2008.
Note: The many facets of security
The reduction of
programs in memory and on the hard disk drive does not alone ensure
security of the computer. These features, combined with a comprehensive,
multilayered, and monitored security structure, are the best defense
against hacker compromise of the computer system.
It only takes
one vulnerability in a system to enable the hacker to exploit the
system. You must attempt to secure them all.
Because Server Core has
no Explorer shell and a limited GUI, local administration and
administration through a Remote Desktop (Terminal Services) connection
must be performed using commands at a command prompt. Figure 1 shows the Server Core console.
