MCSE CCNA Boot Camp Notes :

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.
  
   

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.
  
   

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.
  
   

Your NPS server provides authentication, authorization, and accounting for connection attempts to your organization network. You can protect your NPS server and RADIUS messages from unwanted internal and external intrusion.

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.
  
   

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.