Skip to content

AD FS in Server 2012 R2

TechEd 2013 is happening right now and they are talking about upcoming exciting  features in the upcoming Windows Server 2012 R2.

There are many new features will be introduced in the next Server release. I’m still trying to digest all the new functionality. You can take a look at already delivered presentation about Access and Information Protection, check is out here:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WCA-B207

13 Shades of Claims Based Authentication

With this post I’m going to kick off a series of posts that will cover different topologies in which claims based authentication can be used. We are all familiar with the classic model where the client accesses the application and get redirected to the STS for obtaining the security token. The simplest configuration would have this STS to act both as Resource Provider STS and Identity Provider STS. The next is classic configuration with federation with trusted Identity provider organization. There are many more options on how it all can be configured, all really depends on the specific customer requirements. So I want to try and explorer multiple topologies and record a short demonstration for each of them so you can see what is possible and potentially how it can be done.

Here is what I have currently in mind:

  1. Client – Application – RP – IDP
  2. Client – Application – RP – RP – IDP
  3. Client – Application – RP – RP – RP – IDP
  4. Introduce Proxy components in the above topologies
  5. Introduce multiple IDPs in the above topologies
  6. Introduce different authentication mechanisms in the above topologies (Integrated, FBA, Certificate, PhoneFactor)
  7. Introduce mechanisms to provide automated HRD discovery
  8. Introduce IDP initiated sign on
  9. Introduce UAG as reverse proxy in the middle
  10. Introduce Azure Active Directory as IDP
  11. Introduce Azure ACS as middle tier to get authentication via Social identities (Microsoft, Facebook, Yahoo, Google)

As I work on these scenarios I might drop some of them and I might decide to explorer some other topologies that I have not thought about yet. If you have ideas of what would be interesting to explore then let me know and I might try to get it on my agenda.

Microsoft Forefront UAG Mobile Configuration Starter

Once in a while I get a request from the Packt Publishing to review one of their new publications. Recently they published a new book Microsoft Forefront UAG Mobile Configuration Starter and asked me to take a look  and see what I think. The title of the book has one important word – Starter, and I think that this  book is a great starter for anyone who is not very familiar with UAG and wishes to use it as application publishing solution to clients with mobile devices. The book  provides detailed steps by step instructions on how to configure UAG to publish SharePoint site and Exchange ActiveSync to mobile user population and provide some basic steps on configuration of Windows Phone 7.5 to access SharePoint and use built in Office apps.  Probably the most interesting parts of the book are closer to the end when it starts to cover common application publishing scenarios, security and customization, but since this is a Configuration Starter, it only covers these areas at very high level and the majority of the book is devoted to the step by step instructions with a lot of screen shots, which are very useful if you are not familiar with the product.  

So overall, if you have a requirement to publish applications to mobile devices and would like to use Microsoft UAG 2010 as reverse publishing solution then you will find this book very useful with initial implementation and evaluation of the product and it has a good number of references to other resources to get additional and more advanced information.

UAG SP3

In case you have not seen this, Microsoft released SP3 for UAG 2010. Check out what’s new and download it here.

You have to install SP2 before installing SP3, these service packs are no cumulative.

Mitigating Pass-the-Hash

If you are in the business of securing IT environments then make sure to read the following blog post and referenced white paper.

http://blogs.technet.com/b/security/archive/2012/12/11/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Chaining Multiple STS

A few month ago I learned something about claims based authentication that I thought was not possible.

Ever since starting working on federation solutions, and learning about it via training courses, reading white papers, specifications and presentations the following two topologies were always shown or discussed. The first one is where company has its own STS and their applications configured with this STS. The second solution extends on the first one by federation between two STSs, where one STS is acting as RP and the second is acting as IdP. I have never seen any specs or designs that would show more than two STSs in a chain, ie something like this RP-RP-IdP. So for some time I was assuming that protocols that make it all happen (WS-Fed, SAML etc) are designed to work in specific model RP-IdP and would not go beyond this one-one relationship. While this works for majority of the real world situations, in some cases it does not satisfy the complex requirements where chaining of the multiple STSs is required. Well, I thought that it was not possible till a few month ago. I had to design complex federation architecture and this perceived limitation was giving me a lot of headache. So, obviously I did some research and talked to a few people who also specializes in federation solutions and to my great surprise I learned that there is no limitation with protocols and that it is just fine to setup multiple STSs in a chain of trusts. I wish that I learned it prior from someone else’s design or spec paper, clearly stating that it is fine to do this and it will work. Needless to say, we were able to configure our architecture and satisfy customer requirements without additional overhead and keep it very streamlined.

A few days ago I was rebuilding my lab and decided to configure it to illustrate chaining of multiple STSs and show it here. So if anyone else didn’t decipher it in spec papers or other design, and is thinking that chaining is not possible, that it is in fact possible and works just fine. You can use it in your designs if it is a requirement.

In my lab I configured the following to illustrate this configuration:

  • IdP STS (DC, AD FS 2.0), it has the following FS URL: fs1.contoso.com
  • RP STS (AD FS 2.0), this is a middle STS, with FS URL: fs2.contoso.com
  • RP STS (AD FS 2.0), this is the STS with target relying party application. FS URL: fs1.external.com
  • Relying Party (Sample WIF SDK app). This is a workgroup server configured with fs1.external.com as its STS. Application URL https://myclaims.external.com/myclaims
  • Workstation that will access the application. I have HTTPWatch installed on this PC to show all traffic passive request traffic between the browser and the target systems.

Figure 1 shows my lab configuration:

Figure 1

Figure 1: Chaining multiple STS

Figure 2 shows the HTTPWatch traffic captured on the client PC. As you can see in steps 1 to 10, the browser steps through all parties in the authentication process and authenticates me into the application. It is fairly self explanatory, but if you have questions then let me know if you need any explanation on what happens here.

image

Figure 2: HTTPWatch capture of the Passive Request traffic with multiple chained STS (click on it to see it large)

Finally, you might ask why would anyone need to chain STS in such way. To answer it I’ll have to write another blog post. So stay tuned, I might do that in the next month or so.

Thanks, Dmitrii

Authentication Assurance and Claims Based Authentication

Authentication Mechanism Assurance is described in the following Microsoft publication: http://technet.microsoft.com/en-us/library/dd378897(v=WS.10).aspx.

In this post I want to dig a bit more into different configuration options, show how it works and provide example of how it can be configured with AD FS 2.

Authentication Mechanism Assurance is a new feature in Windows 2008 R2 AD DS configured at 2008 R2 Functional level, it provides an ability to assure that user is authenticated with specific type of certificate. Usually it is used to assure that user is authenticated with a specific type of smart card into AD DS. This assurance can then be passed on to applications which will make authorization decision on what user can or cannot do in it. It is very important feature in environments where specific regulations require to provide assurance of Smart Card authentication.

AD DS configured to use Authentication Mechanism Assurance is capable to identify users who used specific type of Smart Cards for authentication and dynamically populate their Kerberos tickets with security group associated with those specific Smart Cards. The linkage between Smart Card and AD DS is done via the OID populated in Certificate Policy certificate extension. Let’s take a quick look at how it works. The following diagram shows a basic flow of authentication to claims based application which can take advantage of the authentication assurance claim. In our example Contoso has Smart Cards with X.X.XX.XXX.X.X.X.X OID populated in Certificate Policy certificate extension. AD DS is configured to link X.X.XX.XXX.X.X.X.X OID with “Smart Card X Authenticated” security group.

In step 1, user authenticates to their desktop by providing Smart Card and PIN number. During authentication process AD DS detects that user authenticates with Smart Card (it is done by finding X.X.XX.XXX.X.X.X.X OID in the user certs) and builds Kerberos ticket. AD DS will include “Smart Card X Authenticated” security group SID in the Kerberos ticket.

In step 2, user tries to access claims based application which will redirect the browser to its trusted STS.

In step 3 and 4 user will be authenticated to the STS. STS will examine user group membership and because user’s Kerberos ticket contains “Smart Card X Authenticated” SID it will issue special claim type indicating that user was authenticated to AD DS with their Smart Card.

This token will be passed to the application. In step 5, application will have a choice to provide different logic for users who authenticated to AD DS with a Smart Card or without. Simple enough.

 AuthNMechanismAssurance

Let’s take a look how it all can be configured. I’m not going to repeat some of the steps described in the before mentioned Microsoft publication. I’ll refer to it when necessary.

The first step in configuring Authentication Mechanism Assurance is to create proper Issuance Policy in AD DS. The OID in AD DS Issuance Policy must match the OID in Certificate Policy on the Authentication certificate on the Smart Card. It will look something like this on the certificate:

[1]Certificate Policy:

Policy Identifier=X.XX.XXX.X.XXX.X.X.X.X.XX

More likely your AD DS will not have this OID and you’ll need to create one. Fortunately it is easy to do:

  1. Open Certificate Template management console.
  2. Open any v2 certificate template.
  3. Click on Extensions Tab, Click on “Issuance Policies” and then click Edit.
  4. Click on Add, then click on New.
  5. In the Name field type: Smart Card AuthN Cert
  6. In the object identifier field type: X.XX.XXX.X.XXX.X.X.X.X.XX (where XXX – is the OID from the cert on Smart Card)
  7. Click OK
  8. Do not save changes to the certificate template. Exit Certificate Management Console.

At this point you are ready to link appropriate security group to the Certificate Issuance policy. Create get-IssuancePolicy.ps1 and set-IssuancePolicyToGroupLink.ps1 files as described in Microsoft article. Run the first one to see if there are policies already in place. Run the second to make the linkage.

To display run this: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

To create new policy: .\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName “Smart Card AuthN Cert” –groupOU “Auth Mech Assurance” –groupName “Smart Card Authenticated”

To see new policy: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

So far, so good. We configured Authentication Mechanism Assurance. To verify that it actually working logon to AD DS with Smart Card, open command prompt and type whoami /groups. It will list all the groups that you belong, one of them will be Smart Card Authenticated. Logon with UserID/pwd and you’ll not be member of that group.

The next step is really making some use out of this information. Applications must be designed to take advantage of this information and make authorization decisions based on level of assurance we provide to it. Perfect candidates for it are claims based applications. We can generate a claim type, for example lets name it “LOA”, which stands for Level of Assurance, and assign different value to it. If user used userID/pwd, we assign 2 to LOA, if user used Smart Card then LOA will have 3. Application will decide what to do base on those values in LOA claim type.

Next, we are going to create LOA claim type in AD FS 2 and pass it to the application. I’ll discuss it in the next post.

Thanks for stopping by.

Authentication Assurance and Claims Based Authentication

Authentication Mechanism Assurance is described in the following Microsoft publication: http://technet.microsoft.com/en-us/library/dd378897(v=WS.10).aspx.

In this post I want to dig a bit more into different configuration options, show how it works and provide example of how it can be configured with AD FS 2.

Authentication Mechanism Assurance is a new feature in Windows 2008 R2 AD DS configured at 2008 R2 Functional level, it provides an ability to assure that user is authenticated with specific type of certificate. Usually it is used to assure that user is authenticated with a specific type of smart card into AD DS. This assurance can then be passed on to applications which will make authorization decision on what user can or cannot do in it. It is very important feature in environments where specific regulations require to provide assurance of Smart Card authentication.

AD DS configured to use Authentication Mechanism Assurance is capable to identify users who used specific type of Smart Cards for authentication and dynamically populate their Kerberos tickets with security group associated with those specific Smart Cards. The linkage between Smart Card and AD DS is done via the OID populated in Certificate Policy certificate extension. Let’s take a quick look at how it works. The following diagram shows a basic flow of authentication to claims based application which can take advantage of the authentication assurance claim. In our example Contoso has Smart Cards with X.X.XX.XXX.X.X.X.X OID populated in Certificate Policy certificate extension. AD DS is configured to link X.X.XX.XXX.X.X.X.X OID with “Smart Card X Authenticated” security group.

In step 1, user authenticates to their desktop by providing Smart Card and PIN number. During authentication process AD DS detects that user authenticates with Smart Card (it is done by finding X.X.XX.XXX.X.X.X.X OID in the user certs) and builds Kerberos ticket. AD DS will include “Smart Card X Authenticated” security group SID in the Kerberos ticket.

In step 2, user tries to access claims based application which will redirect the browser to its trusted STS.

In step 3 and 4 user will be authenticated to the STS. STS will examine user group membership and because user’s Kerberos ticket contains “Smart Card X Authenticated” SID it will issue special claim type indicating that user was authenticated to AD DS with their Smart Card.

This token will be passed to the application. In step 5, application will have a choice to provide different logic for users who authenticated to AD DS with a Smart Card or without. Simple enough.

Let’s take a look how it all can be configured. I’m not going to repeat some of the steps described in the before mentioned Microsoft publication. I’ll refer to it when necessary.

The first step in configuring Authentication Mechanism Assurance is to create proper Issuance Policy in AD DS. The OID in AD DS Issuance Policy must match the OID in Certificate Policy on the Authentication certificate on the Smart Card. It will look something like this on the certificate:

[1]Certificate Policy:

Policy Identifier=X.XX.XXX.X.XXX.X.X.X.X.XX

More likely your AD DS will not have this OID and you’ll need to create one. Fortunately it is easy to do:

  1. Open Certificate Template management console.
  2. Open any v2 certificate template.
  3. Click on Extensions Tab, Click on “Issuance Policies” and then click Edit.
  4. Click on Add, then click on New.
  5. In the Name field type: Smart Card AuthN Cert
  6. In the object identifier field type: X.XX.XXX.X.XXX.X.X.X.X.XX (where XXX – is the OID from the cert on Smart Card)
  7. Click OK
  8. Do not save changes to the certificate template. Exit Certificate Management Console.

At this point you are ready to link appropriate security group to the Certificate Issuance policy. Create get-IssuancePolicy.ps1 and set-IssuancePolicyToGroupLink.ps1 files as described in Microsoft article. Run the first one to see if there are policies already in place. Run the second to make the linkage.

To display run this: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

To create new policy: .\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName “Smart Card AuthN Cert” –groupOU “Auth Mech Assurance” –groupName “Smart Card Authenticated”

To see new policy: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

So far, so good. We configured Authentication Mechanism Assurance. To verify that it actually working logon to AD DS with Smart Card, open command prompt and type whoami /groups. It will list all the groups that you belong, one of them will be Smart Card Authenticated. Logon with UserID/pwd and you’ll not be member of that group.

The next step is really making some use out of this information. Applications must be designed to take advantage of this information and make authorization decisions based on level of assurance we provide to it. Perfect candidates for it are claims based applications. We can generate a claim type, for example lets name it “LOA”, which stands for Level of Assurance, and assign different value to it. If user used userID/pwd, we assign 2 to LOA, if user used Smart Card then LOA will have 3. Application will decide what to do base on those values in LOA claim type.

Next, we are going to create LOA claim type in AD FS 2 and pass it to the application. I’ll discuss it in the next post.

New UAG Book – Mastering Microsoft Forefront UAG 2010 Customization

My last few posts were dedicated to customization of the look and feel of the UAG 2010 Logon/Logoff and Portal experience. I had to figure out a lot of it on my own without any type of documentation. Well, there is a good news, PACKT Publishing just released a new book on how to customize UAG implementation. It is written by the same folks who wrote a must have book on UAG Administration, and published from the same publisher. If you are doing any work with UAG 2010 then both of these books should be in your library!

I just had a chance to read through the new book. It covers a lot of different topics and shows how to customize UAG installation, and at the same time keep it in supported condition.

You can check it out at the publisher web site http://www.packtpub.com/mastering-microsoft-forefront-uag-2010-customization/book