Forefront Identity Management – Certificate Management (FIM CM 2010) – Part 5

FIM Permission Model

As this is the most difficult part in the FIM CM deployment, I will try to make it easy and simple. Please refer to Microsoft TechNet for basics and then read this section to complete the missing points.

I will be referring to the following terms here:

  • FIM CM Subscribers : those are usually end user ( certificate consumers)
  • FIM CM managers: those are the users that are assigned a management role through the FIM CM portal. This can be the FIM CM full admin, or just a help desk that is assigned the task to offline unblock smart cards.

FIM Permissions: are the new permissions that are introduced by the FIM CM Installation Schema extension (Please refer to Microsoft TechNet for more information about FIM CM Extended Permissions)

 

FIM_CIM_Permission_Model_334

The permissions and rights are assigned in five different places:

  • FIM CM subscribers Group: Permissions are FIM Extended permissions.
  • Service Connection Point: Permissions are FIM Extended permissions.
  • CA Certificate Templates: Permissions are (Read) and/or (Enroll).
  • FIM CM Management Policy: what you see when you configure a profile template.
  • FIM CM Profile Templates:
    • Profile Template Container : Permissions are (Read) and/or (Write)
    • Profile Templates : Permissions are :
      • “Read” and “CLM Enroll”: For Certificate Consumers.
      • “Read” and “Write”:  For FIM CM Full Admins.

Note that FIM CM managers will need permissions on all five locations, while end users (FIM subscribers) should have permissions only on those places:

  • Service Connection Point (Required)
  • Profile Template container and Profile Templates (Required).
  • CA certificate Template: Only if they will do the actual enrollment.
  • FIM CA Management Policy: Only if they will do the actual enrollment.

1.  Permissions at the Service Connection Point SCP

Rights at the service connection point SCP determine if the user is a typical FIM subscriber (FIM CM Certificate consumer) or has a management role in the FIM CM portal

  •  FIM CM Subscribers Group : “Read”
  • FIM CM Managers : “Read” and “FIM Extended Permissions”

For example: in a help desk scenario where help desk team needs to be able to only offline unblock smart cards , they should have ( CLM Request Unblock) and ( CLM Enrollment Agent) , and frankly speaking this is confusing but this is how things work.

 

FIM_CIM_Permission_Model_SCP_44867

2. Permission at the FIM CM Subscribers Group

Once FIM CM manager got the required permissions on the SCP, to restrict their permissions to a group of users, you should assign FIM CM extended permissions on the group of users that you choose :

  • FIM CM Full admin : should have all the FIM CM Extended Permissions
  • FIM CM Manager : This is an admin

For example: in a help desk scenario where help desk team needs to be able to only offline unblock smart cards , they should have ( CLM Request Unblock) and ( CLM Enrollment Agent) , and frankly speaking this is confusing but this is how things work.

FIM_CIM_Permission_Model_Group_44767

 

3. Permission at the Certificate Templates

The golden role is:

  • If the end user can enroll a certificate from the FIM CM portal by himself, then he needs (Read + Enroll) permissions on the certificate template.
  • If the Actual Enrollment is done by a FIM CM Manager, then that manager only needs the (Read + Enroll) permissions on the certificate template.

FIM_CIM_Permission_Model_CA_58987654

4. Permission at the Profile Template

There are two places to assign permissions here:

  1. Profile Template Container :
    1. FIM Subscribers : Read
    2. FIM Full Manager only : Read + Write
    3. FIM Managers : Read
  2. Profile Templates
    1. FIM Subscribers: Always should have (Read + CLM Enroll).[1]
    2. FIM Manager : The FIM manager that will perform enroll on behalf of the user , should also have ( Read + CLM enroll)

Note: FIM Subscribers should ALWAYS have Read and CLM Enroll at the profile template even if they do not do the actual enrollment.

So in case of a centralized deployment were the FIM Manager will initiate the request and will enroll on behalf of user and thus executes the enrollment , both the FIM manager AND the FIM subscribers should have (Read + CLM Enroll) at the profile template.

 

FIM_CIM_Permission_Model_Profile_Template_4343

5. Permission at the FIM Management Policy

Here where you configure the Profile Template by accessing the FIM CM admin portal. A new role is introduced here which is (Approve Request), which could be the user business manager. The (Approve Request) role should be granted the following:

  1. (CLM Audit) and (Read) at the service connection point.
  2. (CLM Audit) and (Read) at the FIM CM Subscribers group.
  3. Assigned the (Approve Requests) from within the FIM CM management Policy.

 

FIM_CIM_Permission_Model_FIM_Policy_$343

 

Summary

 So here is a quick summary for all FIM CM Permission Model 🙂

 

FIM_CIM_Permission_Model_FIM_Summary_$3354

Forefront Identity Management – Certificate Management (FIM CM 2010) – Part 4

FIM CM and CA integration

It is very important to understand the integration between the FIM CM and the CA server. The FIM CM installation files will add two modules in the CA server (Policy module and Exist module):

  • In the CA FIM Policy module: you configure the thumbprint of the FIM Agent Certificate. This will ensure that communication with the CA server is authenticated and encrypted.
  • In the CA FIM Exist module: you configure the FIM CM database SQL connection string. This will allow the CA to write to the FIM CM database.

Note: In order for the CA to access and the FIM CM SQL database, you have to create logon for the computer account of your CA server with (public and clmapp) rights on the FM CM database.

In simple words, the FIM Agent certificate is used to protect traffic between the CA and the FIM CM server, and the FIM KRA certificate is used to encrypt archived keys in the CA database.

FIM_CIM_CA_Integration_3322

Forefront Identity Management – Certificate Management (FIM CM 2010) – Part 3

FIM CM Agents

The powerful of FIM CM and its ability to proxy requests to the CA and to proxy identities is done by the concept of FIM CM Agents. Those agents are usernames in your directory that are used by FIM CM to perform its tasks. You have to configure the web.config file to associate some of the FIM CM agent accounts with their certificates.

Note: FIM CM Initial Configuration Wizard will allow you to automatically create and configure those accounts for you. It is highly recommended that you choose to create them manually and even enroll them for certificates manually. This is very important for later manageability especially when those account certificates are about to expire. You have to create those accounts in Active Directory prior of installation.

FIM_CIM_#333392

FIM Agent

The first agent account used by FIM CM is called simply (FIM Agent) which is a very important account. Configuring this account correctly from the first time will ensure smooth deployment of FIM CM in your corporate.

FIM Agent is enrolled for Signing and Encryption Certificate usually from the (User) certificate template. I choose to duplicate the (User) template and configure the key to be exportable.

Once you get a certificate for encryption and signing, you have to log on to the FIM CM server with the FIM Agent account, and install the certificate in the user personal certificate store.

FIM Agent user is used for the following tasks :

  • Protect communication between the FIM CM server and the CA.
  • Revoke Certificates.
  • Encrypt Smart Card Admin Keys in the FIM CM database.
  • Encrypt (Data Collection) that is requested by the FIM CM portal, in the FIM CM database.

FIM_CIM_Agents_FIMAgent_2322322

You need to make sure that the thumprint of the FIM Agent certificate is placed in the following sections in the FIM CM web.config file :

  1. <add key=”Clm.SigningCertificate.Hash” value
  2. <add key=”Clm.Encryption.Certificate.Hash” value
  3. <add key=”Clm.SmartCard.ExchangeCertificate.Hash” value

 FIM KRA

The second account is the FIM KRA account. This account is used to recover archived keys from the CA database .You should enroll this account a certificate from the template Key Recovery Agent and configure the CA server to use it for key recovery. This account should be member of the local administrators group on the FIM CM server

FIM_CIM_Agents_FIMKRA_333452

FIM Enroll Agent

This account is the account that will perform the actual enrollment of certificates. You should enroll this account a certificate form the (Enrollment Agent) certificate template and you would place the certificate keys to an HSM for enhance protection. This account is what makes it possible to proxy identities when enrolling through the FIM CM portal because the FIM CM admins will not be enrolled for enrollment certificate in this case, instead, they will be assigned a management role in the FIM CM profile template while FIM CM Enroll Agent is the actual user that will perform the enrollment.

The FIM Enroll Agent should have (Read, Request Certificates) on the CA server.

The thumbprint of the FIM KRA agent should be inserted in the following filed of the FIM CM web.config file:

(<add key=”Clm.EnrollAgent.Certificate.Hash” value ).

FIM_CIM_Agents_FIMEnroll_#43433433

FIM Authentication Agent

This agent doesn’t need a certificate to function. The main purpose of this account is to provide a security context for FIM CM services to read configuration data in Active Directory.

The account should be granted the following permissions and rights :

  • “Generate Security Alerts” right in the FIM CM server
  • Member of the (Pre-Windows 2000 Compatible Access) group in AD.
  • “Read” Permission on the CA certificate Templates
  • “Read” and “Write” on the FIM Profile Templates
  • “Create Child Objects” on the Profile Template Container”

Note: If you don’t want some of the legacy profile templates to appear on your FIM CM admin portal, just remove the “Read” permission of the FIM Auth Agent from those profile templates.

FIM_CIM_Agents_FIMAuth_44443

FIM CA Manager

This agent is used by FIM CM to perform CA management tasks like issuing CRLs or delta CRLs when a smart card or certificate is retired or disabled for example.

This account should have “Read” and “Manage CA” rights on the CA

FIM_CIM_Agents_FIMCA_3322

FIM Web Pool Agent

This is one of the most important agents in FIM CM deployment, as it runs the application pool identity for FIM CM portal. This account is used also to access the FIM CM database.

This account should have the following rights and permissions

  • “Generate Security Alerts” right on the FIM CM server.
  • Member of the local administrators group on the FIM CM server.
  • Member of the (IIS_USRS) local group in the FIM CM server.
  • “Act as part of the operating system” right in the FIM CM server.
  • “Replace process level token” right in the FIM CM server.
  • “Read” on the FIM CM Registry Keys.
  • Trusted for delegation for the CA server.

FIM_CIM_Agents_FIMwEBeNROLL_#3333

FIM Agents all together

FIM_CIM_Agents_FIMALL_3777

Forefront Identity Management – Certificate Management (FIM CM 2010) – Part 2

FIM CM Components

FIM CM is a portal that runs under its own application pool identity .Configuration of the product is done by manipulating the web.config file (Located here c:\Program Files\Microsoft Forefront Identity Manager\2010\Certificate Management\web). Knowledge of the sections in the web.config file is required for FIM CM administration.

FIM CM uses its own database (FIM CM default database name is (FIMCertificateManagement) that is created during the initial configuration wizard when you first install FIM CM on your server. The FIM CM uses its application pool identity for database access. A new SQL Role is introduced named (clmapp) and should be granted to the FIM CM application pool identity. The FIM CM database contains information about smart cards, and their admin keys.

FIM CM also stores profile template data in the configuration partition of Active Directory. DACL on those profile templates determine part of the authorization model within FIM CM.

FIM CM also has its own Service Connection Point (SCP) under the system container in AD .Permissions on the SCP determines if users are allowed to log on to the FIM CM admin portal or user portal.

FIM CM portal comes in two modes, user mode in which end users enrolled with certificates can view their digital identity information or request new ones, and admin mode, in which FIM CM admins perform their management tasks. Permissions on the SCP control which mode to be accessed.

As part of FIM CM installation, AD schema is extended to include new FIM CM permissions like (CLM audit, CLM Request Enroll …).

Note: You can place the FIM CM database in a backend SQL, or on the same server as FIM CM server. In all cases, I recommend to have the FIM CM database on a dedicated SQL server that doesn’t host any other database. The reason behind this is that you don’t want your company SQL administrators to have high privileges on this database as it contains sensitive information.

FIM CM communicates heavily with:

  • Active Directory : for authentication , authorization and profile templates configuration
  • SQL Database: to store information especially smart card information and its admin keys.
  • CA: one or more CA servers to request certificates or revoke existing ones.
  • Mail Server: to send notifications if configured.
FIM_CIM_324553343

Forefront Identity Management – Certificate Management (FIM CM 2010) – Part 1

What FIM CM all about?

FIM CM is a management interface between administrators and the certificate authority services .In other words , FIM CM will proxy your requests to the certificate authority services , and by using proxy  I mean from interface perspective and from security context perspective.

It is clear to all of us that Microsoft Certificate Authority Server, especially before the Windows Server 2008 becomes RTM, lacks many features and auditing requirements.

In the days of Windows Server 2003 Certificate Authority, you have to enroll for Enrollment Agent certificate and give it to the person who will be enrolling smart cards in your company. Will this approach is not good enough, since gaining access to that Enrollment Certificate means that being able to enroll for anyone in the corporate. Imagine if this certificate gets compromised. This approach doesn’t scale well if you have global corporate and you want the admins in Europe to enroll for users in their region only, while the admins in Dubai to enroll for users in the middle east .

Although Microsoft Windows Server 2008 R2 came with a great feature called (Restricted Enrollment Agents) to restrict each enrollment agent certificate to a specific users and group, the need still exists for a management approach when it comes to certificates and smart card enrollment.

FIM CM extends the functionality of the Certificate Authority Services that exists out of the box with Windows  , by adding workflow approach , auditing capabilities , notifications ,and introducing many management roles like request renew and request offline unblock and more .All this can be defined inside a management policy approach by utilizing something called (Profile Templates ) inside FIM CM.

Besides extending the functionality, FIM CM acts as a security context proxy, by using the concept of FIM CM Agents. Every action that FIM CM performs is done in the context of one of FIM CM Agents. Those agents are also used to sign and encrypt traffic between the FIM server and the database server, and between the FIM server and the CA server, besides encrypting some data inside the FIM SQL database itself.

Because FIM CM is using those agents for almost all operations, FIM agents need to be enrolled for Encryption and Signing certificates, Enrollment Agent certificates and Key Recovery Agent certificates. Those certificates can be protecting by HSM as gaining access to the enrollment agent certificate is very dangerous. The system administrators thought only needs to have a management role on the FIM CM management policies and they don’t need to have enrollment agent certificates anymore , because the enrollment agent certificate is now owned and managed by FIM CM agents ( via HSM if needed).

Microsoft Forefront Identity Management – Certificate Management (FIM CM 2010) – Migration/Upgrade

I can see that im getting many hits in my blog for the PKI category, so i decided to invest some time writing about one of my favorite PKI topic, which is Microsoft certificate management software FIM CM 2010.

This deployment guide is written to explain missing points on Microsoft FIM CM TechNet documentation .It also contains some explanations about the functions of FIM CM agents, and some explanation about the authorization model that FIM CM is using . No doubt that Microsoft internal staff admit that the security model that FIM CM is built on , is considered the most complex one.

Regarding installing FIM CM 2010, all steps are there in Microsoft TechNet portal and I will not go and repeat the steps required for installation. Instead I will highlight some key points.

Some organizations are already implementing the old product for identity management called CLM 2007 (Microsoft Certificate Lifecycle Management), and in my corporate we already have CLM 2007 FP1 in place. Now, FIM CM 2010 came and there is lack of documentation in Microsoft TechNet about how to upgrade your existing CLM to FIM. This is something I will be discussing in this Blog.

 

Who should be reading this 

This is level 400 documents and you should have good knowledge about Microsoft CLM 2007 and you should be familiar with technologies like Active Directory, Smart Cards and PKI fundamentals.

Assumptions

We will put some assumptions in this blog to make things easy to explain. First we have a current infrastructure in place serving any smart card or certificate enrollment requests (shown on the right side of figure 1). The old infrastructure consists of a server named (CA2003) acting as Microsoft Certificate Authority on Windows Server 2003 SP2.

On the other hand, we have the new infrastructure that we will migrate to. It consists of a new Windows Server 2008 R2 Certificate Services and a new FIM 2010 Certificate Management server running on Windows Server 2008 R2. The FIM2010 Server runs SQL 2008 R2 Standard Edition also.

I will be using FIM CM to refer to FIM2010 Server in this blog. I will be also using (old CA) and (new CA ) to refer to CA2003 and CA2008R2 respectively .

FIM_CIM_4824242

Migrating from CLM to FIM

 

Now, let us move to the difficult part which is migration from CLM 2007 to FIM 2010. Please consider the following assumptions:

  • There is an old CA 2003 in place called CA2003.
  • There is an old CLM 2007 server named CLM2007 using CA2003 for certificate services.
  • Users are enrolled for smart cards from a CLM profile template that uses the following certificate templates from CA2003:
    • Certificate template named (Corporate Encryption Template).
    • Certificate Template named (Corporate Signing Template).
  • There is a new CA2008R2 that will use the same certificate templates mentioned previously.
  • There is a new FIM CM 2010 server named FIM2010 using CA2008R2 for certificate services.

 

Approach for migration

So now we have users with smart card, each smart card contains signing certificate and encryption certificate. We need to migrate to FIM 2010 and frankly all you need to care about it the encryption keys or S/MIME certificates in other words. So why signing certificates are not that important? The answer is we can simply issue users new signing certificates and nothing will not be affected nor the smart card users will feel any difference. After all, you should not archive signing only keys for non-repudiation purposes.

So, what need to be done, is to enroll users smart cards with the following certificates on it :

  • New Signing Certificate from the new CA2008R2.
  • New Encryption (SMIME) certificate from the new CA2008R2.
  • All old encryption certificates from the old CA2003

After that we are going to revoke those old encryption keys on the old CA2003 so they can be used for decryption only operations.

Migration Steps

To do this, the following steps should be done:

  1. Export the old encryption keys from the old CA2003 CA.
  2. Configure the new CA2008R2 to accept External Certificates.
  3. Configure the CLMUtil.exe.config file located in the FIM CM server with OID of the (Corporate Encryption Template)
  4. Import those pfx files to the new CA2008R2 ( they will be shown as External Certificates in the CA console) and to the new FIM2010 server ( the encryption keys will be marked as external)
  5. Configure the FIM CM profile template for smart cards and includes the following certificate templates :
    1. Certificate template named (Corporate Encryption Template).
    2. Certificate Template named (Corporate Signing Template).
  6. Configure the same profile template to include X number of External Certificates.

Note : Corporate Encryption Template and Corporate Signing Templates are just my own example of two certificate templates  that issues encryption/signing certificates.

 

The following TechNet article contains step by step instruction to perform the import of external certificates.

http://technet.microsoft.com/en-us/library/ff602882%28WS.10%29.aspx

 

Cache Credentials and users with one smart cards or more

Cache credentials in windows is useful if you want to access your machine while you don’t have domain controller connectivity . You can use group policy to turn on or off this feature and determine how many accounts to cache .

If the user Bob has a smartcard and logons twice, once as domain\bob and his password, and once with his smartcard and PIN – he will have 2 entries in the cached logon list .So he can go home (offline) and log on using username and password or smart card

Likewise, if the same user Bob has 2 smartcards, and he logs on with SC1 and then SC2 , the cached info for SC2 will be the only card he can use to logon with cached credentials, as it will overwrite the data from  the cached logon from SC1 ( most times ).

This scenario has come up where the security team  issue a user 2 cards , one in case he leaves the other at home or work. He logs on at work with SC1 and when he gets home, expects to logon cached via SC2 etc.Because of the way logon information is cached, the certificate for the second smart card must be issued by another issuing certification authority (CA). If a different CA is not used, the last smart card that the user used online is the only smart card that can be used to log on when they are offline.