Windows Server 2003 R2, which was released December 2005, is an update that doesn’t add much in the way of new features directly of interest to Terminal Services and Citrix (see https://www.brianmadden.com/content/content.asp?id=537), but that doesn’t mean we can completely ignore it.
One of the interesting updates we should be aware of is contained in R2 is identified as “Improved Identity and Access Management”. General information on what is new in R2 is available from Microsoft at http://www.microsoft.com/windowsserver2003/r2/whatsnewinr2.mspx .
In essence, the improvements to Identity and Access Management mean an update to Active Directory. I attended a presentation last fall at Microsoft’s PDC that discussed this in more detail and recently re-stumbled upon it. Some customers will hear about this and will be quite excited about it. VARS, Integrators, and Consultants need to be educated about it, at least enough to react positively or negatively. For most of us we will react to this information at one end of the spectrum or the other--with either love or dread. This article is about why you might care. If you do care, you will need to get R2 and work with it so as to answer your customer’s questions.
Part of the update to Active Directory is what Microsoft calls “Active Directory Federated Systems” (ADFS). ADFS allows us to define intra-domain trust policies on a more granular basis than today. A trust today is pretty much an "all or nothing" arrangement--you can either trust a different domain authority to manage the user identity or you can not trust them. Perhaps this is best explained with an example:
Let’s say we have two organizations, each with separate Active Directory (AD) domains. I will call the organizations A and B (with matching domain names). Using “traditional” AD, users in Domain B are completely unknown in Domain A unless a trust (at minimum a one-way trust from B to A) is established between the two trusts. If a trust is established then when a B user presents B credentials to A, the identity is accepted including all group memberships and the like.
If organization A and B are separate companies, this level of trust is not normally acceptable. If organization B is a sub-contractor of A and needs logon access to resources inside A (often via terminal services or Citrix) this means that B users must also have an identity defined and maintained in Domain A. This makes the administrator at organization A responsible for setting up user accounts and other maintenance chores like resetting passwords. B users must log into the B domain using B credentials, and then into the A domain using A credentials. I do this all the time as part of contracts with ISVs and it is a royal pain. All too often we lose valuable time on a project (and lots of aggravation on both sides) due to basic user maintenance and password lockout issues that arise.
With ADFS, you can establish a more limited trust. In this example you might trust the identity verification to B, but leave policy decisions to A. The trust relationship for A and B might be that A will accept login credentials from B users that are part of the A_Worker group. Once the trust is established, the admin at organization A no longer needs to establish accounts or reset passwords. Users at organization B can log in once using their B credentials. With single sign-on or pass-through enabled their credentials will follow then to A when they log in there.
Another example comes from the Web world. Here a vendor might have a portal for all their VARS to use. Rather than maintain individual accounts for each user, they could establish ADFS trusts with each VAR. Vars would enter the portal using their local credentials. Now let’s say the vendor has a three tier system of Gold, Silver, and Bronze VARs. ADFS also allows the vendor to modify the user claims on the fly--looking up the current level of the VAR (possibly based on the most recent year or quarter) and granting access based on the modification of claims made by this entry script.
ADFS is also part of a broader Federated Identity effort and has applications in working with non Microsoft authority domains using a protocol called SAML. Military and University examples were sited at a recent Microsoft panel discussion at Microsoft’s PDC.
If ADFS is something you need to know more about, additional information is available from the following links:
Mapping Requirements to the Design http://technet2.microsoft.com/WindowsServer/en/Library/09c69199-9ac2-432e-866e-d95dd944e6711033.mspx
Federated Identity Management Interoperability Workshop http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsfedinterop.asp