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 public key, is widely
available and can be used to encrypt the information. The second key,
the private key, is kept closely guarded and is 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.
Using SSL Certificates for SharePoint 2010
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 from a
rogue source.
Certificates are used for multiple functions, such as the following:
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 Active Directory Certificate Services for SharePoint Servers
Windows Server 2008 and 2008 R2
include a role that incorporates a PKI hierarchy. This role is known as
Active Directory Certificate Services or AD CS. AD CS can be used to
create and manage certificates; it is responsible for ensuring their
validity. AD CS 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 issues certificates only for internal parties.
Third-party CAs such as VeriSign are also extensively used but require
an investment in individual certificates.
Certificate services for Windows Server can be installed as one of the following CA types:
Enterprise root CA—
The root of a certificate chain that is also incorporated into an
Active Directory domain and can be used to automatically enroll clients
and systems with certificates.
Enterprise subordinate CA—
Must get a CA certificate from an enterprise root CA but can then issue
certificates to all users and computers in the enterprise.
Standalone root CA—
The root of a hierarchy that is not related to the enterprise domain
information. Multiple standalone CAs can be established for particular
purposes. An enterprise subordinate CA can be created from a standalone
root CA, which is often the case in security situations where the root
needs to be on a workgroup system, not a domain member.
Standalone subordinate CA—
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.
Examining Smartcards PKI Authentication for SharePoint
A robust solution using a PKI
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.
