• <1 minute

Windows Azure now supports federation with Windows Server Active Directory

By Alex Simons, Active Directory Director PM, AD PM USA
Yesterday we shared that Windows Azure Active Directory (AD) has processed 200 BILLION authentications .  Today I’m excited to share some great identity-related improvements we’…

Yesterday we shared that Windows Azure Active Directory (AD) has processed 200 BILLION authentications .  Today I’m excited to share some great identity-related improvements we’ve made to Windows Azure that leverage the capabilities of Windows Azure AD. The number one identity management feature that Windows Azure customers request is the ability for organizations to use their on-premise corporate identities in Windows Server Active Directory to deliver single sign-on (SSO) access to the Windows Azure Management Portal and centralized user access management. 

Starting today, the Windows Azure Management portal is now integrated with Windows Azure AD and supports federation with a customers on-premise Windows Server AD. In addition this integration means that the millions of Office 365 customers can use the same tenants and identities they use for Office 365 to manage sign-on and access to Windows Azure.

There are many advantages to using federation with Windows Azure. For IT professionals, it means:

  • Subscription management for Windows Azure can now be tied to an employees’ status at your company.  If an employee leaves your company, their federated access to the Windows Azure Management Portal can be turned off by deactivating them or removing them from your on-premises Windows Server Active Directory.
  • Your corporate administrator can control credential policy for the Windows Azure Management portal through Windows Server Active Directory, including setting password policies, workstation restrictions, two factor authentication requirements and lock-out controls.
  • Users no longer have to remember a different set of credentials for Windows Azure. Instead by using SSO and Federation, the same set of credentials are used across their PC, your work network and Windows Azure, lowering the chance of employees forgetting their credentials and making central management and reset of passwords easier and lower cost.
  • User passwords never leave your on-premise Windows Server AD: Users login using your on-premise Windows Server AD Federation Server so their identities and credentials are mastered and validated on-premise. Their passwords are never moved to the cloud.
  • You can require multifactor authentication, such as a smartcard & pin or RSA SecureID in addition to standard username and password authentications.

For developers and operators who access the Management Portal, federation means:

  • When you log into your domain joined Windows PC you will be seamlessly authenticated with the Windows Azure Management Portal.
  • If you are logging in from a non-domain-joined machine, such as personal device at home, you can use the same corporate credentials you use on your work PC.
  • You will receive Windows Azure service notification emails via your corporate email address.

Overall, federation can be used to greatly increase the security of your company’s cloud assets and intellectual property.

Using your existing Organizational accounts to access Windows Azure
There are two simple sign-in methods you can use with your existing Organizational Account powered by Windows Azure AD to sign-in to Windows Azure. This includes the Organizational Account you might already use to log into Office 365.

1. Use the Windows Azure sign-in page
You can use the standard Windows Azure sign-in page that you use to access the Windows Azure Management Portal. To sign-in with your Office 365 organizational account, click the link named Already use Office 365? as shown in the following
diagram.

2. Bypass the Windows Azure sign-in page
Alternatively, you can bypass the sign-in page prompts by adding your company’s existing federated domain name to the end of the Windows Azure Management Portal URL. For example from a domain joined machines, point your browser to https://windows.azure.com/contoso.com. If your company has setup federation with Windows Azure AD or if you are already logged into Office 365, you will be logged in to Windows Azure automatically.

To illustrate how this works, let’s use an example of a user named Andrew who works for a fictitious company named Identity365.net. The company has an existing Office 365 subscription and they’ve previously set up federation with Windows Azure AD. 

To access Windows Azure, Andrew logs in to his domain joined PC and types the URL for Windows Azure, but adds his company’s domain name to the end of the URL (https://windows.azure.com/identity365.net).

Windows Azure AD recognizes that identity365.net is a federated domain, and silently redirects Andrew to his organization’s on-premises Active Directory Federation Service (AD FS) server.  Andrew’s organization has configured their AD FS server to require multifactor authentication because they manage medical records using Windows Azure, and they must be HIPPA compliant.

Andrew then inserts his smartcard and selects his name from the list above. His PC then prompts him for the smartcard PIN:

Once he enters his smartcard pin, he is automatically signed into the Management Portal.


 
If Andrew doesn’t provide a smartcard, or uses the wrong pin, his company’s Windows Server AD FS denies him access. By default, Windows Server AD FS will show the standard HTTP 403 Forbidden response code for when improper credentials are submitted during sign-in, but this can be customized to provide a more user-friendly behavior:

How federated access works with Windows Azure
The following illustrations shows how federated access works between Windows Azure AD, the Windows Azure Management Portal, Windows Server AD FS and your company’s on-premises Windows Server Active Directory:

Step 1: User logs into the local domain-joined corporate PC

The following actions occur automatically:

  • The local domain controller validates the user’s credentials.
  • The domain controller generates Kerberos Ticket Granting Ticket valid for X hours. The default is 600 minutes [10 hours], but is configurable by local IT admin policy.
  • Alternatively, local IT admin policy may require multifactor login to the local desktop. If that isthe case, theKerberos Ticket Granting Ticket will record the multifactor claims.

 

Step 2: User types the Windows Azure Portal with his company name

The user types https://windows.azure.com/fabrikam.com

 The following actions occur automatically:

  • The Windows Azure Management Portal parses the URL and extracts the domain name of fabrikam.com. 
  • The Management Portal then performs a redirect to Windows Azure AD, passing the requested home-realm as a query string (whr=fabrikam.com). 

 

Step 3: Windows Azure AD performs look up and then redirect

The following actions then occur automatically:

  • Windows Azure AD looks up the DNS name of the on-premise AD FS server that has been previously configured for the fabrikam.com home-realm.
  • It then redirects the client PC to the required AD FS server DNS name (sts.fabrikam.com).

 

Step 4: On-Premises AD FS sends authentication challenge sends SAML token

The following actions now occur automatically:

  • The on-premises AD FS server challenges the client PC by requesting authentication.
  • The clientPC’s browser passes the previously-generated Kerberos Ticket Granting Ticket to the on-premise KDC (ticket granting server), requesting a Service Ticket.
  • The KDC issues the client a Service Ticket, containing the multifactor claims (this assumes that IT policy forced smartcard authentication at desktop login time, otherwise, AD FS can challenge to present a smartcard during this Windows Azure Management Portal login sequence).
  • The client PC presents the Service Ticket to AD FS.  AD FS validates the Kerberos ticket and generates a signed SAML token for Windows Azure AD in the next step.  AD FS will only send the signed SAML token if the credentials are valid.

 

Step 5: AD FS redirects back to Windows Azure AD

The following actions occur automatically:

  • AD FS performs a redirect with the signed SAML claims as a form POST back to Windows Azure AD, attesting to the valid credentials. 
  • The SAML claims do not contain the corporate credentials.  The actual user credentials never leave the local site.

 

Step 6: AD FS Authentication Challenge

In the final step, the following actions occur automatically:

  • Windows Azure AD transforms the AD FS SAML tokens to its own signed identity claims for the Windows Azure Management Portal.
  • It then performs a POST back to the Management Portal.
  • The Management Portal decrypts the Windows Azure AD claims, extracts the user’s local identity pointer, and looks up the user’s Windows Azure subscription based on that identity.
  • The user is now authenticated into the Windows Azure Management Portal via multifactor authentication.

To learn more about how you can set up single sign on between your company’s on-premises directory and Windows Azure Active Directory, click here. 

If your company is already using Office 365 or another Microsoft cloud servie backed by Windows Azure AD, you can immediately get started by purchasing a new Windows Azure subscription using your corporate identity. To start the purchasing process, visit https://account.windowsazure.com/yourcompanyname.com, replacing the last portion of the URL with your corporate DNS name.

I look forward to your comments, questions and feedback below!

Best Regards,

Alex Simons
Director of Program Management
Active Directory Division