The CLM installation wizard extends the AD schema with a set of CLM-specific
objects and attributes. CLM uses these AD objects to store the CLM certificate
and smart card profile information. CLM profiles contain the management policies
that are linked to a given certificate or smart card type. These policies include
the enrollment, recovery, renewal, revocation, disabling, unblocking (for smart
cards only), and duplication (for smart cards only) policies. You define CLM
profiles, their properties, and their related management policies in the Edit
Profile Template interface (shown in Figure
4), which you access through the Administration\Manage profile templates
option in the CLM management interface.
CLM also leverages AD to store CLM user and administrator data and to define
CLM administrative delegation. For the latter purpose, the CLM installation
wizard extends the AD authorization model by adding the following CLM-specific
permissions to AD: CLMS Audit, CLMS Request Enroll, CLMS Enrollment Agent, CLMS
Request Recover, CLMS Request Renew, CLMS Request Revoke, CLMS Request Unblock
Smart Card, and CLMS Enroll.
You can use these CLM-specific permissions to define how users and groups can
interact with the CLM system. For example, you can specify that a particular
user can initiate a certificate request to the CLM system or that a particular
administrator can request the CLM system to revoke a certificate.
The CLM-specific permissions can be set on AD user, group, and CLM profile
objects by using the classic AD management tools. Figure
5 shows how you can give an AD user CLM-specific permissions from the MMC
Active Directory Users and Computers snap-in. To give a user permission to enroll
for a particular CLM certificate or smart card type, you must set permissions
on the corresponding CLM profile object. You can do this from the Services\Public
Key Services\Profile Templates node in the MMC Active Directory Sites and Services
snap-in, as Figure 6 shows.
CLM can interface with the smart cards, smart card readers, and USB tokens
from various vendors. To let CLM and Windows interoperate with a particular
smart card, the vendor must make available a Windows CryptoAPI-compliant Cryptographic
Service Provider (CSP) software module. This CSP must also be deployed on all
Windows machines (both clients and servers) on which smart cards, USB tokens,
and CLM will be used. You can find a list of preferred Microsoft CLM smart card
vendors at http://www.microsoft.com/windowsserversystem/clm/partners.mspx.
As previously mentioned, CLM-integrated management of smart cards or USB tokens
in an AD environment also requires the installation of CLM client software,
which comes with the CLM server distribution package. Included in the CLM client
is a tool that lets users reset their smart card or USB token PIN without administrator
intervention.
Focus on Identity
CLM is another proof of how Microsoft is gradually becoming an important identity
management solution player. Over the last few years, the company has been ramping
up in the identity space by extending the reach of the identity management services
that are bundled with its OS platforms. Microsoft now offers identity management
solutions that can cover non-Microsoft platforms and applications: Good examples
are the Microsoft provisioning solution (the aforementioned MIIS), UNIX integration
services (Services for UNIX—SFU—and Windows 2003 R2), and last but
not least, Microsoft's PKI solution (bundled with Win2K and Windows 2003) and
CLM. You can find more information about CLM at http://www.microsoft.com/windowsserversystem/clm/default.mspx.
End of Article
Register
