Azure and Microsoft cloud developments announced at TechEd 2013

Here’s a round-up of various new developments announced at TechEd 2013:

-Azure Active Authentication is being launched. This is the PhoneFactor acquisition re-branded and deployed as part of the Azure Active Directory ecosystem. See for something about that. I believe you can deploy this today via the Azure Service portal (with some kind of subscription required), and Office 365 plans to roll it out in the next 3 months. O365 will require it for all “admin” accounts with a free license for them, and they are still working out the licensing details for other O365 users. I haven’t yet heard any plans to allow this service to be integrated with on-premise solutions, but it was a question at one of the sessions and the speaker noted they were thinking about that.

-Azure Authentication Library is being launched. This is a new library that allows you to easily integrate your on-premise or cloud based web application with Azure Active Directory. See for something about that. Note support for OAuth2.

-BYOD enhancements for AD-DS and Azure Active Directory (AAD). Later this year, AAD and WS2012R2 will provide a way for you to “workplace join” personally owned devices from iOS to Android based. On premise, a new component in ADFS facilitates this and issues a long-lived certificate to the device which provides a SSO like experience to the device user. There is good support for deprovisioning the device, with additional selective wipe capabilities dependent on various other Microsoft product integrations. One of those integration points is Microsoft InTune in concert with SCCM. InTune is a cloud-based device management service. We own InTune licenses, but don’t yet have any service leveraging it …

-Along with the BYOD enhancement, Microsoft is enabling per SP multifactor support in ADFS. 3rd party providers can leverage a new multi-factor authentication (MFA) provider capability in ADFS to integrate their authentication methods. As an example of this, SafeNet has been working with Microsoft to provide one of these MFA providers using their hardware/software OTP, SMS, and GrIDSure options as a strong authentication as a service via a cloud based service. Whether cloud-based multi-factor services emerge might be something interesting to keep an eye on.

-I expect most folks saw that Microsoft slashed Azure VM rates 8 days ago to match Amazon EC2 rates, as well as announcing they won’t charge for stopped VMs, and moving to a per-minute charge model. Microsoft had several sessions promoting using Azure VMs for pre-prod/product evaluation/development purposes because you don’t sink costs into a physical on-premise box–and you only pay for the actual time you need the VM.

-Microsoft revealed a strategy to provide a consistent management interface for private cloud and Azure based services. For those that missed it, back in January Microsoft released the Azure Services for Windows  Server, so you can deploy private cloud capabilities on-premise just like Microsoft’s. Last week, this release was renamed the “Azure pack” and a number of enhancements were revealed that will come with Windows Server 2012 R2 planned for release this year. Among the various announcements are System Center capabilities that make it very easy to migrate VMs between on-premise HyperV and Azure, and enhancements to the HyperV Replica features that include using Azure as a HA failover for your on-premise HyperV VMs.

Lots more, but my memory is running dry. 😉

I expect that we’ll learn more details about these new capabilities in a couple weeks when Microsoft holds its annual conference for developers and the Windows 8.1, Windows Server 2012 R2, and System Center preview bits are likely to be released.


ADFS 2.0 Shenanigans

As part of the Office 365 project, UW-IT is deploying ADFS. This will enable federated logon to Office 365 services, and as time allows it can be used in other scenarios to federate other applications on the Windows platform.
I’ve talked and read a lot about ADFS, and listened to perhaps a dozen presentations on it, but haven’t had time to look at
it myself until this project came along.

My initial experiences are well summarized by a statement on a Virginia Tech blog: “Along comes ADFS 2… new, more powerful,
better, more standards compliant … documentation reads like scrawl on a napkin.”

I ran into a lot of “gotchas” most of which are noted on various websites, but very little of which is well-addressed by the Micrsoft documentation or tools. I don’t blog much about problems I run into, but this set of gotchas calls out for a blog post. 🙂

Gotcha #1:
Don’t use the WS2008 Roles feature to install ADFS. You’d think you’d just install the ADFS role via Server Manager, right?


If you do this, you end up with ADFS 1.0. Nothing in Server Manager indicates the version number. Nothing tips you off in the interface until you read documentation somewhere which tells you you have to download the ADFS 2.0 installer and this is the only way to get 2.0 installed.

Gotcha #2:
If you install ADFS 1.0, you can’t install 2.0 without removing 1.0 first. No upgrade. Is this Microsoft software? OK, I can deal with this.

Gotcha #3:
If you use the ADFS GUI installer, you can’t use SQL Standard (or enterprise/datacenter). The UI at least gives you a small

warning note about this. However, this part of the UI and the Microsoft documentation are also a source of the next gotcha.
Gotcha #4:
The MS documentation uses the term “Windows Internal Database (WID)” consistently for the “small” ADFS cluster deployment option. Nowhere does it refer to SQL Express. The ADFS installer UI never uses the WID term, and only refers to SQL Express. Until you realize that WID is a SQL Express based database, you are confused. Maybe this terminology mismatch only confused
me …

Gotcha #5:
The fact that the WID option doesn’t support SAML artifact functionality isn’t well documented or presented. If you choose WID you are sacrificing some functionality. That’s an important point and shouldn’t be hidden.

Gotcha #6:
If you don’t want to use SQL Express, then you have to use a command line utility called fsconfig.exe to generate the SQL database for ADFS. The Microsoft documentation on this is … sparse? Almost non-existent? And what there is doesn’t really highlight the best way to approach this. Run:

Fsconfig.exe GenerateSQLScripts /ServiceAccount [account] /ScriptDestinationFolder [destination folder]

which will generate 2 .sql scripts which will do the work required on the desired SQL server.

Gotcha #7:
The commonly recognized best practice for the token-signing certificate is to use a self-signed certificate. This is because self-signed certs automatically renew themselves, whereas replacing a CA signed cert can result in an ADFS outage or require you to notify all trust partners. But the installation UI doesn’t default to a self-signed cert for the token-signing cert. Good thing I’ve listened to so many ADFS presentations, and talked with folks who have been running ADFS for awhile.

Gotcha #8:
ADFS wants port 1501 for some of its communications. The TSM Client Scheduler service uses port 1501. This blocks installation of ADFS. You can get past this and still run TSM, but it requires stopping the TSM client during installation, then later changing the port that ADFS wants to use. See
to-change-the-net-tcp-ports-for-services-and-administration.aspx for how to change that port.

More gotchas? Maybe. I’ve only installed one ADFS server in our dogfood environment. I’m sure I’ll run into more shenanigans.

ADFS 2.0 Smorgasbord

Over the past several months I’ve seen 4 or 5 presentations on ADFS2. And of course, ADFS2 was released to the web on 5/5/2010. And as announced previously on this blog, we’re actively in a partnership with Microsoft around Shib interop with ADFS2.

So it’s time for all this material to get into a blog post. 🙂

First, see for the ADFS2 download.

Second, the terminology is important to understand, so here’s a decoder ring. I’ve put in bold the terms I think make the most sense to use.

Security Token Service (STS) = Identity Provider (IdP) = Issuer = the server that verifies identity, adds claims, and issues a SAML token.

Claims = Attributes = Assertions = information about the identity associated with the login token which the token issuer claims/asserts are true.

Relying Party (RP) = Service Provider (SP) = Consumer = a server which wants to consume a federation token, possibly using claims in that token for authorization decisions.

One really important concept to understand about the federation IdP/STS role server is that it is *all* about issuing a token in a standardized form, which in both the Shibboleth and ADFS (either version) cases is a SAML 1.1 token. It takes some form of authentication credentials and “transforms” those provided credentials into a SAML token which you can use in a standardized way. So if you are a Math or Coding geek (as I am) you might think of the federation IdP/STS server as a function that transforms non-standard input into a standardized output. Or if you’ve travelled at all, you might think of the IdP/STS as the money exchange you have to visit each time you go from one country to another. You have currency–it’s just that no one accepts the currency you have, and so you need to get the currency that is accepted locally.

Another really important concept to understand is that the Consumer only knows about a single Issuer, or put another way: the Consumer only trusts a single Issuer. I talk about the federated access dance down below.

Third, you might be wondering a lot of various questions.

Why federate? Why not use Windows Integrated Authentication?
Common answers are:

  • you’ve got stuff to protect that isn’t Windows based
  • you need to give folks outside the UW access
  • you are porting your app to the cloud

Why use ADFS when we’ve already got Shibboleth?
The answer there is much more complex. As I’ve already said previously, ADFS2 has interop features with Shib, so stuff that uses an ADFS2 Security Token Service (STS)–which means the same thing as an IdP in Shibboleth-speak–can accept SAML 1.1 login tokens from a Shib IdP.

But there is more to federation than just issuing login tokens. You also need to accept federated login tokens, i.e. the role that Shib calls a Service Provider (SP) and ADFS calls a Relying Party (RP). And assuming you are accepting login tokens from elsewhere, you also need to perform token transformation or claims transformation. Claims transformation is the process of taking claims issued by another authority and tranforming them to mean something within your environment, typically for use in authorization or to populate a user’s details in an application.

Something like Sharepoint 2010 has built-in support for ADFS2, meaning that as a RP, it understands ADFS2 issued tokens and can leverage ADFS2 claims transformations. As I understand it, *only* using Shibboleth to federate Sharepoint 2010 means you’d need to write code for some custom claims transformations.

So the more appropriate question is can we leverage Shibboleth as the point of token issuance along with ADFS2 for the claims transformation? And the answer to that is yes. I’ve seen several demos of this working.

The trick then becomes figuring out whether you also want to be able to use ADFS2 for token issuance.

Why might you want to use ADFS2 for token issuance on top of Shibboleth?

Well, your Windows login token, i.e. the one you get when you interactively login to your computer via a Windows domain account, can be used to automatically get an ADFS2 login token without throwing yet another authentication prompt in the user’s face. With the advent of UWWI delegated OUs, you might believe that reducing the number of logins is desirable and attainable for some population. Whether there is enough demand there isn’t clear to me yet.

However, if it was something we wanted, then we’d next need to deploy a custom WAYF on the ADFS2 server.

What’s WAYF?

WAYF stands for Where Are You From? WAYF is the mechanism where the client chooses what Issuer they’d like to authenticate with. You’ve probably used the WAYF associated with InCommon to choose that you are from the UW and want to login against the UW Shibboleth IdP. In this case, we’d need to have a WAYF that gave 2 options:

  • UW Shibboleth (i.e. Weblogin)
  • UW ADFS (i.e. UWWI).

Moving on from high-level stuff, let’s talk more about details.

The federated access dance is something like this:
a) client goes to Consumer (a website)
b) Consumer asks client for a valid token
c) Client tell Consumer it doesn’t have a token
d) Consumer sends a 302 redirect to client to talk it its Issuer (Issuer A)
e) Consumer hits the WAYF at Issuer A
f) Consumer chooses something from WAYF and gets sent a 302 redirect to their Issuer (Issuer B)
g) Client hits Issuer B, provides credentials
h) Client is issued a SAML token by their Issuer (Issuer B), gets sent a post redirect to the original Issuer (Issuer A)
i) Client hits the original Issuer (Issuer A), which takes the SAML token from Issuer A, and transforms it, issuing a new SAML token and sending a post redirect to the Consumer. The transform may drop some claims and add some new claims, all based on business rules specific to the trust between Issuer A and Issuer B.
j) Client hits the Consumer and presents a valid token
k) Consumer evaluates claims in token, and decides what resources the client has access to. In some cases (e.g. Sharepoint 2010), it might have its own “internal” STS that is used across a farm of resources, and issue yet another token to the client (sending us back to step i).

ADFSv2 supports the following possible authentication sources:

  • Active Directory
  • a “chained” SAML 1.1 token, i.e. a token issued by another federation server

If you have a different authN source (say MIT KDC) or to accept some other kind of token, you no longer can use the “out of the box” ADFS product, but need to build your own STS using the Windows Identity Framework SDK. Many online examples show you how to do this in a step-by-step approach, but this is not for the faint of heart. This point is important to keep in mind, because sometimes when people say they are using ADFS for some interop scenario, they aren’t–they are using a custom STS that is really just a distant cousin of ADFS.

ADFSv2 supports the following possible directory sources for claims:

  • Active Directory
  • MS AD Lightweight Directory Services (LDS)
  • SQL
  • LDAP directory which uses Windows integrated

Federated Sharepoint

Can you do that!? Yes, and in fact, the University of Missouri has a working demo of this that I’ve seen (and in fact, I have 10GB of virtual images of that demo environment). In terms of the coming Sharepoint service offer, it isn’t immediately clear today whether we’ll be able to offer federated authentication at the time of the initial offer, but I do think it’s a feature we need to support.

There are two general use cases for using federated authentication with Sharepoint:

a) All your collaborators have a UW NetID, but for some reason their OS and browser can’t do Windows Integrated authentication (Kerberos, NTLMv2, or NTLMv1).
b) All your collaborators don’t have a UW NetID, but they have credentials elsewhere via either an ADFS or Shibboleth infrastructure.

Most of this blog post will focus on b), but let’s talk just a bit about a) first.

An overwhelming majority of browsers and operating systems do permit Windows Integrated authentication of some flavor, so there isn’t a large demand for this, however, it is an option for that small set of clients.

In this scenario, you’d permit pubcookie authentication via the UW’s Shibboleth IdP. IdP is the terminology for the server which issues the authentication token in this technology.

For either a) or b) you need to have a second web application which has another authentication provider than Windows Integrated. That other web application can point at the

same site content, but because of the security details underneath both federation technologies, you are required to have a different URL if you have access to any given site

via both Windows Integrated and a federated authentication provider. Some of this is noted here, in this ADFS and MOSS configuration link,

For either a) or b) there are side-effects/limitations/broken features. For example, the Office document library integration breaks. Which brings me to the second of many external links, Unsupported SharePoint features with ADFS, And yes, that list is relevant for both a) and b). So generally speaking, if

you can help it, you want to do Windows Integrated authentication. And while I’m back on that topic, I should also mention that those clients which can’t do Windows Integrated auth have another option which is do basic auth together with ssl.

Moving onto b), we’ll get a bit into the architecture, and then later on, I’ll talk about how there are actually two possible solutions for a) and b) (which makes talking about this

already complex topic much more complicated).

So … for a general overview of Shibboleth and ADFS, there are a number of good online resources:
Understanding Shibboleth,
ADFS Design Guide,

Doing the interoperability between ADFS and Shibboleth requires installing the Shibboleth extension for ADFS,, on your IdP, and on every IdP you’d like to accept authentication claims from.

This link has probably the best information available anywhere about the actual interoperability between ADFS and SHibboleth, Shibboleth and ADFS Interoperability


From a quick overview of the architecture components involved, let’s talk about an imaginary use case. Say you’ve got a collaborative group that includes folks from Stanford and the UW.

The Stanford folks would go to the Sharepoint site, and the ADFS Web Agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to a UW ADFS-R server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the ADFS Web Agent installed. That ADFS Web Agent takes those claims, and translates them to the Sharepoint security model.

Both of these links talk about this last step:

Now the description I’ve just shared is one of two possible solutions for b) (and to some extent a)). The other solution drops ADFS from the mix. That one goes like this:

The Stanford folks would go to the Sharepoint site, and the Shibboleth agent would redirect them to authenticate with their Shibboleth IdP (using their local webauth sso provider) and present that claim to our Shibboleth SP server. That server would take the claims, perform any translations specified in a trust agreement, and issue a new set of claims to present to the Sharepoint server which has the Windows Shibboleth agent on it. The Windows Shibboleth agent takes those claims, and pass them to a custom membership provider which translates them to the Sharepoint security model.

There is a vendor which has something that I think is (or is close to) the custom membership provider needed. You can read more about it at

I suspect the solution which includes ADFS is going to be preferable, but that’s still to be fully considered.