Overview of Security for the Branch Office
The first component of the
security policy and program used to implement security at the branch
office is a definition of adequate physical security. Physical security
is intended to keep intruders out and to keep the valuable information
system assets in. Physical security is implemented in obvious things
like solid walls, fences, doors and locks, guards and guard dogs, and
internal security zones, like a secure server room with card swipes in
and out, designed to provide differing levels of security as users enter
the different security zones. Physical security is also implemented in
more technical components, like the use of strong passwords, smart
cards, and biometrics.
Next, acceptable use
policies should be created to include any device or system in the
facility and in any device owned by the enterprise that gets issued to
the worker. One of the most effective security measures that can be
implemented, after the security policy, the security program, and the
acceptable use policies, is security awareness training for all users.
This should cover facility safety training and an overview of the
security policy. Employees should understand that they have specific
responsibilities related to the security program and that they must know
what the rules of the policy are. They must further understand that
violation of any security policy could be grounds for termination.
Employees should be constantly reminded and aware of the security
concerns of the organization. For example, this can be accomplished
through posters or a column in the monthly newsletter citing recent
violations and threats, as well as through feedback from IT and through
management, when users are identified to be in violation of acceptable
use of the computers and information systems.
Security awareness
training should be performed at least annually for all employees and
should be provided at a higher level and more often as the role of the
user rises in the organizational structure in the enterprise. Management
personnel must understand their responsibility to know the relevant
security policies, as well as their roles as the enforcers of the
security policy in their departments. Middle management must provide
enforcement at the lower levels of management, and so on.
When employees know
what the acceptable use rules are and understand their responsibilities,
the security structure should include auditing and monitoring of the
facility and as much of the environment as is legal. It should be
explained that this monitoring is for the safety and security of the
employees, as well as for the assets of the enterprise.
Note: A warning about employee monitoring
The
laws in the United States on employee monitoring vary greatly from
state to state and even county to county. Typically, the employee must
be aware of, and agree to, the monitoring. Furthermore, the monitoring
cannot target specific individuals, which would amount to
discrimination. The monitoring should be performed routinely and
randomly.
Always consult the
local legal department for documented guidelines on how, what, and whom
can be monitored, and do not exceed these guidelines.
You will, of course,
enable a comprehensive audit policy on the information systems. You
might want to monitor by using CCTV cameras and recording devices, and
you might want to record network and Internet usage for any and all
employees. You might want to have access to monitor the display on the
computer monitor (these can indeed be shadowed by the administration)
and be able to search any hard disk drive on the corporate network. You
should monitor employees’ company e-mail and voicemail. You should
monitor the employees any time they are on the company premises, any
time they are using company-owned resources (such as cell phones and
portable computers), and any time they are acting as a representative of
the organization—again, only within the limits of the law. Don’t forget
that in most cases the organization is legally responsible, and
therefore liable, for anything inappropriate that an employee does while
on company business or while using any of the organization’s devices.
Recording all of
this information is beneficial, but it is useless unless someone is
specifically responsible for the review of the audit logs, the intrusion
detection system (IDS) and intrusion prevention system (IPS) logs, the
videotapes, the call logs, the firewall logs, and so on. This is the
difficult part. Because the reviewers are looking at the actual map of
attacks, exploits, violations, and events that occurred on the system,
they must decipher an understanding of what these many logs and events
actually say. The responsible person must identify violations, attempted
violations, and unexpected vulnerabilities in the environment and
develop proposals on the implementation of new and appropriate
countermeasures to mitigate the risks and defend against these attacks
in the future.
Furthermore, in many cases,
these logs must be tightly secured, with their integrity protected and
provable, and retained in archives for several years to satisfy legal
and regulatory compliance requirements.
Securing Windows Server 2008 in the Branch Office
Now that the foundation of
security is in place, including the security policies, employee safety,
physical security, awareness training, and monitoring, the next security
objective is the electronic security of the information systems. The
threats to information systems that are covered in this section include
threats from willful and malicious hacker attack, from malware, from
willful or accidental modification of data or system configuration, and
from privilege misuse.
Security Overview for the Information System in the Branch Office
Each
branch office implementation must be individually and carefully
designed, implemented, and maintained. There are, however, several core
security components that virtually every branch office network
installation should include.
Infrastructure Firewalls
The branch office
network should be isolated from external networks, including the network
at HQ, through one or more firewalls. They can be placed in series (one
behind the other) to construct a perimeter network (also known as DMZ,
demilitarized zone, and screened subnet) for public resources or
resources shared with HQ. They can be placed in parallel and through
different Internet service providers (ISPs) to provide redundancy for
the WAN link connections to the Internet or to HQ.
Host-Based Firewalls
In addition to the
network-based firewalls, Windows Server 2003, Windows XP, Windows Vista,
and Windows Server 2008 all have a built-in, host-based firewall (often
called a personal firewall). In general, these host-based firewalls
should all be enabled and properly configured to allow only the minimum
required traffic into and out of the Windows-based computers. Windows
Vista and Windows Server 2008 provide for advanced configuration in the
host-based Windows Firewall with Advanced Security.
The Intrusion Detection System/Intrusion Protection System
Another infrastructure
device that you should consider on the branch office network is the
Intrusion Detection System/Intrusion Protection System (IDS/IPS). These
are third-party devices (or systems). The IDS monitors network traffic,
logs data about the traffic, analyzes the traffic based on signatures
and anomalies, recognizes potential attacks, and alerts the
administrative staff to the perceived attack. The IPS does all that, but
it also has the capability to react to the perceived attack. This
reaction can be an adjustment to the rule base on one or more firewalls
to reject the attacker’s frames, or the transmission of TCP NACK to the
victim, or the transmission of deauthentication frames to an 802.1x
port-based authentication switch to disconnect the victim from the
attacker.
Server Hardening
The next routine
security target on all computer systems is server hardening, or creating
the bastion host. This reduces the attack surface of the computer by
reducing the number of targets available on the system to a hacker. In
general, server hardening includes the following:
Stopping and disabling all unnecessary services and applications
Renaming the Administrator account
Creating a new, useless, and disabled user account named Administrator and securing it with an impossible password
Removing or disabling all unnecessary user accounts
Delegating remaining user accounts based on the principle of least privilege
Requiring strong authentication of users
Performing regular firmware, operating system, and application updates
Installing, running, and regularly updating antivirus and anti-spyware applications
Regularly documenting and then reconfirming the system configuration
Implementing routine auditing on logons, network connections, object access, and system configuration changes
This is the basic
hardened server configuration that should be implemented on every
computer in the enterprise. However, for critical or exposed servers,
you should implement additional lockdowns. They include the following:
Deleting all nonessential executables (binaries) from the computer
Deleting all administration tools
Configuring a GPO to disable and further restrict unused services
Creating scripts to lock down services and schedule them to run each hour
Implementing
a routine or process to detect changes to the system files or system
configuration (you can use the Microsoft System File Checker [SFC.exe]
for this purpose. A popular third-party tool named Tripwire is available
to validate the integrity of system files, as well.)
Monitoring system activity and network traffic to and from the hardened server
Implementing more detailed auditing on logons, network connections, object access, and system configuration changes
Securing Windows Server 2008 in the Branch Office
Windows Server
2008 has introduced several significant enhancements to improve security
in installations like the branch office. The most important new
additions are the following:
The Server Core server
The read-only domain controller (RODC)
The Password Settings Object (PSO)
Network Access Protection
Administrator Role Separation
The Read-Only Domain Controller
A new security-related feature in Windows Server 2008 is the RODC. It is designed for implementation in environments where:
There is a need for local access to Active Directory by users, computers, applications, or other entities.
The physical security of the server cannot be guaranteed.
The server might be exposed to a hazardous network environment, such as an extranet.
There are relatively few users.
WAN link connectivity to the main network might be unreliable.
Local technical support skills might be limited.
As you review that list,
you will undoubtedly realize that it sounds like a branch office
environment. The RODC differs from the full DC in the following ways.
The RODC:
Holds a read-only copy of the Active Directory database.
Participates in only one-way replication of all replication partitions, including domain data from a Windows Server 2008 DC.
Participates
in only one-way replication of schema, configuration, and application
directory partitions, and the global catalog from a Windows Server 2003
DC but not the domain partition.
Does not receive user or computer credentials (passwords) from Active Directory, by default.
Can cache only selected user and computer credentials for accounts specified in a Password Replication Policy.
Supports the removal of specified sensitive attributes from replication through the RODC filtered attribute set.
Supports Administrator Role Separation.
Supports a read-only instance of the DNS zones.
RODC Disadvantages
Because of the
read-only nature of the RODC, it cannot be used as an operations master
or a replication bridgehead server. In addition, if Active
Directory–aware applications need to write data to Active Directory, the
RODC cannot accept those write commands and the application’s process
will fail. Microsoft Exchange Server is an example of this type of
application. An Active Directory write process fails if the request is
sent to an RODC. Active Directory–aware applications should be tested
with the RODC prior to deployment into production.
The
RODC might fail to authenticate smart card logons by default. For any
DC to be able to authenticate smart card logons, the DC must receive a
domain controller X.509 digital certificate from a trusted certification
authority. These digital certificates are typically distributed to the
DCs through certificate autoenrollment. The permissions on the
certificate template must be modified to allow the RODC to receive this
certificate.
The RODC does
not advertise properly as a time source, causing the clocks on the
branch office client computers to become desynchronized. The simple
solution is to configure a Windows Server 2008 full DC server as the PDC
emulator operations master for the domain, making it the time master
for the domain. Another solution is to manually configure a time master
for the domain.
Installing an RODC
You need to take a few steps before you can install the first RODC in a domain:
Ensure
that the forest functional level is Windows Server 2003 or higher.
Remember that this means you must purge the forest of any Windows NT
Server 4.0 and Windows 2000 Server DCs.
Run
ADPrep/RODCPrep. This can only be done on the Schema Operations master
for the forest and only by a member of the Enterprise Admins group. This
step is not required if this is a new Windows Server 2008 forest. Copy
the contents of the \sources\adprep folder to the schema master DC, and
execute the command from there.
Install
a Windows Server 2008 DC into the domain. This DC is the replication
source for the RODC. The Windows Server 2008 DC must hold the PDC
emulator operations master role and be located in the site nearest the
site of the RODC, based on site link cost.
Then you can install
the RODC on a Windows Server 2008 server. You can install the RODC on a
Windows Server 2008 full installation server or on a Windows Server 2008
Server Core installation server. Installing the RODC on the Server Core
server provides the greatest level of security because of the hardened
server nature of the Server Core server.
Delegated Installation of the RODC
The RODC computer object
can be created in, or moved to, the DC OU during the installation of
the RODC, but this will require membership in the Domain Admins group in
the domain for the installer. However, this level of privilege is often
not desirable for users in the remote office.
Because the RODC is
often located in a remote office with a nondomain administrator user as
the installer, it is possible to pre-create the RODC account in the
Domain Controllers OU in Active Directory Users and Computers and
delegate authority to the remote, nondomain administrator installer who
completes the DCPromo installation. Furthermore, you can specify details
about the DCPromo installation that get stored on this unoccupied
domain controller account object. These details get pushed down to the
remote RODC during the DCPromo installation.
In
Active Directory Users And Computers, on the Domain Controllers OU,
right-click and select the Pre-Create Read-Only Domain Controller
Account option, as shown in Figure 1. You now see the Active Directory Domain Services Installation Wizard.
To see all
configurable options for the RODC, on the Welcome page, select the Use
Advanced Mode Installation check box. After a few standard DCPromo
pages, such as the Network Credentials page, you are prompted to define
information, such as the necessary credentials to pre-create the domain
controller account, computer name, site location, and whether you want
to configure the RODC to host services such as DNS or the global
catalog. You can next specify the Password Replication Policy for the
RODC server, as shown in Figure 2.
This policy
defines the list of passwords that can be replicated to, and cached on,
the RODC. This Password Replication Policy will be explained in more
detail later in this lesson. The Active Directory Domain Services
Installation Wizard next prompts you to specify which user or group of
users are delegated the authority to run the DCPromo process on the
Windows Server 2008 server in the remote office, as shown in Figure 3. The delegated users do not require any additional privileges to complete the installation.
The recommendation for
granting privilege, including the privilege to install an RODC, as
always, is to follow A-G-DL-P. Place user accounts into global groups,
place global groups into domain local groups, and then grant the
necessary privileges to the domain local group. The Summary dialog box
has an Export button to generate an answer file for use in other similar
unattended installations.
Installing the RODC from Customized Media
As
you probably recall from Windows Server 2003, the DCPromo utility could
be executed using the /ADV switch. This allowed the remote DC to
acquire the Active Directory database (NTDS.dit) from a system state
data backup copy of a DC in the same domain. This feature has been
replaced in Windows Server 2008 with what is called Install From Media
(IFM). By using the NTDSUTIL.exe utility with the IFM subcommand, you
can create a copy of the NTDS.dit database and remove “cached
secrets”—that is, passwords that you do not want to cache on the RODC
server.
The RODC
installation methods that can use the custom IFM media with passwords
removed from the Active Directory database include the following:
The RODC Authentication Process
In
Windows Server 2008, the authentication processes have been changed in
environments like a branch office where the only DC is an RODC. When a
member computer boots up or when a user attempts to log on to a domain
account, the request is sent to the local DC—in this case, it is an
RODC. The RODC does not cache user or computer credentials by default.
The RODC, acting as a relay agent, will then refer the authentication
request across the WAN link to a Windows Server 2008 full (writable) DC
in the nearest site. This can be slow and will fail the authentication
process if the WAN link is down.
To improve performance
and reliability, an administrator can create a Password Replication
Policy that will replicate the passwords of the users and computers in
the remote branch office to the branch office RODC. Now when a member
computer boots up or when a user attempts to log on to a domain account,
the local RODC can complete the authentication process within the local
branch office. A different Password Replication Policy can be created
for each RODC.
If a member computer boots
up or a user attempts to log on to a domain account and the local RODC
does not have its credentials cached, after the authentication process
completes through the referral process, the RODC will request that the
writable DC replicate the credentials to the RODC for caching. If the
account (user or computer) is on the Allowed list of the Password
Replication Policy for that RODC, the credentials are replicated from
the writable DC to the database of the RODC in the branch office.
If the account is not on
the Allowed List of the Password Replication Policy for that RODC, the
credentials are not replicated from the writable DC to the RODC, and the
authentication process will need to be completed over the WAN link
through the referral process every time.
The Password Replication Policy maintains four lists. They are:
Allowed List These passwords (secrets or credentials) can be replicated to the RODC.
Denied List These passwords (secrets or credentials) cannot be replicated to the RODC.
Revealed List
A list of accounts whose passwords are cached on RODCs. This list can
be used to reset passwords of accounts on RODC servers that become
compromised.
Authenticated List A list of accounts that have been successfully authenticated against the RODC.
You can view these lists
in Active Directory Users and Computers by displaying the properties of
the RODC server’s computer object. In the Password Replication Policy
tab, you can see the allowed and denied entities by examining the
Setting column, as shown in Figure 4.
Click the Advanced button to access the Revealed and Authenticated Lists, as shown in Figure 5.
Replication Concerns with the RODC
As
stated previously, the RODC can receive domain replication data only
from a Windows Server 2008 full (writable) DC. The site with the RODC
must be connected to a site with a Windows Server 2008 full (writable)
DC in the same domain, by a site link with the lowest cost. If the
nearest site (again, based on site link cost) does not contain a Windows
Server 2008 full (writable) DC in the same domain, domain data
replication to the RODC will fail.
The RODC can receive all other partitions of replication from a Windows Server 2008 DC or a Windows Server 2003 DC.
Automatic Site Coverage
Sites are defined in
Active Directory by mapping IP subnets to specific sites. Active
Directory clients authenticate against and otherwise access DCs in their
local site, based on their IP addresses. To ensure that all Active
Directory clients are able to identify the appropriate local DC, DNS SRV
records are created for DCs and mapped to each site within the DNS zone
for the domain.
Because
it is possible to create a site without placing a domain controller in
the site, Windows 2000 Server, Windows Server 2003, and Windows Server
2008 perform a service called automatic site coverage. If a site is
recognized to be without a DC, a DC in the nearest site, based on site
link cost, registers a service location (SRV) record for the remote
site. This allows the Active Directory clients in the remote site
without a local DC to connect to the nearest DC to their site.
However, Windows
2000 Server and Windows Server 2003 do not recognize a Windows Server
2008 RODC and might register a SRV record for a remote site, with only
an RODC in it. This is a problem. In DNS for the branch office site
there is a SRV record for the RODC that is actually in the branch office
site and a SRV record for a Windows 2000 Server DC or a Windows Server
2003 DC in a site remote from the branch office. With DNS round robin
(enabled by default), 50 percent of the time Active Directory clients in
the branch office site will commute the WAN link to access Active
Directory when they have their own RODC locally. This causes increased
and unnecessary traffic on the WAN link, degrades performance, and can
cause Active Directory–related failures for clients in the branch office
site if the WAN link is down.
At the time of this writing, Microsoft recommends using one of five adjustments to resolve this problem:
Wait for a hotfix from Microsoft.
Use only Windows Server 2008 DCs in the site nearest to the RODC site.
Disable automatic site coverage on the Windows 2000 Server DCs and the Windows Server 2003 DCs.
Adjust the weight of the Windows Server 2003 DC SRV records (this is only a partial solution).
Use a GPO to adjust the weight of the Windows Server 2003 DC SRV records (this is only a partial solution).
RODC Compromise
The main reason to use the
RODC is the increased threat of compromise of the DC in an unsecure
environment, either by physical theft or access of the system or
electronic attack. If the RODC is stolen or becomes otherwise
compromised and the hacker cracks into the Active Directory database,
the hacker has access to only a few account passwords, so the amount of
accounts potentially compromised is reduced. By using the Revealed List
for the RODC in Active Directory Users and Computers, you can quickly
reset the potentially compromised passwords.
Because the RODC
cannot replicate to other DCs, there is no risk of a hacker modifying
anything in Active Directory, such as permissions and group membership,
and then poisoning the legitimate Active Directory through replication.
If
your RODC is stolen, you can easily delete the RODC computer object in
Active Directory Users and Computers without a successful DCPromo to
remove the DC from Active Directory and without using the NTDSUTIL
MetadataCleanup command. (Using the NTDSUTIL MetadataCleanup command to
remove Active Directory objects leaves broken links from processes that
refer to the now removed object. These broken links will generate
numerous errors about the missing object in event logs of DCs for the
life of the domain.) To delete the RODC computer object, in Active
Directory Users And Computers, right-click the RODC computer object in
the Domain Controllers OU, and select Delete. Click OK to close the
Warning message dialog box. You can then export a list of all accounts
that were cached on the RODC and force the resetting of user and
computer passwords for all accounts that were cached on the RODC, as
shown in Figure 6.
To summarize, a
Windows Server 2008 domain controller in the branch office will
maximize performance by having a local copy of all passwords, accepting
Active Directory changes, and performing two-way replication. But it
also maximizes the amount of sensitive data loss and the risk of
poisoning the legitimate Active Directory in the case of compromise.
A Windows Server 2008 RODC
in the branch office will support most Active Directory requirements in
the branch office while minimizing the amount of sensitive data loss
and the risk of poisoning the legitimate Active Directory in the case of
compromise. The more accounts you cache, the better the performance but
the greater the risk of exposure. The fewer accounts you cache, the
poorer the performance but the less the risk of exposure.
Installing
the RODC on a Windows Server 2008 Server Core server in the branch
office provides the greatest level of security in the branch office by
reducing the attack surface of the server and minimizing the amount of
sensitive data loss and the risk of poisoning the legitimate Active
Directory in the case of compromise.
The RODC supports delegated installation, as well as Administrator Role Separation for increased security.
The Password Settings Object
New to Microsoft
Windows Server 2008 is the ability to define different password and
account lockout policies to users in the domain. This support for
different policies for different users is called fine-grained password
policies. In earlier versions of Windows, only one password and account
lockout policy could be effective for all users in the domain. It is a
common concern that different users in the domain, like the users in a
branch office, require different strengths of passwords and more or less
strict account lockout policies. These differing password policies are
defined in Password Settings Objects (PSOs) and are applied to users and
(preferably) groups of users. PSOs cannot be applied to computer
objects or to OUs.
To utilize fine-grained
password policies in the branch office, the domain functional level must
be set to Windows Server 2008. This requires that all DCs in the domain
run Windows Server 2008. Next, create one or more global security
groups, one for each different PSO required in the branch office, and
populate the group(s) with the appropriate users.
Using fine-grained password policies, you can configure values, including the following:
Maximum Password Age
Minimum Password Age
Minimum Password Length
Password History
Password Complexity
Reversible Encryption Enabled
Account Lockout Threshold
Account Lockout Window
Account Lockout Duration
Users or global security groups to which the PSO applies
If you don’t like ADSI
Edit, you can use LDIFDE. LDIFDE uses a script to configure the new PSO.
Save the following script to an ASCII text file and apply an .ldf file
extension. Adjust the parameters as desired. For example, you will need
to replace the domain name specified in the “dn:” line with your domain
name.
dn: CN=BoPSO, CN=Password Settings
Container,CN=System,DC=dc1,DC=litware,DC=internal
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:24
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=BOusers,CN=Users,DC=dc1,DC=litware,DC=internal
The
time values are calculated using the I8 format. The I8 format breaks
the time units into negative 100 nanoseconds (billionths of a second),
so all forward-looking time values must be negative. To convert time
into I8 values:
Multiply minutes by -6,000,000,000.
Multiply hours by -36,000,000,000.
Multiply days by -864,000,000,000.
After you create the PSO,
you can adjust the users and groups to which it is applied by using
Active Directory Users and Computers. Complete the following steps:
1. | Under the View menu item, select Advanced Features.
|
2. | Expand
the Active Directory Users And Computers tree to <Domain Name>,
System, and then select the Password Settings Container.
|
3. | In the right pane, right-click the PSO and choose Properties.
|
4. | In the Attribute Editor tab, select the msDS-PsoAppliesTo attribute and click Edit.
|
5. | Add the distinguished name of the user or global security group to which you want to apply the PSO or remove the desired entry.
|
Fine-grained password
policies allow administrators to define unique password and account
lockout policies for users and global security groups in a domain. They
are well-suited for application to users in the branch office
environment, which commonly requires a different level of security.
Security for Data in Storage
Another
area of security for the nonsecure branch office that you should
address is security for data in storage. If a computer is stolen from a
branch office, the thief could crack user accounts on the system and
access data stored locally on the hard disk drives. If the thief removes
the hard disk drives from the original computer and mounts them in
another computer where he or she is the administrator, the thief can
access all the content. Windows Server 2008 provides two ways to secure
this stored data:
The Encrypting File System (EFS)
EFS was introduced in
Windows 2000. It provides encryption for data files and folders only. It
requires that the underlying volume (partition) be formatted with NT
file system (NTFS). It uses self-generated X.509 digital certificates
associated with the user account to secure encryption keys for the
encrypted content. Ultimately, one accesses the decryption key by
knowing the user’s password. If the hacker can crack the password, the
hacker can decrypt all of the user’s EFS protected content.
By default, the
local administrator (standalone) or the domain administrator (domain
member) is the EFS recovery agent and can decrypt any EFS-secured
content. EFS cannot be applied to system or AD DS–related files. All
other users who attempt to access another user’s EFS content receive an
Access Denied error, even if proper permissions are granted.
BitLocker
BitLocker was
introduced in Windows Vista and is available in Windows Server 2008. A
specific partition structure must be configured prior to the
installation of the operating system in order for BitLocker to be
available for implementation on a system. BitLocker encrypts the entire
volume and can be applied to system, boot, and data volumes. BitLocker
encryption remains intact even if the hard disk drive is installed in
another computer and is mounted by another operating system.
Note: BitLocker
Use BitLocker if you need to secure the NTDS.dit database.
BitLocker is based on the
Trusted Platform Module (TPM), currently version 1.2. TPM is a microchip
that holds the encryption/decryption key and a piece of code in the
BIOS used to perform the encryption/decryption process on the specified
disk volumes. You can also implement BitLocker on systems without TPM
support by storing the encryption/decryption key on a USB thumb drive.
In either case, a recovery
key or recovery password, or both, should be exported to external media
in case the original encryption/decryption key(s) are lost. By default,
no recovery information is backed up. The recovery password is a
48-character numeric value that can be typed into
the BitLocker Recovery Console. The recovery key is stored on a USB
thumb drive and can be accessed by the BitLocker Recovery Console. In
addition, you can generate and store the recovery passwords in AD DS by
means of a GPO. The recovery key and recovery password should be
securely stored separate from the computer.
Securing the Branch Office with Network Access Protection
In Windows Server
2008, administrators can use Network Access Protection (NAP) to ensure
that remote, local, and branch office clients meet minimum security and
configuration compliance requirements for secure connections to branch
office and HQ networks. NAP checks the client’s health status regarding
the state of its firewall, updates, antivirus protection, and
anti-spyware protection for the Windows XP SP3, Windows Vista, and
Windows Server 2008 operating systems.
