Security Infrastructure Services Lesson 9

Skills Matrix Technology SkillObjective DomainObjective # Using CertificatesPlan infrastructure services server roles 1.3 Securing Remote AccessMonitor 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.

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 a local area network (LAN).

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 integrity checking.

Point-to-Point Tunneling Protocol (PPTP) For authentication, PPTP supports only the Microsoft Challenge Handshake. Authentication Protocol version 1 (MS-CHAP v1), Microsoft Challenge and shake. Authentication Protocol version 2 (MS-CHAP 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 IPsec’s 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 (MS-CHAPv2) 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 Protocol- Transport 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 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 user’s 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 to connect to the server.

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 . Smart card logon. Software code signing. Wireless network authentication.

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 suitable for issuing certificates to clients outside the enterprise.

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 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 been signed by a dedicated CA.

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 revoked.

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 issued by any other CAs subordinate to the root.

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 issuing certificates to end users, but in a three-level arrangement, they typically do not.

CA Hierarchy

Certificate Templates Sets of rules and settings that define the format and content of a certificate based on the certificate’s 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 that template.

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.

Certificate Enrollment Methods Active Directory Certificate Services supports several certificate enrollment methods. A client’s 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.

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. – By using the Certutil.exe command-line program.

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 the root CA.

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 certificate’s 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 client’s 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.

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 CA’s revoked certificates, and delta CRLs. – Delta CRLs are shorter lists of certificates that have been revoked since the last full CRL was published.