This topic provides best practices for
implementing and configuring NPS and is
based on recommendations from Microsoft
Product Support Services.

Installation

Before installing NPS, do the
following:

Install
and test each of your network
access servers by using local
authentication methods before
you make them RADIUS clients.

After you
install and configure NPS, save
the configuration by using the
netsh nps export
command. Use this command to
save the NPS configuration to an
XML file every time a
configuration change is made.

If you
install additional Extensible
Authentication Protocol (EAP)
types on your NPS server, ensure
that you document the server
configuration in case you need
to rebuild the server or
duplicate the configuration on
other NPS servers.

If you
install additional system health
validators (SHVs) on your NPS
server, ensure that you document
the server configuration in case
you need to rebuild the server
or duplicate the configuration
on other NPS servers.

Do not
install Windows Server 2008 on
the same partition with another
version of Windows Server.

Do not
configure a server running NPS
or the Routing and Remote Access
service as a member of a
Windows NT Server 4.0 domain if
your user accounts database is
stored on a domain controller
running Windows Server 2008 in
another domain. Doing this will
cause Lightweight Directory
Access Protocol (LDAP) queries
from the NPS server to the
domain controller to fail.

Instead, configure your server
running NPS or Routing and
Remote Access as a member of a
Windows Server 2008 domain. An
alternative is to configure a
server running NPS as a RADIUS
proxy server that forwards
authentication and accounting
requests from the Windows NT
Server 4.0 domain to an NPS
server in the Windows
Server 2008 domain.

Client computer
configuration

Following are the best practices for
client computer configuration:

Automatically configure all of
your domain member 802.1X client
computers by using Group Policy.

Automatically configure all of
your domain member NAP-capable
clients by importing NAP client
configuration files into Group
Policy.

Authentication

Following are the best practices for
authentication:

Use
authentication methods, such as
Protected Extensible
Authentication Protocol (PEAP)
and Extensible Authentication
Protocol (EAP), that provide
authentication types, such as
Transport Layer Security
(EAP-TLS and PEAP-TLS) and
Microsoft Challenge Handshake
Authentication Protocol version
two (PEAP-MS-CHAP v2), that
support the use of certificates
for strong authentication. Do
not use password-based
authentication methods because
they are vulnerable to a variety
of attacks and are not secure.

Use PEAP,
which is required for all
Network Access Protection (NAP)
enforcement methods. Determine
the PEAP authentication types
that you want to use, such as
PEAP-TLS and PEAP-MS-CHAP v2,
and then plan and deploy your
public key infrastructure (PKI)
to ensure that all computers and
users can enroll the
certificates required by the
authentication types.

Deploy a
certification authority (CA) by
using Active Directory®
Certificate Services (AD CS) if
you use strong certificate-based
authentication methods that
require the use of a server
certificate on NPS servers. You
can also use your CA to deploy
computer certificates to domain
member computers and user
certificates to members of the
Users group in Active Directory.

When you are administering an NPS
server remotely, do not send
sensitive or confidential data (for
example, shared secrets or
passwords) over the network in
plaintext. There are two recommended
methods for remote administration of
NPS servers:

Use Remote
Desktop Connection to access the
NPS server.

When Remote Desktop Connection
users log on, they can view only
their individual client
sessions, which are managed by
the server and are independent
of each other. In addition,
Remote Desktop Connection
provides 128-bit encryption
between client and server.

Use
Internet Protocol security
(IPsec) to encrypt confidential
data.

If you manage one or more remote
NPS servers from a local NPS
server by using the NPS
Microsoft Management Console
(MMC) snap-in, you can use IPsec
to encrypt communication between
the local NPS server and the
remote NPS server.

Accounting

There are two types of accounting,
or logging, in NPS:

Event logging for NPS.
You can use event logging to
record NPS events in the system
and security event logs.
Recording NPS events to the
security event log is a new
feature in Windows Server 2008,
and much more information is
logged for NPS than in previous
operating system versions for
Internet Authentication Service
(IAS). This information is used
primarily for auditing and
troubleshooting connection
attempts.

Logging user authentication and
accounting requests.
You can log user authentication
and accounting requests to log
files in text format or database
format, or you can log to a
stored procedure in a SQL
Server 2000, SQL Server 2005, or
SQL Server 2008 database.
Request logging is used
primarily for connection
analysis and billing purposes,
and is also useful as a security
investigation tool, providing
you with a method of tracking
down activity after an attack.

To make the most effective use of
NPS logging:

Turn on
logging (initially) for both
authentication and accounting
records. Modify these selections
after you have determined what
is appropriate for your
environment.

Ensure
that event logging is configured
with a capacity that is
sufficient to maintain your
logs.

Back up
all log files on a regular basis
because they cannot be recreated
after they are damaged or
deleted.

For
billing purposes, use the RADIUS
Class attribute to both track
usage and simplify the
identification of which
department or user to charge for
usage. Although the
automatically generated Class
attribute is unique for each
request, duplicate records might
exist in cases when the reply to
the access server is lost and
the request is resent. You might
need to delete duplicate
requests from your logs to
accurately track usage.

If you use
SQL Server logging, ensure that
you store credentials and other
connection properties in a
secure location. This
information is not exported to
file when you use the
netsh nps export
command.

To provide
failover and redundancy with SQL
Server logging, place two
computers running SQL Server on
different subnets. Use the SQL
Server tools to set up database
replication between the two
servers. For more information,
see SQL Server documentation.