1dent1ty cHa0s

In preparation for our DEC 2008 presentation this week we were faced with the challenge of presenting on the rather broad topic of Identity and Access Management portals via Windows SharePoint Services 3.0.  We had to pull a bunch of slides from the deck because it kept running long - one "batch" of slides I really wanted to present was a proof of concept using Windows Authorization Manager (AzMan) to model an application for Kerberos delegation.  The solution calls for using ILM to automate the process for "Kerberizing" an application and ensuring things like Service Principal Names are valid and the proper delegation bits are flipped when necessary. 

I Want My Wizard

The ILM/AzMan solution developed as I was doing the research for my portion of the aforementioned presentation - let me take a step back here and offer some back-story.  I've been an "infrastructure guy" for the better part of fifteen years now ever since I got my first job assembling PC's (ok, I was technically the delivery guy for a week - then I started in assembly).  My foundation was hardware, then technical support, desktop/helpdesk support, server administration, and then systems engineering where I stuck to the plumbing aspects of Active Directory until I moved on to Identity Management.  It's been an interesting progression, but my primary motivation was to make my job and the job of my teammates easier.  Let's face it folks, configuring Kerberos delegation for Active Directory applications is way more difficult than it needs to be (where is the wizard?).  The fact that we're still stuck running 'setspn' in the days when we can do complex process automation is absurd.  So, to complete the back-story, when we were coming up with ideas to submit for DEC 2008, the pain points fresh on my mind were:

• WSS for non-SharePoint people isn't that straightforward - I made a host of newbie mistake that I'm proud to share
• Whenever presented with a screen offering me a choice between NTLM and Kerberos I'm always going to pick Kerberos and to reinforce the previous bullet, that decision comes with some consequences

Needless to say, much of my consternation with ILM "2" Beta 1 had nothing to do with Beta 1 and everything to do with getting WSS dialed in; after all, I was not about to be defeated by that three-headed beast.  The biggest pain point of all kept sidetracking me and hijacking much of the content for the DEC presentation but reality set in (i.e. Jerry) and I had to yank pretty much all of that content and redirect it here.  So while you now have the benefit of my inner monologue, you do have to suffer through "Brad verbose mode".  If you're actually reading this prior to our presentation on Monday morning (March 3rd) you deserve one of the swanky T-shirts our marketing department cooked up that I think are really cool.

  

If you see us around the conference mention this posting and if we have any left you are welcome to one!

The Problem

As I stated before, the manual steps in correctly configuring Kerberos delegation for an application is ridiculous - compound that with the volume of service accounts in your typical MOSS 2007 deployment and you're looking at many points of failure.  Compared to the average eight to ten service accounts needed for MOSS, WSS needs a minimum of three assuming you're using domain accounts and including the SQL service account; manageable right?  When I polled the crowd at a local SharePoint Users Group meeting last week I counted maybe three hands out of 40+ people who had even attempted Kerberos and out of them I think one group had actually gotten the blasted thing configured properly.  Everyone else was getting by happily on NTLM ignorant of the fact that the really cool kids use Kerberos!

A Solution

I've long since had this idea in the back of my brain of using Authorization Manager (AzMan) for modeling applications that ILM could use to provision things like service accounts and the like.  We take the identity lifecycle of people for granted because that is the solution we focus on delivering with ILM.  However, administrative accounts and service accounts are frequently left either out of scope or targeted for future enhancements but let us not forget the importance of tracking the lifecycle of these identities as well.  To focus on service accounts means that we really need to address what function they provide.  Service accounts are merely identities that provide a security principal for running applications and it's the relationship between the application and those identities that we need to focus on.  How many times have you come across accounts in your directory that you are too afraid to delete because no one knows exactly what function they are providing?

For the uninitiated, AzMan is a free Windows add-on that most people are completely unaware of which provides a way to decouple much of the complexities of authorization within your application from the underlying infrastructure (developers should neither know or care about your AD OU structure which has a tendency to change).  If you're not writing "directory aware" applications then you probably have little reason to know anything about it but one of my pet peeves is that so few developers understand what it means to write "directory aware" applications much less use AzMan for authorization but I digress.   All I'll say about AzMan at this stage is that if you're writing applications that are asking the question "is this user a member of group cn=xyz,ou=groups,dc=domain,dc=com" then you need to come out of your cave and read a couple of white papers quick; it's free people!  And don't even think it, there are solutions out there to extend AD to non-Windows platforms as well as extend the AzMan .NET based API to Java based developers so no excuses.

Since this is running long, I'll wrap up this blarticle with an overview of the solution and continue this in the next one.  By using AzMan to model the relationship between service accounts and applications we gain the following pros:

• Developers can build their applications completely isolated from the infrastructure by using the XML data store for AzMan.  This allows them to define each of the operations, tasks, and roles for their applications but not worry about which security groups are actually going to be used to to fulfill them - local groups or direct membership can be utilized during development and these settings imported or migrated later
• The applications themselves are therefore insulated from changes in the infrastructure should groups change, move, be consolidated or expanded in roll; these changes have no impact to the application and there is no recoding or reconfiguration necessary
• Simple delegation is possible to model and with ILM this can be automated to apply the appropriate SPN's and set the bits for trusted delegation
• Segregation of duties (a compliance favorite) becomes possible as we allow developers to request and model one aspect of the application while being divorced from the actual implementation of the security model

We do, however, end up with the following cons to this approach:

• Using AzMan to model the relationships between service accounts and their host applications may be acceptable for simple delegation but the relationships become too complex to model in AzMan alone for accomplishing constrained delegation - for this we'll need a little help from SQL or SharePoint
• We need an outside process like ILM to act on the objects we model and implement the delegation properly

This solution will involve the following bits:

• An ADMA configured to read the AzMan store from AD
• Sample attribute flow code to set servicePrincipalName and userAccountControl
• Walkthrough for configuring AzMan to model the application, service class, host and port designation

To be continued...