August 2011 - Posts

Add Facebook as an Identity Provider for your Claims Aware .net Application
22 August 11 12:34 PM | forefrontsecurity | with no comments

Hi All,

Hicham has already told about “How to authenticate to your network through your online credentials” :

Let’s talk today, how you can very easily authenticate on your .Net Claims Aware Application with your Facebook Account.

First you have to create / initialize your Windows Azure AppFabric Service Bus, and ACS. I don’t want to go deeper in that subject, I am not very relevant with those technologies. But I can use them. For more informations (in french), here is a great Techdays 2011 session by Arnaud Cleret and Guillaume Belmas about “The integration of Windows Azure in my Information System” :

Ok, and now :

Go to Facebook, and create a new Application. For this topic, I have created the “ Claims Identity Provider”


Configure this application to be a Web Site that can be used to authenticate users. Specify that the relying party is your ACS Service Namespace URL :


When all is done, configure your ACS to add Facebook as an identity Provider and provide the APP ID, and APP Secret. Save, and that’s it


During the first logon to the application, choose your Azure Access Control, and the Facebook Identity Provider


You will be redirected on the Facebook Login Page


And here you are. My application just show a list of available claims in the token. For the moment, there is only a Name, but I can now search in my Active Directory to find user’s roles.


As you can see, it’s pretty easy to give an access to your On Premise application to Facebook Users. Why doing that ? Sometimes, delegating authentication to another provider is useful : No needs to host a username / Password database or Directory, no needs to manage password policy and other benefits that those new Cloud Scenarios provides.

In a next article, I will go deeper in security with AD FS, because opening your Infrastructure to Facebook is great, but in other words, you are opening your application to millions of strangers !

Published by Olivier DETILLEUX

Implementing Office 365 in a multi-forest context
21 August 11 07:06 PM | forefrontsecurity | with no comments

Single Sign-On (SSO) is one of the new features brought by Office 365. This relies on the following Microsoft technologies:

  • The Directory Synchronization tool (DirSync) based on Identity Lifecycle Manager (ILM) 2007 to sync your on-premises directory with Office 365.
  • Active Directory Federation Services (AD FS) 2.0 to provide authentication between your environment and Office 365.

If the benefits are important, one main limitation still exists: you cannot synchronize multiple forests. To address this scenario, Microsoft recommends to consolidate your forests or to use your primary logon forest only. This requires a deep Active Directory cleanup prior to beginning your Office 365 deployment.

To overcome this issue, I worked with Julien Peigné – Unified Communications Consultant at vNext – to develop a unique approach to sync and federate your forests with Office 365. Here is how it works in 3 main steps:

  • Consolidation: A new, dedicated forest is created to provide a clean and consolidated directory. This directory will be synced with Office 365 using DirSync.
  • Synchronization: User accounts are synced between the existing forests and the new resource forest using Forefront Identity Manager (FIM) 2010.
  • Federation: AD FS 2.0 is setup and configured in each forest to provide a transparent authentication between your environment and Office 365.

The following figure summarizes the solution:


This provides some interesting benefits:

  • All types of directories: using FIM 2010, we can provide Office 365 accounts to all your users no matter their directory (Active Directory, LDAP, SQL…).
  • Step-by-step migration: using FIM 2010, we can filter and gradually fund accounts from your existing forests to the new resource one.
  • Deployment accelerator: there is no need to cleanup your existing directories. Malformed, inactive or disabled accounts can simply be ignored with FIM 2010.
  • No impact: No change is required on your existing directories. We only sync the attributes that DirSync needs using FIM 2010.

Feel free to contact us for more information about this solution. Please also note that this has not been tested by the Office 365 team and is consequently not supported by Microsoft. However, we tested it and validated it in our test labs at vNext.

Published by Olivier DETILLEUX

A new blog about Unified Communications :
18 August 11 10:24 AM | forefrontsecurity | with no comments

Hi All,

Just a quick post to present the blog of Julien Peigné, a colleague at vNext. Julien is an Unified Communications Consultant. He has just open a new blog about Unified Communications :


This blog aims at analyzing and understanding Microsoft products and strategies to improve your business and personal communications. The specificity of this site is to provide an abstract high level approach. Hence you won’t find any tutorials here but thoughts and discussions on unified communications and their concrete implementation.

I will mainly focus on the following products and services:

  • Exchange Online, Lync Online and more globally Office 365
  • Exchange Server and Lync Server
  • Office
  • Windows Phone
  • Windows Live

… and more! Stay tuned.

Published By Olivier DETILLEUX

Provide access to your Partner on your UAG Portal with ADFS 2.0
16 August 11 09:58 AM | forefrontsecurity | with no comments


As Hicham already demonstrate, you can add Claims Provider Trust on your Federation Server. His example is a Federation with Azure services, but you can do the same with a Federation Partner. Have a look at this article :

Let’s assume that the Labiam Corporation wants to allow access on his UAG Portal to the company. Both have a Federation Service.


As you can see on the above schema, we have to create a Claims Provider Trust on the LABIAM Federation Server, and add this Federation Server as a Trusted relying Party on the Federation Server.


With the FederationMetadata URL, it is easy to add this provider


Add the necessary claims to the Provider (Windows Account Name, Role …)

On the other side, create the Relying Party Trust, and accept the required claims.


Now, when a user access the UAG Portal, he can choose his repository, and your Partner can access your publications. 


Then you can filter the access to specific application, using the Role Type of Claims (developed in a previous article :

AD FS is a very great feature. No matter Network considerations, Active Directory Trust Relationships, just use HTTP(s) Exchange to Federate your Business Partners.

Published by Olivier DETILLEUX

AD FS 2.0 and UAG : Set authorization on application in UAG based on Claims Roles
16 August 11 09:12 AM | forefrontsecurity | with no comments

Hi all,

AD FS 2.0 provide transparent authentication on the UAG Portal. Hicham and I have already deal with this great feature. Today, I will show how we can set authorization, based on claims, on the application published through UAG.

With the regular Form Based Authentication against an Active Directory, it is easy to set authorization for an application :


But with an ADFS authentication, how can we query Active Directory groups ? We have to enrich (add additional claims value) the SAML2 ticket with this information.

To achieve that, it is pretty simple.

Let’s assume that only the GGS_Director group can access the web application “Application”, and that James Kirk, as the Enterprise Director, is a member of this Active Directory group :


To add claims value in a SAML ticket, we must ask the Claims Provider to search the value in Active Directory, and send this value to the Relying Party.

On the Claims Provider (Active Directory), add a claims as a Role. In our case : If the user is a member of the GGS_Director group, then a GGS_Director as Role :


For the relying party, just pass through this value


On the UAG Side, specify that only Owner of the GGS_Director Role can access the application.


Now, when James open the portal, he can see the application, as Janice Rand cannot.

Easy, isn’t it ?

But you can say that it is not very convenient, if we must define a rule for each group.

You can also create a custom rule that query the Active Directory to return all groups that a user is directly member of.

Published by Olivier DETILLEUX

Authenticating to your network through your online Credentials
05 August 11 03:54 PM | forefrontsecurity | with no comments

Now off to another subject: ADFS!

Active Directory Federation service v2.0 is the newest trend. Using your Live ID or Google ID to Log into your domain, and access your domain resources is a great new topic that very exciting to work with.


In this example I will show you how to use your Live ID to logon to your UAG server and then access your resources and application that way. I’ll add to that a small ADFS custom Store so that you can see the possibilities lying behind all of that.

What you need to do that:

· UAG 2010 SP1

· ADFS 2.0

· Domain Controller

· Windows Azure Account


Here is a small architecture design of what you could have:


Let me explain what going on here:

A user wants to access his corporate application; he goes to his UAG portal URL. UAG was configured with ADFS as an authentication method and redirects all users to the ADFS home page which asks the users about what authentication method they want to use.

The user chooses Live ID and authentication to the UAG portal through his Hotmail or MSN account.

Once on the portal he needs to access his resource, some technical stuff go on, ADFS turns the LiveID into something your domain might understand and UAG will map this info to a shadow account and through KCD will log you into your application ! Cool ain’t it?

Now let’s see how to do that:

First you need to have an ADFS server configured

This is how I configured mine but you could have anything here


Next is to configure the ADFS trust with UAG as per my previous article:

This first step will get you to the first milestone where you can logon to your UAG with ADFS.

However until now ADFS was configured to get your SAML ticket info from Active Directory only.

Let’s set up the link with other services such as Microsoft’s Live ID authentication.

In ADFS it’s basically a new Claim provider trust that you’re adding:


You then need to tell your claim rule to transmit the information that it gets from the claim provider as let’s say an account name.

Technically this means that the SAML ticket will have the Live ID or Google ID you logon in as an account name attribute.


Now that the link is set between your UAG ADFS and Azure you need to tell the relaying party trust you created between your UAG and your ADFS server to transmit to UAG the information it got form the provider to the relying party (in that case it’s UAG).

That can be done by editing the relying party claim rule and telling it to transmit to UAG an account name, or in that case create a custom rule like I did :

In my ADFS console I had added an SQL Database to which I added each user’s Live ID and mapped it to an Active Directory account (or group).this can of course be any data storage system (Active Directory, Oracle DB).


What we’ll do here is access the relaying party trust we created between ADFS and UAG and write down a custom rule that will give us the AD account to which the live ID is mapped!

Check it out:

Edit your claim rule and create a new Custom claims rule:


This rule will look like that:

c:[Type == ""] => issue(store = "SQL Attribute Store", types = (""), query = "SELECT Role FROM URT WHERE UserName={0}", param = c.Value);

This rule will access the SQL DB store you created and get the role from the table where username = you live ID account.

When you access your UAG portal you will be given the choice to logon with your usual Active Directory ADFS SAML ticket or with your windows Azure à live ID account!

Here is what it looks like (note that this page is completely customizable)

You first get a choice between your usual active directory Provider and now you have a new one: AZURE!


And once you select azure:


Once you enter your Live ID credentials ADFS will process the information and send it to the UAG portal and you will be logged in as anything you set in your rule J in my case the group it retrieved from my sql database !

However this account will allow you to access the portal only and unless your application is claims aware, you will need to map this account to an active directory shadow account to be able to access non claims aware applications.

And now let’s configure your application to turn your SAML information intro a Kerberos Ticket:

Access the application you to give access to and go the authentication TAB:


Choose the KCD option and choose the claim type value to turn into a Kerberos ticket: I chose the name since this is where my info is stored in my SAML ticket.

The last part is to enable KCD on the application:

UAG will create an LDIF file for you through this menu


Apply this file to your UAG computer domain and you will have enabled KCD.

And now you can access you application by using your windows Live ID account !

Very cool!


Published by Hicham Bardawil

This Blog


    We talk about Forefront Unified Access Gateway, Web SSO, DirectAccess, Threat Management Gateway, Identity Manager and other Forefront Technologies. Also, some post about Active Directory and other Identity and Access technos.