1dent1ty cHa0s

Welcome back to the series on Kerberos Service Principal Names, in this blarticle we're going to examine using something like Windows Authorization Manager (AzMan) to model the SPN relationships with the application they represent. 

Why AzMan?

If you're following good development practices for writing "AD aware" applications then you should already be using AzMan to decouple the authorization burden from your applications. If you are not currently using AzMan and you find yourself having to know an awful lot about how your AD is structured or are tired of changing your code whenever a re-org happens and OU's shift around then I strongly recommend checking out the AzMan Team blog:

http://blogs.msdn.com/azman/

There are a ton of great links here as well as the very highly recommended AzMan Developer Whitepaper which is simply a phenomenal read, even for IT Pro's like myself. The overview is as follows:

As corporate security and regulatory compliance requirements increase, the need and demand for a simple and common application authorization model grows. Today's application developers and enterprise administrators are aligning around Role-Based Access Control (RBAC) but are confronted by differing terminology and implementations. Authorization Manager provides a consistent and flexibility RBAC framework for Windows-based applications.

Authorization Manager is a role-based application framework which provides runtime access validation methods, storage, and a UI to manage access control. Authorization Manager is available on Windows Server® 2003, Windows XP, and Windows 2000 (runtime only.) Authorization Manager is an alternative to custom authorization solutions that tend to be limited in features, poorly integrated with the system, or very expensive to design and maintain.

Authorization Manager provides a high-end authorization solution for .NET applications and COM applications. Authorization Manager supports the use of Windows integrated, Active Directory® Application Mode (ADAM) authentication, Active Directory Federation Services (ADFS) claims aware applications, and SQL Server or custom authentication. The Authorization Manager runtime is separate from the authorization policy store, which may be stored in Active Directory, ADAM, or XML.

So, AzMan also has a play in the Claims and Federation scene as well, but from an IT Pro perspective, if you're managing your company's AD and your developers aren't using AzMan, then you may want to introduce this to them. A few years back Microsoft began to change their tune as to who was responsible for what features and it became painfully clear that expecting developers to account for authentication and authorization security features in every thing they build is just not a good way to do business. As you are probably already painfully aware of, the role of security in this respect is really a infrastructure concern and shouldn't vary from app to app. AzMan gives you an infrastructure layer that allows you to abstract the way applications authorize against AD and absolves the developers from  having to know anything about how AD is structured, what the DN's or sAMAccountNames of the groups they need to authorize against and so on. Furthermore, AzMan insulates them from changes to the environment so these things can change without the need to modify code or configuration files! But enough about AzMan, we're here to talk about Kerberos.

Service Classes, Hosts and Ports

So, if you're using AzMan to model an application for authorization you already have a set of objects in the directory that represent a given line of business application. The only thing you don't have here is something that associates the various service accounts needed to run this application. You may have a whole host of application pool accounts, SQL Server accounts, and application service accounts that are all affiliated with this single application entity. From a compliance and auditing perspective it would be nice to have this association for reporting. From an account lifecycle perspective it sure would be nice to be able to control the lifecycle of the accounts via the status of the application, and from a Kerberos delegation perspective it would be awesome if all of the right SPN's were assigned and maintained along with the application definition. Since AzMan only provides the definition itself for us we need some additional parts to complete our puzzle, we'll need:

• ILM 2007 to control the lifecycle of the identities, we want it to create the accounts for us and enforce certain aspects of what it means to be a service account and ultimately remove the accounts when the application is no longer active
• Custom attribute flows in ILM 2007 to derive and assign the SPN's as well as flip the bits necessary for delegation

In the diagram above we can see the Admin view of an AzMan application definition. Most importantly are the three categories under the "Definitions" tree.

Role Definitions typically allow you to define a specific role in an applications like "submit" or "approve". If I have this role in the application then there are associated Tasks and Operations that I am allowed to do. We're going to leverage this relationship for our SPN's and use the Role Definition to specify the name of the service account we're modeling. Each service account is going to have at least two SPN's and a Service Class to model.

Task Definitions are specific sub-categories of a role, so a member of the "approve" role may need access to a task to escalate to a manager if a given limit is exceeded. But we're going to use this Task Definition to model our Kerberos Service Classes. For instance, the SPN "HTTP/ida.domain.com" specifies the HTTP service class is being used. There are others, but probably the two most common amongst web applications are HTTP and MSSSQLSVC.

Operation Definitions are the smallest component of the definition and are the atomic bits that define a particular task. The flexibility is here, whether it is used or not, to be extremely granular about everything an app can do, so you could say that the "escalate" task is composed of various "read page", "query manager", "submit email" operations that may also be shared by other Tasks and Roles. For our purposed we're going to use the Operation Definition to model our host and port components of the SPN. Because we're restricted from putting in any special characters here we're using a space to delimit the host from the port designation. Leaving the port blank would be a default "port 80" configuration. I should not here the Operation Number field and head off any questions about why we're not using this field as the port designator. This field is used to distinguish each task numerically and therefore uniquely within the developers code. If we have multiple port 80 SPN's (which we will) to craft then we'd be out of luck - we just need to make sure we don't step on any numbers already in use so you may want to start with a high number.

Since our Tasks can hold operations we create the relationship between our service class and our hosts by adding the Operations to the Task and the Task to the Role.  In the figure above we see that the HTTP class has several SPN's associated with it. You can imagine a similar construct for the MSSQLSVC class and its associated Operations.

Delegation

In our solution we need to accomplish the following:

 

Now with normal delegation we need to flip the TRUSTED_FOR_DELEGATION bit (0x80000 or 524288) on for the (in this case) web service account only. In most solutions you will not need to delegate the SQL Service account. We're going to do this in the ILM custom attribute flow. If we wanted to do Constrained Delegation then we'd need a much more complex relationship than we can provide here but more on that later. Constrained Delegation looks like so:

Trying to create the relationship between the MSSQLSVC SPN's and the web service account would get far too messy with AzMan alone so we're not covering it in this solution. In a future solution we may look at leveraging SharePoint or SQL to extend this if there is interest.

In the next installment we'll walk through setting up the definitions and demonstrate the ILM solution and rules extensions. If you're an ILM wizard then probably have enough clues to piece the remainder together but we'll walk through it and provide some sample code and MA exports just in case.