Examining Integration Points Between SharePoint and Public Key Infrastructure

The term public key infrastructure (PKI) is often loosely thrown around but is not often thoroughly explained. PKI, in a nutshell, is the collection of digital certificates, registration authorities, and Certificate Authorities that verify the validity of each participant in an encrypted network. Effectively, a PKI itself is simply a concept that defines the mechanisms that ensure that the user who is communicating with another user or computer on a network is who he says he is. PKI implementations are widespread and are becoming a critical component of modern network implementations.

PKI is a useful and often critical component of a SharePoint design. The PKI concepts can be used to create certificates to encrypt traffic to and from SharePoint virtual servers to the Internet. Using Secure Sockets Layer (SSL) encryption is a vital method of securing access to a SharePoint site and should be considered as part of any SharePoint farm that enables access from the Internet.

Understanding Private Key Versus Public Key Encryption

Encryption techniques can primarily be classified as either symmetrical or asymmetrical. Symmetrical encryption requires that each party in an encryption scheme hold a copy of a private key, which is used to encrypt and decrypt information sent between the two parties. The problem with private key encryption is that the private key must somehow be transmitted to the other party without it being intercepted and used to decrypt the information.

Public key, or asymmetrical, encryption uses a combination of two keys mathematically related to each other. The first key, the private key, is kept closely guarded and is used to encrypt the information. The second key, the public key, can be used to decrypt the information. The integrity of the public key is ensured through certificates. The asymmetric approach to encryption ensures that the private key does not fall into the wrong hands and only the intended recipient will be able to decrypt the data.

Reviewing Certificates for SharePoint Portal Server 2003

A certificate is essentially a digital document issued by a trusted central authority and used by the authority to validate a user's identity. Central, trusted authorities such as VeriSign are widely used on the Internet to ensure that software from Microsoft, for example, is really from Microsoft, and not a virus in disguise.

Certificates are used for multiple functions, such as the following:

• Secured SharePoint site access

• Secured email

• Web-based authentication

• IP Security (IPSec)

• Code signing

• Certification hierarchies

Certificates are signed using information from the subject's public key, along with identifier information such as name, email address, and so on, and a digital signature of the certificate issuer, known as the Certificate Authority (CA).

Utilizing Windows Server 2003 Certificate Services for SharePoint Servers

Windows Server 2003 includes a built-in Certificate Authority (CA) known as Certificate Services. Certificate Services can be used to create and manage certificates; it is responsible for ensuring their validity. Certificate Services is often used to generate SSL-certificates for SharePoint Virtual Servers if there is no particular need to have a third-party verify an organization's certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party Certificate Authorities such as VeriSign are also extensively used but require an investment in individual certificates.

Certificate Services for Windows Server 2003 can be installed as one of the following CA types:

• Enterprise root Certificate Authority The most trusted CA in an organization and should be installed before any other CA. All other CAs are subordinate to an enterprise root CA.

• Enterprise subordinate Certificate Authority Must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA.

• Standalone root Certificate Authority The root of a hierarchy that is not related to the enterprise domain information. Multiple standalone CAs can be established for particular purposes.

• Standalone subordinate Certificate Authority A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.

To install Certificate Services on a Windows Server 2003 Server, follow these steps:

1.	Choose Start, Control Panel, Add or Remove Programs.
2.	Click Add/Remove Windows Components.
3.	Check the Certificate Services box.
4.	A warning dialog box appears, as shown in Figure 15.28, indicating that the computer name or domain name cannot be changed after you install Certificate Services. Click Yes to proceed with the installation. Figure 15.28. Certificate Services warning.
5.	Click Next to continue.
6.	The following screen, shown in Figure 15.29, allows you to create the type of CA required. Refer to the preceding list for more information about the different types of CAs that you can install. In this example, choose Enterprise Root CA and click Next to continue. Figure 15.29. Selecting the type of CA server to install.
7.	Enter a common name for the CAfor example, CompanyABC Enterprise Root CA.
8.	Enter the validity period for the Certificate Authority and click Next to continue. The cryptographic key is then created.
9.	Enter a location for the certificate database and then database logs. The location you choose should be secure, to prevent unauthorized tampering with the CA. Click Next to continue. Setup then installs the CA components.
10.	If IIS is not installed, a prompt appears, as shown in Figure 15.30, indicating that Web Enrollment will be disabled until you install IIS. If this box appears, click OK to continue. If IIS is installed, a message is displayed that indicates that IIS will be stopped to complete the installation. Click Yes to continue. Figure 15.30. IIS warning in the CA installation procedure.
11.	Click Finish after installation to complete the process.

NOTE

Certificate Services can be installed on a SharePoint server itself, if necessary, to provide for self-service certificate creation on SharePoint virtual servers. It can also be used on domain controllers, or a separate server entirely, however, in larger or more risk-averse organizations.

Examining Smartcards PKI Authentication for SharePoint

A robust solution for a public key infrastructure network can be found in the introduction of smartcard authentication for users. Smartcards are plastic cards that have a microchip embedded in them; this chip allows them to store unique information in each card. User login information, as well as certificates installed from a CA server, can be placed on a smartcard. When a user needs to log in to a system, she places the smartcard in a smartcard reader or simply swipes it across the reader itself. The certificate is read, and the user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN and the certificate are verified, the user can log in to the domain and access resources such as SharePoint.

Smartcards have obvious advantages over standard forms of authentication. It is no longer possible to simply steal or guess someone's username and password in this scenario because the username that allows access to SharePoint can be entered only via the unique smartcard. If stolen or lost, the smartcard can be immediately deactivated and the certificate revoked. Even if a functioning smartcard were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Layering security in this fashion is one reason why smartcards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Examining the Encrypting File System (EFS)

Just as transport information can be encrypted via certificates and public key infrastructure, so too can the NT File System (NTFS) on Windows Server 2003 be encrypted to prevent unauthorized access. The Encrypting File System (EFS) option in Windows Server 2003 allows for this type of functionality and improves on the Windows 2000 EFS model by allowing offline folders to maintain encryption sets on the server. EFS is advantageous, particularly for laptop users who tote around sensitive information, such as documents checked out of SharePoint document libraries. If the laptop or hard drive is stolen, these documents are worthless and inaccessible to the thief because it is scrambled and can be unscrambled only with the proper key. EFS is proving to be an important part in PKI implementations.

Integrating PKI with Non-Microsoft Kerberos Realms

The Windows Server 2003 Active Directory component can use the PKI infrastructure, which utilizes trusts between foreign non-Microsoft Kerberos realms and Active Directory. The PKI infrastructure serves as the authentication mechanism for security requests across the cross-realm trusts that can be created in Active Directory. After these trusts are in place, user accounts from these non-Microsoft Kerberos realms can be used to allow access to SharePoint sites.