My quest to bring Best Practices to Identity Management especially with Microsoft FIM / ILM

Friday, August 14, 2009

AD RMS on R2 -- new Federation Features

AD RMS on Windows Server 2008 R2 adds a really slick feature blogged about here: Group Expansion for Federated Users

Prior to R2 to issue a use license to a federated user they need to specifically be granted permissions. With Windows Server 2008 R2 you can create a contact matching the external federated user and then place the contact in the group and then they have the same RMS permissions as that group.

This is great to be able to include external users in groups, and still without provisioning a user account for them in your domain. Oops, now we need to provision a contact object for them and put that into the group. But perhaps if we combine this capability with custom claims transformation modules to do on demand provisioning the way my coworker Chris Calderon demonstrated on Windows Server 2008 at TEC 2009 (to get his slides go to  http://theexpertscommunity.com/item/show/blog/659/TEC-presentations-now-available  and follow the instructions).

But On-Demand Provisioning only solves half of the battle (and here all of the GI Joe fans thought knowing was half the battle ;)

Even though the user's access has been turned off by their employer disabling or deleting their account, the contact objects on your side still need to get cleaned up. But how to know when to deprovision an account from a federated partner? Perhaps you could use the RMS logging database as a starting point and look for users that haven't accessed the system in a while, email them and see if you get a bounce. After receiving an NDR for a federated user that hasn't accessed anything for months would be a pretty safe bet to delete their contact object.

How to make that happen? Create your own service or scripts to automate querying the logging database and sending the email. Another script to check for NDRs and then write to a table the contacts to be deleted. Then use FIM to read the table and delete the contacts, or your script could do it directly, as appropriate.

Labels: , , , ,

Tuesday, June 2, 2009

To PKI or not to PKI?

When should one implement a Public Key Infrastructure and when should one not? Obviously we implement a PKI to solve a problem, usually around security, enabling secure communications with a web server, multi-factor authentication, encryption. A PKI solution can be very versatile, but it comes at a price in setup and maintenance. But what alternatives do we have? Let's examine each problem in turn

 

Problem PKI difficulties Alternatives Benefits for Alternatives
Enable Secure web transactions (SSL) certs expire without warning anyone none  
Secure network communications (IPSEC) Need to issue certificates to all client computers (can use AutoEnroll GPO) none  
Multi-factor authentication for Wireless networks using 802.1X Need to issue certificates to all client computers or smart cards to all users Radius -- One Time Password Tokens With Quest Defender issuing and maintaining of OTP is very easy. Defender is much easier than standing up a PKI and issuing smart cards to everyone
Multi-factor authentication (certificates, smart cards) Need to issue smart cards to all users (can be time consuming) Need special hardware One Time Password Tokens With Quest Defender issuing and maintaining of OTP is very easy. Defender is much easier than standing up a PKI and issuing smart cards to everyone. Can work even on computers without the smart card reader.
Encryption of files (EFS) Need to issue smart cards to all users (can be time consuming) AD Rights Management Services Enrollment of users is transparent -- new users can be given permissions by adding them to groups without having to re-encrypt the files. No need to renew certificates. Restrictions are enforced after file is opened. It allows you to assign rights and permissions to other people to documents (open, saving, edit, print, cut and paste) and emails (forward, cut and paste)
Enabling users (internal and/or external) to use your code without getting scary warning (Signing Code Modules, Macros, ActiveX controls etc) Need to issue/buy certificates for developers none  
Signing emails Need to issue certificates (whether on smart cards or not) to all users PGP (web of trust)  
Encrypting emails Need to issue certificates (whether on smart cards or not) to all users AD Rights Management Services

or
PGP (web of trust)
AD RMS Enrollment of users is transparent. Restrictions are enforced after file is opened. It allows you to assign rights and permissions to other people to documents (open, saving, edit, print, cut and paste) and emails (forward, cut and paste)

In short you need certificates for SSL, IPSEC, code signing and signing emails. Whether you build your own PKI or get certificates for them is another question. For SSL and code signing you can get away with buying your certs and should if your web site and/or code is for the public (although if you have enough you may want to look at setting up a subordinate CA with a Public CA that way you control the certs but they are issued through a trusted root CA and your customer don't get those confidence inspiring messages asking them whether to trust you or not) . For IPSEC and signing emails you should implement your own PKI in order to save the cost of buying so many certs.

If you need to implement signing of emails along with multi-factor authentication then it makes sense to take advantage of the versatility of certificates on smart cards. Then it makes sense to implement the Certificate Management component (CLM) of ILM 2007 to ease many of the challenges with issuing and managing smart cards.

However, if multi-factor authentication and encryption are your main goals you may want to take a look at one time password tokens with Defender and Microsoft's AD Rights Management Services (AD RMS) respectively. Both present easier and perhaps cheaper alternatives, that also add capabilities. Defender adds the capability to use multi-factor authentication on machines without smart card readers, and AD RMS adds the capability to restrict what users can do with content even after they decrypt it.

Labels: , , , , ,

Saturday, August 16, 2008

IDM in pop culture

Some days I am amazed at how deeply the identity management concepts have penetrated into popular culture:

"Mr Big Stuff, who do you think you are?" clearly relates to an authentication issue or authorization issue.

"Won't get fooled again" by the WHO is clearly making a reference to a Certificate Revocation List, now that I have revoked your certificate you won't be authenticated again.

One area where pop culture is still shockingly uninformed still need help is in asset protection. I guess the authors of many forlorn love songs wish they could have used Rights Management Service and issued a use license that did not contain the permission to "Steal my heart" and "Break my heart."

Labels: , , , ,

Wednesday, May 7, 2008

The Grand Unified Demo of Identity Management

As I was architecting and assembling the Identity All Up workshop (part of the 2008 Directory Experts Conference see the review by Felix Gaehtgens, an analyst for Kuppinger Cole) designed to expose the attendees (or delegates) to all facets of the Microsoft Identity Access Platform, Lori Craw, from Microsoft referred to this as the "Grand Unified Demo". I chuckled, instantly catching the reference to the still undiscovered Grand Unified Field theory that eluded Einstein and even today's theoretical physicists.

In creating and delivering this workshop, I have reinforced, my earlier belief that the Active Directory (AD) is the medium through which most of these interactions happen that allow for interactions between these components of the platform, and Identity Lifecycle Manager (ILM) is the driving force.

Allow me to explain -- In order to manage the lifecycle of smart cards through Certificate Lifecycle Manager (CLM) you must belong to groups in AD that have been assigned permissions to the CLM Service Connection Point, the CLM Profile Template, the CLM Certificate Template, and a group that contains the user upon whom you will act. How do you get into these groups? Through Identity Lifecycle Manager! So AD is the medium and ILM the driver.

In the case of CLM, ILM also has a more direct connection through the Certificate Lifecycle Management agent through which ILM can provision, enroll requests, termination requests, suspend requests, renewal requests, and unblock requests.

Let's take a look at Active Directory Rights Management Services (RMS). With RMS permissions as with most other permissions, they are assigned to Groups in AD. Once more -- AD is the medium and ILM is the driver.

Now please turn your attention to Active Directory Federated Services (AD FS). Users get access to resources at the resource partner by virtue of having claim that gives them access, most of the time this claim will be a group claim. Once more -- ILM is driving through the medium of AD.

Even more, look at AD RMS integration with AD FS. Now we can extend Rights Management protection to documents while sharing them with partners without the unrealistic expectation for the partner to have their own AD RMS infrastructure (the requirement for RMS prior to Windows Server 2008). Once more, access for partners is through being member of a group that establishes an outgoing claim to the resource partner that is then consumed by RMS, and once more the best way to get users into groups is through ILM.

Expand your horizons, once more, now using a smart card (provisioned through an ILM request to CLM), we can authenticate to the Directory build the list of groups to which we belong (managed by ILM), we can access an RMS protected document at a Partner's SharePoint site, and have the appropriate restrictions apply to us.

Wait, what about AD Lightweight Directory Services (AD LDS -- formerly known as ADAM), and Windows Cardspace? Where do they fit in?

AD LDS can be used as another repository for storing identities usually for your extranet, for partners that aren't federation ready (either because of lack of size, technology, or policy). AD FS can use AD LDS as one of its account stores! Hence the same protection of RMS documents can be extended once more to non-federation partners without the need for another RMS infrastructure -- in fact vendors could offer RMS as a service using ADFS and AD LDS to cover the authentication needs.

What about Card Space? Card Space, can also be incorporated, but that is a topic for another day.

I want to give special thanks to Chris Calderon for his tireless efforts in helping me setup the virtual machines and hammering out the AD RMS AD FS integration with Sharepoint. Thanks also to David Wozny (pronounced Wahznee) for improving and delivering the deepdive into CLM. Thanks to Craig Martin for assisting David Wozny in improving the ILM deepdive. Additional thanks to Bob Tucker for helping with the VM setup. Thanks to Hugh Simpson-Wells and James Cowling for editing the labs. Thanks to James Booth for listening and improving while I dreamed up the scenarios used in the labs.

Labels: , , , , , ,