FIM CM Deployment Scenarios

Applies To: Forefront Identity Manager Certificate Management

FIM CM is highly scalable and can be configured to support a wide range of certificate management applications. Three typical FIM CM configurations are described below. Each of these scenarios builds on the base FIM CM architecture that has already been described in the section, FIM CM Architecture. The scenarios also identify any additional components required to support the capability. Each scenario describes how FIM CM’s policies can be leveraged to make each of these solutions easier to architect, deploy and support over the long term.

Smart Card Logon

Figure 8, above provides an illustration of the components required in order to enable smart card logon. Essentially the only additional elements to the core infrastructure of Active Directory, Certificate Services, and MS SQL are a BaseCSP enabled Windows XP, Vista or 7 client. The domain controller must be configured to utilize a Windows Domain Controller Certificate template that has smart card logon enabled as shown in Figure 9 below.

FIM CM is central to providing management capabilities in this scenario. It is used to enroll users and associate user accounts with smart cards. It can be used to manage smart cards once user are enrolled and handle situations such as smart card loss and the issuance of temporary cards. Through the use of FIM CM’s reporting features – deployment of smart cards across the enterprise can also be tracked and managed.

Once a user has been enrolled with a smart card – a variety of different applications are available: Smart Card Logon to the network, Smart Card authentication to any AD enabled application, and access to other applications depending on the types of certificates that have been configured on the card.

With smart card based logon enabled, Windows clients can utilize a smart card to authenticate to the Windows network environment. When prompted to logon, the Windows XP GINA recognizes that a smart card has been inserted into the device’s reader and prompts the user for their smart card PIN. Once the pin is received, the smart card certificate is read from the card and the certificate is used to initiate a Kerberos logon to the Windows network environment. Once the authentication is successful users can continue to access network resources or AD enabled applications using their smart card. If the smart card is removed from the workstation, the user session may be configured through GPO settings to lock or automatically log-off the user. Similarly, Smart Card logon for server administration can also be enabled. Smart card based authentication can be performed against any Windows Server 2003 or Windows Server 2008 server running BaseCSP. Any RDP session to the server can also utilize smart card based authentication – providing an AD integrated two factor authentication solution for server administration.

Once users are enrolled to use a smart card, any application that provides integrated Windows Authentication, can utilize smart card based authentication. Internet Information Services (IIS)-based web applications using integrated authentication can leverage the credentials stored on the smart card to authenticate users to web applications without modification. Microsoft Exchange can also access the information on the smart card and use an S/MIME certificate to encrypt and sign emails (more on this scenario in the section, Secure Email (S/MIME)).

The use of smart card based authentication also opens the opportunity for integrated security applications such as using the smart card as a photo identification badge or utilizing a hybrid smart card that includes proximity technology for physical access control applications.

VPN (IPSEC, SSL)

A typical strong authentication scenario is the authentication of remote users accessing a corporation network using VPN technology. VPNs devices are now available with a wide range of protocol support, but the architecture described below is equally application to IPSEC, L2TP, PPTP or SSL based VPNs. In each scenario mobile users who are either working from home or while travelling require access to the corporate network to access email, corporate applications, or other resources available through the corporate network. A secure method of authenticating the remote user is required – typically this is provided via a two factor authentication solution or through the use of software certificates resident on the user’s laptop.

Figure 9 above illustrates the architecture where FIM CM is used to enroll users for VPN certificates. The certificates could be SSL, IPSEC, or regular client authentication certificates depending on the specific VPN endpoint used. In this scenario, VPN client workstations would be issued a certificate using FIM CM. VPN endpoints would also require a certificate and would need to be configured to trust the Issuing CA and to check for revoked certificates using the certificate distribution points configured within the environment.

In this scenario, users logging in from a remote location would first authenticate to their local workstation before initiating a VPN session. When the VPN session was invoked the VPN client software would use the user’s software certificate or smart card to authenticate the session with the VPN endpoint. The VPN endpoint would check the validity of the software certificate or smart card with the enterprise certification authority (CA) and if valid establish an encrypted session.

The primary certificate and lifecycle management issues related to this scenario are: enrollment of users, replacement of authentication cards and tokens, the issuance of temporary cards and revocation of certificates or smart cards. As part of the profile template settings, workflows could be defined for browser based enrollment of users. Similarly, policy settings could be enabled to allow for the temporary issuance of smart cards or authentication tokens in the event that the authenticator was lost, or if it were used to provide remote access to contractors. Finally, FIM CM could be used as the primary interface for revoking access when the employee exits the organization or no longer requires remote access.

If VPN access is provided in addition to smart card logon capability, the existing registration and management model could be leveraged. This would allow multiple authentication services to use the same management system and processes rather than requiring the information technology group to manage two different systems.

Secure Email (S/MIME)

Figure 10 above illustrates a Secure Email architecture based on Microsoft Certificate Services and FIM CM. In this scenario Microsoft Certificate Services is configured to issue S/MIME encryption and S/MIME signing certificates. Microsoft Exchange is used as the messaging platform, while Microsoft Outlook is utilized as the email client. In this scenario, FIM CM’s management capabilities are being leveraged to enroll users with S/MIME certificates and to manage the certificates once they have been issued. In terms of certificate storage, the S/MIME certificates could either be stored locally on a user’s workstation or on a smart card alongside an authentication certificate.

In this scenario, once users have enrolled for their S/MIME certificates they are downloaded to their workstations using the FIM CM user portal. The S/MIME certificates can either be stored locally on their workstations or on Smart Cards if the level of assurance requires it. The S/MIME certificates are also published to Active Directory so that users can lookup public key information to encrypt emails for receiving parties. Once a user has been enrolled for a certificate they can access Microsoft Outlook email encryption and signing functionality (Outlook 2003 and Outlook 2007 both support this functionality if configured). Email that is encrypted or signed is sent in the S/MIME mail format and cannot be read by intermediary parties as it travels between the sender and the receiver.

The use of digital signatures applied to emails is intriguing in this scenario as it provides a business enabler that could be of significant value to an organization. Digital signatures allow for legal binding transactions to occur electronically. Digitally signed emails could be used for electronic orders, signing of contracts between organizations, or for communications that require non-repudiation of the sending party.

Digitally signed and encrypted email poses its own challenges from a certificate lifecycle management perspective. There are two that are unique to this scenario: how do you ensure that a certificate used for digital signatures is tightly bound to an individual’s identity, and how do you recover encrypted emails when a user’s certificate is revoked when they leave the organization.

The flexibility of FIM CM’s enrollment policies allows the first challenge to be easily addressed. FIM CM’s enrollment policies are flexible enough to provide high assurance binding of the digital identity represented by the certificate and their physical identity through a variety of different controls. First, enrollment policies may be configured to gather additional information on the registrant which can be verified against other corroborating datastores such as a human resources system or another employee database. Secondly, enrollment policies may be configured to required explicit approvals once registration information has been collected and approved. This can allow a checkpoint for procedural controls such as verifying the registrant’s Photo ID or other physical credentials. Thirdly, the enrollment policy can require that the user completes the registration process themselves and applies either a password to a digital signature certificate or a PIN to smart card requiring an additional authentication whenever the certificate is used for digital signing purposes.

The second challenge of recovering encryption emails can also be addressed through FIM CM’s recovery policy. This policy allows authorized individuals to recover certificates and utilize them to decrypt information stored in emails that have been encrypted by users that are no longer with the organization. Obviously, this recovery process must occur in a controlled manner and only by individuals authorized to do so. Constraints and limitations may be configured within the recovery process for this as well as additional information gathering to validate the identity of the individual invoking the recovery process as well as capturing information on why the recovery was required.

FIM CM’s management functionality provides an ideal platform to provision email encryption certificates as well as deal with the management challenges that are specific to Email encryption.

High Availability Architecture

The requirement for a high availability FIM CM solution varies depending on the specific business requirement for certificate management or smart card management within a given organization. Since FIM CM is dependent on an underlying Active Directory and Certificate Services infrastructure a combined architecture including FIM CM can only achieve the overall availability of all combined components. In order to understand the impact of failure on the various components of an FIM CM implementation, it is first necessary to consider the interrelationship of the underlying components and how each component affects the overall availability of the system. In this section, the impact of the failure of each component will be identified in conjunction with redundancy, failover and recovery strategies for each component of the architecture.

Active Directory – FIM CM is highly dependent on Active Directory which acts as its repository for certificates, certificate templates, profile templates, and manager and subscriber groups. If Active Directory is unavailable then FIM CM will be unable to operate as will any network operation that is dependent upon Active Directory. Active Directory’s architecture is highly robust and redundant when implemented on multiple server grade machines with an Enterprise environment.

Microsoft Certificate Services – FIM CM is dependent upon Microsoft Certificate Services for all certificate related transactions including certificate enrollment, renewals, revocation and recovery. If Certificate Services is unavailable FIM CM will not be able to perform task involving certificate management. However, end users utilizing certificates will still be operational. High availability strategies for Certificate Services including running issuing CAs on enterprise grade server equipment with RAID storage, redundant CPUs and power supplies. A regular backup regime should be implement to assist in recovery should catastrophic failure occur.

Windows Server 2008 Active Directory Certificate Services provides additional options for supporting a high-availability CA infrastructure. Specifically, this is referred to as CA cluster support. CA clustering provides the capability to configure two CAs in an active / passive cluster configuration – where the passive CA becomes active once the primary server fails. The secondary CA then has full access to the primary CA’s certificate store and can continue certificate operations. FIM CM provides the capability to utilize this functionality through its enhanced support for Windows Server 2008 32 bit Active Directory Certificate Services and CA module support for Windows Server 2008 32-bit. For additional information on CA cluster support available in Windows Server 2008, please refer to https://support.microsoft.com/Default.aspx?id=946797.

FIM CM Portal – The core of the FIM CM’s management interface which is available through the FIM CM portal is dependent on IIS. The impact of an outage on the portal interface is that all FIM CM management and user portal functions would be unavailable for the duration of the outage. Certificate or smart card based functions occurring at the client level would remain unaffected. FIM CM’s architecture permits traditional high availability web server architectures including Round Robin DNS, Network Load Balancing Services (NLBS) Clustering, Web Clustering, or the use of a network appliance can be implemented to ensure the availability of FIM CM servers within a multiple FIM CM server deployment.

SQL Server – The FIM CM portal is dependent on Microsoft SQL Server for storing all certificate and smart card management data. A failure with the FIM CM database and/or the FIM CM server running IIS would render the FIM CM web portal inaccessible. While certificates could still be issued from the issuing certification authority (CA) they would have to be reimported into FIM CM once the system was brought back online. Fortunately, FIM CM’s datastore can leverage high availability and recovery architectures typically used for SQL Server including clustering and transactional replication. SQL clustering uses a common IP shared by two or more servers (with common disk storage) to provides fault tolerance. In the event of failure of one SQL node, communications are automatically redirected to another functioning node in the cluster. Transactional Replication is a real time backup strategy where data is replicated from a primary SQL Server to a secondary SQL Server according to a defined interval. In the event of primary server failure, the FIM CM configuration would have to be manually reconfigured to point to the secondary SQL Server.

Each of the high available strategies identified above can be applied to an FIM CM environment, building on standard high-availability and redundancy techniques used in other Microsoft products. If an enterprise has already invested in a Microsoft high-availability infrastructure, then it is highly likely that ILM can leverage it for its own services.

Previous topic

Operating FIM CM in an Enterprise Environment

Next topic

Benefits of a FIM CM Approach

See Also

Concepts

FIM CM 2010 Technical Overview