Security Infrastructure Services

Lesson 9

Skills Matrix
Technology Skill

Objective Domain

Objective #

Using Certificates

Plan infrastructure
services server roles

1.3

Securing Remote
Access

Monitor and maintain

security and policies

3.3

Remote Access
Windows Server 2008 provides
remote access capabilities, as part of
its Network Policy and Access
Services role, which enable users to
connect to the network using dial-up
or virtual private network (VPN)
connections.

Dial-Up Connections
To use dial-up connections, you must equip
your Windows Server 2008 computer with at
least one modem and telephone line.
For a single-user connection, as for an
administrator dialing in from home, a
standard off-the-shelf modem is suitable.
For multiple connections, there are modular
rack-mount modems available that enable
you to connect dozens of users at once, if
necessary.
In the real world, however, hardware and
telephone costs and the near-ubiquity of highspeed Internet connections have caused dialup remote connections to be almost entirely

Point-to-Point Protocol (PPP)

A dial-up connection is a dedicated link
between two modems that remains in
place during the entire session.
The client and the server establish a
Point-to-Point Protocol (PPP)
connection, during which the server
authenticates the client and the
computers negotiate a set of
communication parameters they have in
common.
PPP is much simpler than Ethernet
because the two computers are using a
dedicated connection, and there is no
need to address each packet to a
particular destination, as they must do on

Point-to-Point Protocol (PPP)

Virtual Private Network (VPN)

In a virtual private network (VPN)
connection, the remote client and the
remote access server are both connected
to the Internet, using local service
providers.
The client establishes a connection to the
server using the Internet as a network
medium and, after authentication, the
server grants the client access to the
network.

VPN Protocol Encapsulation

VPN Protocols
The VPN protocols that Windows
Server 2008 supports are as follows:
Point-to-Point Tunneling Protocol
(PPTP)
Layer 2 Tunneling Protocol (L2TP)
Secure Socket Tunneling Protocol
(SSTP)

Point-to-Point Tunneling Protocol (PPTP)

The oldest of the VPN protocols, PPTP
takes advantage of the authentication,
compression, and encryption mechanisms
of PPP, tunneling the PPP frame within a
Generic Routing Encapsulation (GRE)
header and encrypting it with Microsoft
Point-to-Point Encryption (MPPE), using
encryption keys generated during the
authentication process.
PPTP therefore can provide data
protection, but not other services, such as
packet origin identification or data

Point-to-Point Tunneling Protocol (PPTP)

For authentication, PPTP supports only the
Microsoft Challenge Handshake.
Authentication Protocol version 1 (MSCHAP v1), Microsoft Challenge and shake.
Authentication Protocol version 2 (MSCHAP v2), Extensible Authentication
Protocol (EAP), or Protected Extensible
Authentication Protocol (PEAP).
Although it can use them (with EAP), one
of the advantages of PPTP is that it does
not require the use of certificates. In most
cases, organizations use PPTP as a fallback
protocol for clients running non-Windows
operating systems.

Layer 2 Tunneling Protocol (L2TP) with

IPsec
L2TP relies on the IP security extensions
(IPsec) for encryption, and as a result
performs a double encapsulation.
The system adds an L2DP header to the
PPP frame and packages it with the User
Datagram Protocol (UDP).
Then it encapsulates the UDP datagram
with the IPsec Encapsulating Security
Payload (ESP) protocol, encrypting the
contents using the Data Encryption
Standard (DES) or Triple DES (3DES)
algorithm, with encryption keys generated
during IPsecs Internet Key Exchange (IKE)
negotiation process.

Layer 2 Tunneling Protocol (L2TP) with

IPsec
L2TP/IPsec can use certificates or
preshared keys for authentication,
although administrators typically use the
latter only for testing.
The end result is that the L2TP/IPsec
combination provides a more complete set
of services than PPTP, including packet
origin identification, data integrity
checking, and replay protection.
For VPN connections involving Windows XP
clients, L2TP/IPsec is the preferred
protocol.

Secure Socket Tunneling Protocol

(SSTP)
New to Windows Server 2008 and
supported only by clients running Windows
Vista with Service Pack 1, SSTP
encapsulates PPP traffic using the Secure
Sockets Layer (SSL) protocol supported by
virtually all Web servers.
The advantage of this is that
administrators do not have to open an
additional external port in the server, as
SSTP uses the same TCP port 443 as SSL.
SSTP uses certificates for authentication,
with the EAP-TLS authentication protocol,
and in addition to data encryption,
provides integrity checking and enhanced
key negotiation services.

Authenticating Remote Users

Remote Access in Windows Server
2008 uses an authentication system
that is entirely separate from the
Kerberos authentication system that
clients on the local network use.
However, authentication is even
more important for remote access
clients than for local ones, because
of the increased likelihood of
intrusion.

Authenticating Remote Users

Extensible Authentication Protocol (EAP)
Protected EAP (PEAP)
Extensible Authentication Protocol
Transport Level Security (EAP-TLS)

Microsoft Challenge Handshake

Authentication Protocol Version 2 (MSCHAPv2)
Challenge Handshake Authentication
Protocol (CHAP)
Password Authentication Protocol (PAP)
Unauthenticated Access

Extensible Authentication Protocol

(EAP)
EAP is a shell protocol that provides a
framework for the use of various
types of authentication mechanisms.
The primary advantage of EAP is that
it enables a computer to use
mechanisms other than passwords
for authentication, including public
key certificates and smart cards, as
well as providing an extensible
environment for third-party
authentication mechanisms.

Protected EAP (PEAP)

The primary function of PEAP is to
use Transport Level Security (TLS) to
create an encrypted channel
between a wireless client and an
authentication server.
The use of PEAP is not supported for
remote access clients.

Extensible Authentication ProtocolTransport Level Security (EAP-TLS)

Enables the server to support

authentication with smart cards or
other types of digital certificates.
To use EAP-TLS, you must obtain and
install a certificate on the remote
access server and configure both the
server and the client to use smart
card authentication.
This is the strongest authentication
method supported by Windows
Server 2008 Remote Access.

Microsoft Encrypted Authentication

Version 2 (MS-CHAPv2)

Uses a new encryption key for each

connection and for each direction in
which data is transmitted.
The strongest password-based
authentication method supported by
Windows Server 2008 Remote Access
Selected by default.
MS-CHAPv2 supports mutual
authentication of clients and servers,
as well as encryption of both
authentication and connection data.

Challenge Handshake Authentication

Protocol (CHAP)
Uses MD5 hashing to encrypt user
passwords, but it does not support the
encryption of connection data, and the
passwords it uses must be stored in a
reversibly encrypted format.
As a result, CHAP provides relatively weak
protection when compared to MS-CHAPv2.
Windows Server 2008 does not select
CHAP by default.
Mostly used to provide compatibility with
non-Microsoft clients.

Password Authentication Protocol

(PAP)
The least secure of the authentication protocols
supported by Windows Server 2008.
It uses simple passwords for authentication, and
transmits them in clear text.
Requires no special technology, and virtually
every operating system and remote access
software product supports it.
The disadvantage is that anyone capturing the
packets transmitted during the authentication
process can read the users account name
password and use it to gain access to the
network.
In Windows Server 2008 Remote Access, PAP is
disabled by default, and its use is strongly
discouraged for all connections that can use a
more capable authentication protocol.

Unauthenticated Access
Windows Server 2008 also supports
unauthenticated access, in which the
systems use no authentication
protocol at all, and the client does
not have to supply a user name or
password.
Obviously, no authentication is the
weakest form of authentication
available, and should be used only
when there is some other security
mechanism in place or when the
administrator wants to allow anyone

The Routing and Remote Access

Console

The Configuration Page

The Remote Access Page

The VPN Connection Page

The IP Address Assignment Page

The Address Range Assignment Page

The Managing Multiple Remote Access

Servers Page

The Security Tab of a

Remote Access Servers Properties Page

The Authentication Methods Dialog

Box

Public Key Infrastructure (PKI)

Windows Server 2008 relies heavily on this
public key infrastructure (PKI) for many of
its security mechanisms.
A digital certificate is a digitally signed
document, issued by a third party called a
certification authority (CA), that binds a
user, computer, or service holding a private
key with its corresponding public key.
When both parties involved in a transaction
trust the CA to properly authenticate users
before handing out certificates, and believe
that the CA protects the privacy of its
certificates and keys, then they can both trust
in the identity of the certificate holder.

Certificate Functions

Digital signature.
Encrypting File System (EFS).
Internet authentication.
IP Security (IPsec).
Secure email.
Smart card logon.
Software code signing.
Wireless network authentication.

The Certificates Snap-in

The General Tab in a Certificate Dialog

Box

The Details Tab in a Certificate Dialog

Box

The Certification Path Tab

in a Certificate Dialog Box

Types of Certificate Authorities

Windows Server 2008 supports two
basic types of CAs:
Enterprise CA
Standalone CA

Enterprise CA
Enterprise CAs are integrated into the
Windows Server 2008 Active Directory
environment.
They use certificate templates, publish
their certificates and CRLs to Active
Directory, and use the information in
Active Directory to approve or deny
certificate enrollment requests
automatically.
Because the clients of an enterprise CA
must have access to Active Directory to
receive certificates, enterprise CAs are not

Standalone CA
Standalone CAs do not use certificate
templates or Active Directory.
They store their information locally. In
addition, by default, standalone CAs do
not automatically respond to certificate
enrollment requests, as is the case with
enterprise CAs.
Requests wait in a queue for an
administrator to manually approve or deny
them.
Standalone CAs are intended for situations
in which users outside the enterprise
submit requests for certificates.

Root and Subordinate CA

A root CA is the parent that issues
certificates to the subordinate CAs
beneath it.
If a client trusts the root CA, it must
also trust all the subordinate CAs
that have been issued certificates by
the root CA.
The certification path included in
every certificate traces the hierarchy
from the issuing CA up through any
additional CAs to the root.

Certificate Life Cycle

When planning certificate and key
lifetimes, administrators must
consider how vulnerable the keys are
to compromise and what the
potential consequences of their
compromise are.

Certificate Life Cycle

The following factors can influence
the lifetime of a certificate:
Length of private keys.
Security of the CAs and their private
keys.
Strength of the technology used for
cryptographic operations.
Vulnerability of the CA certificate
chain.
The users of your certificates.
The number of certificates that have

Certificate Revocation
A certificate has a specified lifetime, but CAs can
reduce this lifetime by a process known as
certificate revocation.
Every CA publishes a certificate revocation list
(CRL) that lists the serial numbers of certificates
that it considers to be no longer valid.
The specified lifetime of CRLs is typically much
shorter than that of a certificate.
The CA might also include in the CRL a code
specifying the reason the certificate has been
revoked. A revocation might occur because a
private key has been compromised, because a
certificate has been superseded, or because an
employee has left the company.
The CRL also includes the date the certificate was

The Select Role Services Page

The Specify Setup Type Page

The Specify CA Type Page

The Set Up Private Key Page

The Configure Cryptography for CA

Page

The Configure CA Name Page

The Set Validity Period Page

The Configure Certificate Database

Page

Enterprise Subordinate CA
The only difference in the installation
procedure for an enterprise
subordinate CA is the inclusion of a
Request Certificate from a Parent CA
page in the Add Roles Wizard in place
of the Set Validity Period page.

The Request Certificate

from a Parent CA Page

CA Hierarchy
While even a single CA constitutes a PKI, it is
common for organizations to use multiple CAs,
arranged in a hierarchy, much like Active
Directory forests.
In a hierarchical CA structure, there is a single
root CA at the top, and one or more subordinate
CAs beneath it.
The root CA provides certificates to the
subordinate CAs, which in turn can generate
certificates for additional subordinate CAs or for
end users.
In an Active Directory hierarchy, domains in the
same tree automatically trust each other. In a
CA hierarchy, trust chaining enables clients
that trust the root CA to also trust certificates

Simple CA Hierarchy

CA Hierarchy
Some larger organizations may have two
distinct types of subordinate CAs, as
follows:
Intermediate CAs Intermediate CAs do
not issue certificates to end users or
computers; they issue certificates only to
other subordinate CAs below them in the
certification hierarchy. Intermediate CAs
are not required, but using them enables
you to take your root CA offline, which
greatly increases its security.
Issuing Cas Issuing CAs provide
certificates to end users and computers.
Root and intermediate CAs are capable of

CA Hierarchy

Certificate Templates
Enterprise CAs might have to issue
thousands of certificates to users and
computers.
If administrators had to provide the
configuration settings for each certificate
manually, they could easily spend all of
their time issuing certificates and would
probably make a large number of mistakes
in the process.
Fortunately, administrators can use
certificate templates to simplify the
process of creating certificates and ensure

Certificate Templates
Sets of rules and settings that define
the format and content of a
certificate based on the certificates
intended use.
Provide the client with instructions on
how to create and submit a valid
certificate request.
Define which security principals are
allowed to read, enroll for, or
autoenroll for certificates based on

Certificate Templates
Windows Server 2008 includes a large collection
of predefined certificate templates, supporting a
variety of functions and applications.
You can also customize each template for a
specific use or create your own templates to suit
the needs of your organization.
Only enterprise CAs can issue certificates based
on certificate templates; standalone CAs cannot.
When an administrator defines a certificate
template, the definition must be available to all
CAs in the forest.
To make the definition available, administrators
publish the template in Active Directory and let
the Active Directory replication engine propagate
the template throughout the enterprise.

The Certificate Templates Snap-In

The Security Tab of the

Security Templates Properties Sheet

The Default Capabilities of

the Smartcard User Template

The Duplicate Template Dialog Box

Adding Application Policies to a Duplicate

Template

Certificate Enrollment Methods

Active Directory Certificate Services
supports several certificate
enrollment methods.
A clients choice of enrollment
method for obtaining certificates is
typically dictated by the type of CA
the client is requesting the certificate
from and whether the client and CA
can communicate across a network.

Certificate Enrollment Methods

When requesting certificates from an
enterprise CA, a client can use the
following methods:
Autoenrollment
Web enrollment
Certificates Snap-in

Autoenrollment
Applications automatically issue a
certificate enrollment request and
send it to the CA.
The CA then evaluates the request
and issues or denies a certificate.
When everything works properly, the
entire process is invisible to the end
user.

Web Enrollment
When you install Active Directory
Certificate Services with the
Certification Authority Web
Enrollment role service, the setup
wizard creates a Web site that clients
can use to request certificates from
the CA.
Although standalone CAs are more
likely to use Web enrollment,
enterprise CAs support it as well.

Certificates Snap-In
The Certificates snap-in for MMC
enables users to manually request
certificates, as well as view the
certificates they already possess.

The Request Handling Tab on a Certificate

Templates Properties Sheet

The Certification Authority Web Enrollment

Interface

The Certificate Enrollment Wizard

The Pending Requests Folder of

the Certification Authority Console

The Certificate Issued Page

Revoking Certificates
Administrators might occasionally
need to revoke a certificate because
a user has left the organization,
because they have decommissioned
a computer, or because a private key
has been compromised.
There are two ways to revoke
certificates:
By using the Certification Authority
snap-in.

The Certificate Revocation Dialog Box

Summary
Windows Server 2008 provides
remote access capabilities as part of
its Network Policy and Access
Services role, which enable users to
connect to the network using dial-up
or virtual private network (VPN)
connections.
A dial-up connection is a dedicated
link between the two modems that
remains in place during the entire
session.

Summary
The Remote Access client and the
server establish a Point-to-Point
Protocol (PPP) connection, during
which the server authenticates the
client and the computers negotiate a
set of communication parameters
they have in common.

Summary
In a virtual private network (VPN)
connection, the remote client and the
remote access server are both
connected to the Internet, using local
service providers.
The client establishes a connection
to the server using the Internet as a
network medium and, after
authentication, the server grants the
client access to the network.

Summary
In the tunneling process, the two
computers establish a PPP
connection just as they would in a
dial-up connection, but instead of
transmitting the PPP packets over
the Internet as they are, they
encapsulate the packets again by
using one of the three VPN protocols
supported by Windows Server 2008.

Summary
Remote Access in Windows Server
2008 uses an authentication system
that is entirely separate from the
Kerberos authentication system that
clients on the local network use.

Summary
A digital certificate is a digitally
signed document issued by a third
party, called a certification authority
(CA), that binds a user, computer, or
service holding a private key with its
corresponding public key.

Summary
When both parties involved in a
transaction trust the CA to properly
authenticate users before handing
out certificates and believe that the
CA protects the privacy of its
certificates and keys, then they can
both trust in the identity of the
certificate holder.
Windows Server 2008 supports two
basic types of CAs: enterprise CAs
and standalone CAs.

Summary
You can configure each enterprise or
standalone CA to function as either a
root CA or a subordinate CA.
The first CA you install in your
organization must always be a root
CA. A root CA is the parent that
issues certificates to the subordinate
CAs beneath it.
If a client trusts the root CA, it must
also trust all the subordinate CAs
that have been issued certificates by

Summary
While a CA hierarchy can have just
two levels, larger organizations might
have three or more levels.
When this is the case, there are two
distinct types of subordinate CAs:
intermediate CAs and issuing CAs.

Certificate templates are sets of rules

and settings that define the format
and content of a certificate based on
the certificates intended use.

Summary
Certificate enrollment is the process
by which a client requests a
certificate and a CA generates one.
Active Directory Certificate Services
supports several certificate
enrollment methods.
A clients choice of enrollment
method for obtaining certificates is
typically dictated by the type of CA
the client is requesting the certificate
from and whether the client and CA

Summary
Applications discover that a
certificate has been revoked by
retrieving the certificate revocation
list (CRL) from the CA.
There are two kinds of CRLs: full
CRLs, which contain a complete list
of all of a CAs revoked certificates,
and delta CRLs.
Delta CRLs are shorter lists of
certificates that have been revoked
since the last full CRL was published.