Active directory-from-on-premises-to-the-cloud

Active Directory from on-premises to
the cloud
Microsoft France
Published: January 2013
Version:1.0

Author: Philippe Beraud (Microsoft France)
Contributors/Reviewers:Arnaud Jumelet (Microsoft France), Christophe Leroux (Microsoft
Corporation), Philippe Maurent (Microsoft Corporation)

Copyright
© 2013Microsoft Corporation. All rights reserved.

Abstract
Identity management, provisioning, role management, and authentication are key services both
on-premises and through the (hybrid) cloud. With the Bring Your Own Apps (BYOA) for the cloud
and Software as a Service (SaaS) applications, the desire to better collaborate a la Facebook
with the ―social‖ enterprise, the need to support and integrate with social networks, which lead to
a Bring Your Own Identity (BYOI) trend, identity becomes a service where identity ―bridges‖ in the
cloud talk to on-premises directories or the directories themselves move and/or are located in the
cloud.
Active Directory (AD) is a Microsoft brand for identity related capabilities. In the on-premises
world, Windows Server AD provides a set of identity capabilities and services and is hugely
popular (88% of Fortune 1000 and 95% of enterprises use AD). Windows Azure AD is AD
reimagined for the cloud, designed to solve for you the new identity and access challenges that
come with the shift to a cloud-centric, multi-tenant world.
Windows Azure AD can be truly seen as an IdentityManagementasaService (IDMaaS) cloud
multi-tenant service. This goes far beyond taking AD and simply running it within a VM in
Windows Azure.
This document is intended for IT professionals, system architects, and developers who are
interested in understanding the various options for managing and using identities in their (hybrid)
cloud environment based on the AD foundation and how to leverage the related capabilities.AD,
AD in Windows Azure and Windows Azure AD are indeed useful for slightly different scenarios.

This document is provided ―as-is‖. Information and views expressed in this document, including URL and
other Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft
product. You may copy and use this document for your internal, reference purposes. You may modify
this document for your internal, reference purposes.
© 2013 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Internet Explorer, SQL Server, Windows, Windows PowerShell, and
Windows Server are trademarks of the Microsoft group of companies. All other trademarks are property
of their respective owners

Content

1 INTRODUCTION ............................................................................................................................. 1
1.1 OBJECTIVES OF THIS PAPER .................................................................................................... 2
1.2 NON-OBJECTIVES OF THIS PAPER ............................................................................................ 4
1.3 ORGANIZATION OF THIS PAPER ................................................................................................ 4
1.4 ABOUT THE AUDIENCE ............................................................................................................. 5
2 AD IN WINDOWS AZURE IS NOT WINDOWS AZURE AD! ......................................................... 6
3 WHAT IS WINDOWS AZURE AD? ................................................................................................ 9
3.1 TYPE OF IDENTITIES ..............................................................................................................13
3.2 ANATOMY OF W INDOWS AZURE AD .......................................................................................15
4 SYNCHRONIZE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-
PREMISES DIRECTORY .......................................................................................................................31
4.1 SYNCHRONIZE YOUR DIRECTORY TENANT WITH ACTIVE DIRECTORY ON-PREMISES ...................32
4.2 SYNCHRONIZE YOUR DIRECTORY TENANT WITH NON-AD DIRECTORIES ON-PREMISES ...............39
5 FEDERATE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES
DIRECTORY ..........................................................................................................................................42
5.1 FEDERATE YOUR DIRECTORY TENANT WITH AN ON-PREMISES WS-* BASED IDENTITY PROVIDER45
5.2 FEDERATE YOUR DIRECTORY TENANT WITH AN ON-PREMISES SAML 2.0 BASED IDENTITY
PROVIDER .......................................................................................................................................46
6 ENABLE SINGLE SIGN-ON AND WINDOWS AZURE AD DIRECTORY SERVICES FOR
CLOUD APPLICATIONS .......................................................................................................................48
6.1 LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS SUBSCRIPTION .48
6.2 LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR LOB APPLICATION IN THE
CLOUD 51
6.3 LEVERAGE YOUR CUSTOMER‘S W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS
APPLICATION IN THE CLOUD ..............................................................................................................62
7 BRING YOUR OWN IDENTITY (BYOI) WITH WINDOWS AZURE AD ACCESS CONTROL ....70
8 ENSURE INFORMATION PROTECTION AND CONTROL (IPC) WITH WINDOWS AZURE AD
RIGHTS MANAGEMENT .......................................................................................................................75

Active Directory from on-premises to the cloud ii

1 Introduction

The cloud is changing the way in which applications are written. Accelerated market cycles, multi-
tenancy, pure cloud solutions and hybrid deployments, Web programmability, and the rise of devices
(smartphones, tablets, etc.) as well as rich clients as consumption models offer without any doubt new
opportunities.
They also present at the same time new challenges for the key services both on-premises and through
the (hybrid) cloud that represent the identity management, the provisioning, the role management, and
the authentication.
With:
The Bring Your Own Apps (BYOA) for cloud and Software as a Service (SaaS) applications,
The desire to better collaborate ala Facebook with the ―social‖ enterprise,
The need to support and integrate with social networks, which lead to a Bring Your Own
Identity (BYOI) trend,
Etc.
Identity becomes a service where identity ―bridges‖ in the cloud ―talk‖ to on-premise directories or the
directories themselves move and/or are located in the cloud (see Gartner report2013 PLANNING GUIDE:
IDENTITY AND PRIVACY1).
Identity, like compute and storage and networking, is an essential platform service. In the same way
that identity played a critical role in the adoption of workgroup computing, identity services will play a
critical role as organizations adopt the cloud. Organizations will use cloud services and applications
created by ISVs, Platform as a Service (PaaS) cloud platforms for (Line of Business (LOB)) custom
development, (as well as Infrastructure as a Service (IaaS) cloud environment for specific workloads to
onboard the cloud for IT optimization reasons).
Kim Cameron, Microsoft Chief Identity Architect, is convinced 2 that ―organizations will find they need
new identity management capabilities to take full advantage of the cloud. They will also find that the
most reliable and cost-effect way to obtain these capabilities is through Identity Management as a
Service – i.e. using the cloud to master the cloud.
We can therefore predict with certainty that almost all organizations will subscribe to identity services
that are cheaper, broader in scope and more capable than the systems of today.
Enterprises will use these services to manage authentication and authorization of internal employees,
the supply chain, and customers (including individuals), leads and prospects. Governments will use
them when interacting with other government agencies, enterprises and citizens.
Identity Management as a Service will require that we move beyond the models of identity
management that have guided our thinking to date. A new service-based model will emerge combining
more advanced capabilities with externalization of operations to achieve reduction in risk, effort and
cost.‖

1
2013 PLANNING GUIDE: IDENTITY AND PRIVACY: http://www.gartner.com/id=2221415
2
IDENTITY MANAGEMENT AS A SERVICE: http://www.identityblog.com/?p=1205

Active Directory from on-premises to the cloud 1

1.1 Objectives of this paper

Active Directory (AD) is a Microsoft brand for identity related capabilities. In the on-premises world,
Windows Server Active Directory (Windows Server AD or simply AD) provides a set of identity
capabilities and services and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD).
With the Infrastructure as aService (IaaS) capability in the cloud, such as the one offered by the
Windows Azure platform, it becomes possible to deploy virtual machines (VM) that host AD domain
controller.
Whilst such an approach could be more than appropriate for specific workloads on IaaS platforms like
a SharePoint environment, the Microsoft vision for the cloud consists in recreating a similar identity
service, but one that is optimized to support cloud applications and support modern protocols.
Windows Azure Active Directory (Windows Azure AD or AAD) is AD reimagined for the cloud (see blog
3 4
posts REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 1) , (PART 2) ), designed to
solve for you the new identity and access challenges that come with the shift to a cloud-centric, multi-
tenant world.
Windows Azure AD can be truly seen as an IdentityManagementasaService (IDMaaS) cloud multi-
tenantservice that provides a robust and comprehensive cloud identity platformarchitected to operate in
the cloud with high scale, high availability, and integrated disaster recovery. This goes far beyond
taking AD and simply running it within a VM in a hosted environment such as the IaaS capability of
Windows Azure: Windows Azure AD is definitely different than running AD in a Windows Azure VM.
Being optimized to support cloud services and supports modern protocols such as REST and OAuth2
for mobile and consumer scenarios, Windows Azure AD typically provides identity and access
capabilities for:
Cloud-based applications on Windows Azure or in other clouds such Amazon Web Services
(AWS),
SaaS applications or multi-tenant applications such as the Microsoft Office 3655, which relies
on it for its identity infrastructure,
Mobile applications (with or without a back-end in the cloud like the one proposed through the
Windows Azure Mobile Services6),
Etc.
Windows Azure AD utilizes the enterprise-grade quality and proven capabilities of Windows Server AD
on-premises, so you can bring your applications to the cloud easily. It offers capabilities that can be
leveraged to centralize the identity management needs of your solutions, whether they are cloud-
based, hybrid, or even on-premises. Windows Azure AD is a complete offering that can help you to
take advantage of your on-premises existing investment, to fully outsource to the cloud your user‘s
management and anything in between.
By connecting your existing on-premises identity infrastructure to Windows Azure AD, you can manage
a hybrid environment that provides unified authentication and access management for both cloud and
on-premises services and servers, eliminating the need to maintain new, independent cloud directories

3
REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 1):
http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining-active-directory-for-the-social-enterprise-part-1.aspx
4
5
Microsoft Office 365 provides secure anywhere access to professional email, shared calendars, instant messaging (IM), video
conferencing, and document collaboration, see http://office365.microsoft.com/
6
Windows Azure Mobile Services: http://www.windowsazure.com/en-us/home/features/mobile-services/

2 Active Directory from on-premises to the cloud

and thus avoiding to recreate in the cloud identity silos for the applications with all the burden and
hassle that comes with them in terms of operations.
By leveraging the Windows Azure AD core directory and authentication capabilitiesand beyond
handling authentication requests (e.g. to (cloud) services and applications user logins) that are sent
from the user and/or devices to Windows Azure AD, you can enable:
Single sign-on (SSO) across all your cloud applications as well as with your SaaS
subscriptions (provided that they support the integration with Windows Azure AD as it is the
case today for the Microsoft Online Services such as Office 365). SSO is the ability for a user
to login in once and not have to re-enter their credentials each time when accessing different
(cloud) or applications.
It represents an important part of Windows Azure AD because it delivers a secure, yet simple
and seamless way for the corporate users to connect to their resources running somewhere in
the cloud7.
Simple interoperability with your existing on-premises identity infrastructure based on Windows
Server Active Directory (AD) (or non-AD sources) through federation (and synchronization).
Federation is the ability for Windows Azure AD and your existing on-premisesidentity
infrastructure to work togetherdelivering a federated SSO experience for corporate users while
keeping user passwords on-premises and related policies on-premises.(Federation also gives
the option to require multifactor authentication for increased security.)
Via the use of open standards such as the OASIS WS-Federation, WS-Trust, and SAML 2.0
protocols, you can indeed quickly extend your existing on-premises directory authentication to
your cloud applications through Windows Azure AD. By using your existing on-premisesidentity
infrastructure as the authoritative identity provider, users are seamlessly authenticated to your
cloud applications with their existing corporate accounts.
At the end, if you are an organization, Windows Azure AD provides your corporate users with a
seamless, (federated) SSO experience across all your cloud applications, while simplifying the
adoption of SaaS subscriptions, as well as the development of your own cloud applications.
Conversely, if you are an ISV, you can leverage Windows Azure AD to reach a vast user population,
which includes the ever-growing user base of the Office 365.
As of today, since its introduction, Windows Azure AD has ―now processed 200 Billion authentications
for 50 Million active user accounts. In an average week we receive 4.7 Billion authentication requests
for users in over 420 Thousand different domains.‖8
Beyond the support of AD in Windows Azure, this paper provides you with a ―tour‖ of Windows Azure
AD to learn about its capabilities, interfaces, and to understand how it works in concert with Windows
Server Active Directory (AD) (or non-AD sources).
It discusses the possible options to perform federated provisioning and synchronization of identity
information from Active Directory sources and non-AD directories sources to Windows Azure AD for
the cloud and SaaS applications. This document also introduces the new Windows AzureDirectory
Graph, a REST-based API that enables access to your Windows Azure AD directory tenant.
It further presents the SSO and the Federation capabilities for your cloud (multi-tenant) applications
and SaaS subscriptions.

7
The best user experience for corporate users on the corporate network is provided with domain-joined machines.
8
WINDOWS AZURE ACTIVE DIRECTORY PROCESSES 200 BILLION AUTHENTICATIONS - CONNECTING PEOPLE, DATA AND DEVICES AROUND THE
GLOBE: http://blogs.msdn.com/b/windowsazure/archive/2012/11/27/windows-azure-active-directory-processes-200-billion-
authentications-connecting-people-data-and-devices-around-the-globe.aspx


Furthermore, with Windows Azure AD Access Control (formerly Windows Azure Access Control
Services or ACS), a unified federated SSO experience in the cloud can now be planned. With the
ongoing dissolution of the boundary between ―internal‖ or at least organizational identities and external
or social identities, it indeed has out-of-the-box support for popular web identity providers including
Microsoft Account (formerly known as Windows Live ID), Google, Yahoo!, and Facebook and any
Open ID identity providers. The interaction between your Windows Azure AD directory tenant and your
namespaces in Windows Azure AD Access Control is also covered as part of this paper.
Finally, a new capability for Information Protection and Control (IPC) is also introduced: Windows
Azure AD Rights Management.
This paper can be seen a starting point for anyone challenged with identity, provisioning, federation or
cloud based authentication.
Special thanks toAlex Simons, Edward Wu,John Shewchuk,Kim Cameron, Stuart Kwan, Vittorio
Bertocci, and Yannick Kristoficfor providing valuable content on thesetopics.

1.2 Non-objectives of this paper

This document doesn‘t discuss the deployment and configuration of Windows Server AD on-premises.
This document is intended as an overview document for AD in Windows Azure and Windows Azure
AD, and as such, it doesn‘t provides neither in-depth description nor detailed step-by-step instructions
on how to implement a specific covered feature or capability. Where necessary, it instead refers to
more detailed documents, articles, and blog posts that describe a specific feature or capability.
Furthermore, this document is part of a document series on the identity and security features of
Windows Azure AD and Microsoft Office 365. It indeed completes the following whitepapers already
available on the Microsoft Download Center:
MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.09;
MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.010;
INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH W INDOWS AZURE AD
RIGHTS MANAGEMENT11;
INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS12.

1.3 Organization of this paper

To cover the aforementioned objectives, this document is organized by themes which are covered in
the following sections:
AD IN W INDOWS AZURE IS NOT W INDOWS AZURE AD!;
W HAT IS W INDOWS AZURE AD?;

9
MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.0: http://www.microsoft.com/en-
us/download/details.aspx?id=28971
10
MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.0: http://www.microsoft.com/en-
11
INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH WINDOWS AZURE AD RIGHTS MANAGEMENT:
http://www.microsoft.com/en-us/download/details.aspx?id=34768
12
INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS: http://www.microsoft.com/en-


SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY;
FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY;
ENABLE SINGLE SIGN-ON AND W INDOWS AZURE AD DIRECTORY SERVICES FOR CLOUD
APPLICATIONS;

BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZURE AD ACCESS CONTROL;
ENSURE INFORMATION PROTECTION AND CONTROL (IPC) WITH W INDOWS AZURE AD RIGHTS
MANAGEMENT.

1.4 About the audience

This document is intended for IT professionals, system architects, and developers who are interested
in understandingthe various options for managing and using identities in their (hybrid) cloud
environment based on the AD foundation and how to leverage the related capabilities.
AD, AD in Windows Azure and Windows Azure AD are indeed useful for slightly different scenarios.
We recommend using Windows Azure AD in addition to on-premises AD (and AD in Windows Azure)
in most cases as one doesn‘t replace the other.


2 AD in Windows Azure is NOT Windows Azure AD!

Microsoft announced13 in June 2012 the release of Windows Azure Virtual Machines14, an IaaS offering
in the Windows Azure platform in the cloud. Such an offering helps moving (part of) your business,
applications and infrastructure to the cloud without changing existing code in their own unique way, at
their own unique speed.
As its name clearly indicates, Windows Azure Virtual Machines provides support for virtual machines
(VM).At a glance, a VM consists of a piece of infrastructure to deploy an application. Specifically, this
includes a persistent operating system (OS) disk, possibly some persistent data disks, and
internal/external networking ―glue‖/connectivity to hold it all together. With these infrastructure
ingredients, itenables to create a platform where customers and partners can deploy existing
applications to take advantage of the reduced cost and ease of deployment offered in Windows Azure.
VMs indeedgive you application mobility, allowing you to move your virtual hard disks (VHDs) back and
forth between on-premises and the cloud. This enables you to migrateyour existing VM, to bring your
own customized Windows Server or Linux images, etc. As a common virtualization file format, VHD
has been adopted by hundreds of vendors and is a freely available specification15 covered under the
Microsoft Open Specification Promise (OSP) 16. The new version VHDX17 is also available as a free
specification covered under the OSP.
While “migration” is a simple goal for any IaaS offering, the ultimate objective consists in being
able to run the exact same on-premises applications and infrastructure or part of them in the
cloud and thus enabling onboarding and offboarding of workloads in order to improve the
agility of the organization, i.e. its ability to capitalize on new opportunities and respond to
changes in business demands.
Such a process might involve transferring an entire multi-VM workload, which may require virtual
networks for hybrid connectivity to an on-premises deployment.(This can be seen as a cross-premises
deployment.) This is where Windows Azure Virtual Networks comes into play.
Windows Azure Virtual Network, another capability of the Windows Azure IaaS offering, lets you
provision and manage virtual networks (VNET) in Windows Azure. A VNET is the ability for the
administrator to create a logical boundary and place into it VMs. VNET also provides the capability of
connecting Windows Azure Cloud Services18 (web roles and worker roles) that are in the same affinity
group directly with them.

Note:

An affinity group is a container where you choose the location (Windows Azure region) and where you
placed your Windows Azure resources. An affinity group represents also a convenient way to
designate a Windows Azure data center region with the name of your choice. (As of this writing,

13
ANNOUNCING NEW WINDOWS AZURE SERVICES TO DELIVER ―HYBRID CLOUD‖:
http://blogs.msdn.com/b/windowsazure/archive/2012/06/06/announcing-new-windows-azure-services-to-deliver-hybrid-
cloud.aspx
14
Windows Azure Virtual Machines: https://www.windowsazure.com/en-us/home/features/virtual-machines/
15
VIRTUAL HARD DISK IMAGE FORMAT SPECIFICATION: http://go.microsoft.com/fwlink/p/?linkid=137171
16
Open Specification Promise: http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx
17
VHDX FORMAT SPECIFICATION V1.00: http://www.microsoft.com/en-us/download/details.aspx?id=34750
18
Windows Azure Cloud Services: http://www.windowsazure.com/en-us/home/scenarios/cloud-services/


Windows Azure Cloud Services can be added to an affinity group only at the time of creation of the
service.).

Windows Azure Virtual Networkprovides control over network topology, including configuration of IP
addresses, routing tables and security policies. A VNET has its own private address space. The
address space is initially IPv4 only, but could be extended to IPv6 in a future release.
Windows Azure Virtual Networkallows securely extending on-premises networks into the cloud. With
the ability to assign a private address range for its VNET, an organization can indeed treat it as an
extension of its own corporate private network address space by establishing appropriate gates (VPN
gateway) between their on-premises corporate private network and their virtual network(s) in Windows
Azure. For that purpose, Windows Azure Virtual Networkenables to set up secure site-to-site
connectivity between the organization‘s corporate VPN gateway and Windows Azure, and then to
connect the organization‘s on-premises corporate network to the organization‘s Windows Azure tenant
by using a VPN gateway along with the industry-standard IPSEC protocol.
With such a capability, IT administrators can easily create a logically isolated private environment in
Windows Azure, and connect it to the organization‘s on-premises IT infrastructure by using a secure
VPN tunnel. Once set up, the isolated Windows Azure environment can be view as a natural extension
of the on-premises corporate network.
To synthetize, Windows Azure Virtual Network allows you to create private network(s) of VMs in your
Windows Azure tenant environment that you can assign IP addresses to and then connect to your data
center through a VPN gateway. Using this method, you can seamlessly connect on-premises (virtual)
machines toVMs running in your Windows Azure tenant.
The above capabilities enable the support of three key Microsoft workloads to deploy in the cloud:
1. Active Directory:An hybrid identity solution with extensive networking expectations;
2. SQL Server:A database workload with expectations for exceptional disk performance;
3. SharePoint Server: A large-scale, multi-tier application with a load-balanced front-end.
Moreover, SharePoint Server deployments include Active Directory and SQL Server.
These broad workload types canbe deployed either standalone or as part of a larger application, with
or without on-premises connectivity.
In the specific context of this paper, Windows Azure Virtual Machines and Windows Azure Virtual
Network enable AD in Windows Azure a reality of today.
The fundamental requirements for deploying Windows Server AD on VM(s) in Windows Azure differ
very little from deploying it in VMs (and, to some extent, physical machines) on-premises. For example,
if the domain controllers (DCs) that you deploy on WM are replicas in an existing on-premises
corporate domain/forest, then the Windows Azure deployment can largely be treated in the same way
as you might treat any other additional Windows Server AD site. That is, subnets must be defined in
Windows Server AD, a site created, the subnets linked to that site, and connected to other sites using
appropriate site-links. There are, however, a number of differences that are common to all Windows
Azure deployments and some that vary according to the specific deployment scenario.
The articles INSTALL A NEW ACTIVE DIRECTORY FOREST IN W INDOWS AZURE19 and GUIDELINES FOR
DEPLOYING W INDOWS SERVER ACTIVE DIRECTORY ON W INDOWS AZURE VIRTUAL MACHINES20cover the
fundamental differences and explained in great detail how successfully deploy and operate AD in
Windows Azure. The former deals with a standalone configuration in the cloud whereas the latter

19
INSTALL A NEW ACTIVE DIRECTORY FOREST IN W INDOWS AZURE: http://www.windowsazure.com/en-
us/manage/services/networking/active-directory-forest/
20
GUIDELINES FOR DEPLOYING W INDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090


highlights the requirements for deploying AD in a hybrid scenario in which Windows Server AD is partly
deployed on-premises and partly deployed on VMs in Windows Azure.
Whatever the scenario is, and as you understand, AD in Windows Azure simply means
Windows Server AD running in your VMs in your Windows Azure tenant for the best
compatibility with existing applications and for hybrid applications.
AD in Windows Azure is NOT Windows Azure AD, a REST-based service that provides identity
management and access control capabilities for cloud applications.
Wikipedia21 defines REST and RESTful service as follows:
―Representational State Transfer (REST) is a style of software architecture for distributed
hypermedia systems such as the World Wide Web. The term Representational State Transfer was
introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Fielding is one of the
principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.
Conforming to the REST constraints is referred to as being ‗RESTful‘.
…
A RESTful web service (also called a RESTful web API) is a simple web service implemented
using HTTP and the principles of REST. It is a collection of resources, with three defined aspects:
the base URI for the web service, such as http://example.com/resources/
the MIME type of the data supported by the web service. This is often JSON, XML or
YAML but can be any other valid MIME type.
the set of operations supported by the web service using HTTP methods (e.g., POST,
GET, PUT or DELETE).‖
With this definition in mind, let‘s considerwhat Windows Azure AD is all about in the next section.

21
REST : http://en.wikipedia.org/wiki/Representational_State_Transfer


3 What is Windows Azure AD?

Windows Azure Active Directory (Windows Azure AD or simply AAD) was introducedback in November
2011 as the cloud service that provides identity and access capabilities for services on Microsoft Office
365.
John Shewchuk, the Microsoft Technical Fellow who plays a key role in getting our cloud identity
offering engineered right, describes22 Windows Azure ADas follows: ―We have taken Active Directory, a
widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a
multi-tenant service with Internet scale, high availability, and integrated disaster recovery.
Since we first talked about it in November 2011, Windows Azure AD has shown itself to be a robust
identity and access management service for both Microsoft Office 365 and Windows Azure–based
applications.
In the interim, we have been working to enhance Windows Azure AD by adding new, Internet-focused
connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere
and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms
like Amazon Web Services, and technologies like Java.
The easiest way to think about Windows Azure AD is that Microsoft is enabling an organization‘s Active
Directory to operate in the cloud. Just like the Active Directory feature in the Windows Server operating
system that operates within your organization, the Active Directory service that is available through
Windows Azure is your organization‘s Active Directory. Because it is your organization‘s directory, you
decide who your users are, what information you keep in your directory, who can use the information
and manage it, and what applications are allowed to access that information. And if you already have
on-premises Active Directory, this isn‘t an additional, separate copy of your directory that you have to
manage independently; it is the same directory you already own that has been extended to the cloud.
Meanwhile, it is Microsoft‘s responsibility to keep Active Directory running in the cloud with high scale,
high availability, and integrated disaster recovery, while fully respecting your requirements for the
privacy and security of your information.
As such, it provides easy-to-use, multi-tenant identity management services for applications running in
the cloud and on any device and any platform with the Bring Your Own Device (BYOD) as a result of
the Consumerization of IT.‖
Windows Azure AD provides a multi-tenantcloud-based store for directory data and a core set
of identity services including user logon processes, authentication and federation services.
Windows Azure AD is able to scale to millions of customers and billions of objects.
As of today, since its introduction, Windows Azure AD has ―now processed 200 Billion authentications
for 50 Million active user accounts. In an average week we receive 4.7 Billion authentication requests
for users in over 420 Thousanddifferent domains. This is a massive workload when you consider
others in the industry are attempting to process 7B logins per year‖.
A number of people are surprised to find out that every Office 365 customer already has a
Windows Azure AD directory tenant.
Windows Azure AD is indeed the directory used by Office 365 to store user identities and other tenant
properties.

22


If you are a Microsoft Office365 customer,you can then navigate to the (preview of the) Windows Azure
AD Management Portal23 (activedirectory.windowsazure.com) and sign in with your organizational
account.

Windows Azure AD is used by a number of Microsoft cloud services today, and through the developer
preview program it is possible to extend the usage of these directory tenants to other applications.
It‘s also possible to obtain a ―standalone‖ directory tenant through theprovisioning system.If you don‘t
already have a tenant, you can set up your own custom Windows Azure AD ―standalone‖ directory
tenant for free as part of the developer preview programby following the
linkhttp://g.microsoftonline.com/0AX00en/5.

If you create a new tenant, the first user you generate as part of the sign-up process will also be an
administrator.

23
Preview of the Windows Azure AD Management Portal: https://activedirectory.windowsazure.com/


The developer preview of Windows Azure AD is currently available as a free preview service. It
is not intended for production use at this time.
At general availability (GA), Windows Azure AD will remain available at NO charge. (See blog
post W INDOWS AZURE ACTIVE DIRECTORY: MAKING IT EASIER TO ESTABLISH IDENTITY MANAGEMENT IN THE
CLOUD24)
Same is true for Windows Azure AD Access Control (see section § 7BRING YOUR OWN IDENTITY (BYOI)
WITH W INDOWS AZURE AD ACCESS CONTROL).

The rest of this chapter describes the main characteristics of Windows Azure AD that organizations
and cloud applications can leverage, and the functionalities that Windows Azure AD provides for the
users of these applications and for the developers of these applications to be successful.
As of today, Windows Azure AD is still in preview and keeps continuing to receive enhancements that
make Windows Azure AD even more useful for IT professionals and developers.

Note:

Please make sure you periodically check the Windows Azure Active Directory community forum 25 as
well as the MSDN Windows Azure blog26 for notification of upcoming enhancement and changes that
relate to Windows Azure AD.

For a short look back at the recent enhancements, the starting point since the initial introduction in
2011 is the announcement of the developer preview in June 2012 (see blog post ANNOUNCING THE
DEVELOPER PREVIEW OF W INDOWS AZURE ACTIVE DIRECTORY27). New components have been introduced
with the developer preview in order to make it easy for developers to take advantage of Windows
Azure AD for adding single sign-on and directory management capabilities to Web applications, rich
clients and RESTful services. Specifically, the following capabilities were announced:
Web Single Sign-On (SSO) for cloud and SaaS applications with the support of the WS-
Federation protocol (see section § 6ENABLE SINGLE SIGN-ON AND W INDOWS AZURE AD
DIRECTORY SERVICES FOR CLOUD APPLICATIONS),
Windows Azure Active Directory Graph, a RESTful API to programmatically access identity
relationships in the Windows Azure AD directory to build rich applications (see section §
3.2.1.4PROGRAMMING INTERFACE).
The Microsoft TechEd US 2012 session recordingsA LAP AROUND W INDOWS AZURE ACTIVE
DIRECTORY28and DIRECTORY GRAPH API: DRILL DOWN29 provide an introduction to these capabilities.
In August 2012 was introduced the Windows Azure Authentication Library (AAL), a new capability in
the developer preview (see blog post INTRODUCING A NEW CAPABILITY IN THE W INDOWS AZURE AD

24
W INDOWS AZURE ACTIVE DIRECTORY: MAKING IT EASIER TO ESTABLISH IDENTITY MANAGEMENT IN THE CLOUD:
http://blogs.msdn.com/b/windowsazure/archive/2012/11/30/windows-azure-active-directory-making-it-easier-to-establish-identity-
management-in-the-cloud.aspx
25
Windows Azure Active Directory community forum: http://social.msdn.microsoft.com/Forums/en-US/WindowsAzureAD/
26
Windows Azure blog: http://blogs.msdn.com/b/windowsazure/
27
ANNOUNCING THE DEVELOPER PREVIEW OF WINDOWS AZURE ACTIVE DIRECTORY:
http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-
directory.aspx
28
A LAP AROUND WINDOWS AZURE ACTIVE DIRECTORY: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA209
29
DIRECTORY GRAPH API: DRILL DOWN: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA322


DEVELOPER PREVIEW: THE W INDOWS AZURE AUTHENTICATION LIBRARY30). Whilst developers can of course
write directly to the standards based protocols supported in Windows Azure AD, this library is another
option available for developers who are looking for a faster and simpler way to take advantage of
Windows Azure ADin high value scenarios, including the ability to secure access to your cloud
applications (see section § 6.2.2ENABLE SINGLE SIGN-ON (SSO) WITH W INDOWS AZURE AD).
In September 2012, three major enhancements have been made available to the developer preview as
announced in the blog post MORE ADVANCES IN THE W INDOWS AZURE ACTIVE DIRECTORY DEVELOPER
PREVIEW31:
The ability to create a standalone Windows Azure AD directory tenant,
A preview of the Windows Azure AD Management portal that gives a graphical user interface
to manage the directory tenant,
Write support in the Windows Azure Active Directory Graph API.

Note:

This latter update includes support for create, update, delete operations for users, groups, and group
Membership, user license assignments, contact management, and set JavaScript Object Notation
(JSON) as the default data format, which is of interest for instance for mobile applications.

Lastly, in November 2012, and as described on the blog post ENHANCEMENTS TO W INDOWS AZURE
ACTIVE DIRECTORY PREVIEW32, the following enhancements have been added:
Added graphical user interfaces for registering your cloud application in a directory tenant,
Support for the SAML 2.0 protocol for Web SSO,
Sign out support for the WS-Federation protocol in Web SSO,
Differential query in the Windows Azure Active Directory Graph API,
The ability to federate Windows Azure AD directory tenants with Windows Azure AD Access
Control namespaces (see section § 7BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZURE
AD ACCESS CONTROL),
And an updated version of the Windows Azure Authentication Library (AAL).
Even more Windows Azure AD functionalities will be integrated this year for your identities in the cloud.
The rest of the document provides a description for all of the above.

30
INTRODUCING A NEW CAPABILITY IN THE WINDOWS AZURE AD DEVELOPER PREVIEW: THE WINDOWS AZURE AUTHENTICATION LIBRARY:
http://blogs.msdn.com/b/windowsazure/archive/2012/08/01/introducing-a-new-capability-in-the-windows-azure-ad-developer-
preview-the-windows-azure-authentication-library.aspx
31
MORE ADVANCES IN THE WINDOWS AZURE ACTIVE DIRECTORY DEVELOPER PREVIEW :
http://blogs.msdn.com/b/windowsazure/archive/2012/09/12/more-advances-in-the-windows-azure-active-directory-developer-
preview.aspx
32
ENHANCEMENTS TO W INDOWS AZURE ACTIVE DIRECTORY PREVIEW :
http://blogs.msdn.com/b/windowsazure/archive/2012/11/07/enhancements-to-windows-azure-active-directory-preview.aspx


3.1 Type of identities

Windows Azure AD enables a customer to be able to start using its services with no on-premises
footprint. Accordingly, Windows Azure AD provides for hosted (cloud) identities where customers can
create users, groups and other principals for their organization.The cloud identities (Cloud ID) are
mastered in Windows Azure AD.
With cloud identities,users receive, for signing into Windows Azure AD and any services and
applications that are integrated into Windows Azure AD (see section § 6ENABLE SINGLE SIGN-ON AND
W INDOWS AZURE AD DIRECTORY SERVICES FOR CLOUD APPLICATIONS),cloud credentials (that are
separate from other desktop or corporate on-premises credentials if any).
Many enterprise customers will want to federate their on-premises identity infrastructure with Windows
Azure AD to establish a hybrid corporate identity platform.It‘s a more sophisticated approach in the
sense that it requires setting up a federation between their on-premises identity infrastructure and
Windows Azure AD(see section § 5FEDERATE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR
ON-PREMISES DIRECTORY). Users can then sign into Windows Azure AD or any services and
applications that are integrated into Windows Azure AD using their own corporate credentials. The
user‘s IDs are mastered on-premises in the identity infrastructure and synchronized to the Windows
Azure AD in the form of federated identities (federated ID).
Users can gain access to Windows Azure ADor any services and applications that are integrated into
Windows Azure AD by authenticating to their Windows Azure AD user accounts, either through a
prompt to provide valid credentials or through a federated single sign-on (SSO) process. Once
authenticated, user‘s identities refer to the user names associated with the Windows Azure AD
accounts.
Considering the above, we have three authentication/deployment model types available:
1. Cloud identities;
2. Cloud identities + directory synchronization;
3. Federated identities + directory synchronization.
Through directory synchronization, organizations can keep their existing on-premises identity
infrastructure synchronized with their Windows Azure AD directory tenant. The directory
synchronization is discussed in section § 4SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT
WITH YOUR on-premises directoryfor larger organization‘s that may want to streamline the provisioning
and the synchronization of identities.
The above type of identity (cloud vs. federated) affects the user experience, administrative
requirements, deployment considerations, and capabilities using Windows Azure AD.
The following is the simplified breakdown of the experience:
User experience with cloud identities:Users sign in with their cloud identity. Cloud identities
are authenticated using traditional challenge/response, where users type in their user name
and password.Authentication happens in the cloud. Users are always prompted for credentials.
As mentioned above, users may have two IDs, i.e.Cloud ID for Windows Azure AD itself and
the services and applications in the cloud that leverage Windows Azure AD and potentially one
for accessingon-premises services. Consequently, users are prompted for credentials even
when logged into their on-premises infrastructure (AD or non-AD sources) when accessing
Windows Azure AD itself and the services and applications in the cloud that leverage Windows
Azure AD.
User experience with federated identities: Users sign in with corporate ID for access to
online and corporate services. In other words, they are authenticated transparently using the
on-premises identity infrastructure when accessing Windows Azure AD itself and the services
and applications in the cloud that leverage Windows Azure AD. Authentication happens on-


premises against the organization‘s identity provider servers and users get true SSO.
Furthermore, multifactor authentication (MFA) can be utilized if it is deployed on-premises.

Important note:

Multifactor authentication (MFA) support is available is not available for clients other than Web
browsers. Other clients that do not have the capability to prompt users for strong authentication
credentials can therefore not be supported. Strong authentication must only be applied to the passive
federation endpoints on on-premises identity provider servers, as other clients will otherwise not be
able to connect.

Administrator experience with cloud identities:Organization‘s administrators managethe
password policy both in the cloud and on-premises. The cloud identities password policy is
stored in the cloud with Windows Azure AD. Password reset has to be managed for on-
premises and the cloud identities and, hence, the users have to change the password as per
the policy for both. Finally, there is no MFA integration.

Note:

With the recent acquisition of PhoneFactor33 in October 2012, MFA support could be introduced in
Windows Azure AD in the future. As Bharat Shah, corporate vice president, Server and Tools Division
for Microsoft, said, ―The acquisition of PhoneFactor will help Microsoft bring effective and easy-to-use
multifactor authentication to our cloud services and on-premises applications.‖

By leveraging a device nearly every user already has — a phone — PhoneFactor enables rapid
deployment of MFA across a wide range of applications. It already works with many Microsoft
products and services, including Outlook Web Access and Internet Information Services, and
interoperates with Active Directory

Administrator experience with federated identities:Organization‘s administrators
managethe password policy on-premises only and hence do not need to separately worry
about password reset for federated identities. The organization‘s identity infrastructure stores
and controls the password policy. Password reset occurs for on premise IDs only. Eventually,
several on-premises MFA integration options are offered.
While the ―federated identities + directory synchronization‖ model may require some server
investments and deeper architectural decision making, it does allow support for richer federated single
sign-on with the corporate credentials, integration with on-premises MFA and a configurable password
policy. It enables organization to adequately manage their hybrid environment.
Since organizations usually want to pilot/test something new with a small number of users and then
enable it for their full end user population, Windows Azure AD supports staged federation to allow a
customer to incrementally deploy or rollback federation.
For the moment, let‘s see how Windows Azure AD supports both cloud identities and federated
identities.

33
MICROSOFT ACQUIRES PHONEFACTOR: http://www.microsoft.com/en-us/news/Press/2012/Oct12/10-04MFAPR.aspx


3.2 Anatomy of Windows Azure AD

At the simplest level, Windows Azure AD (core directory and authentication) is a scalable directory
infrastructure that provides for storage, data access, replication and synchronization, and security
token services (STS).
Below is a conceptual diagram showing the public interfaces, and the management surface:

3.2.1 Core Directory

The core directory represents the heart of Windows Azure AD. As a directory (service in the cloud) and
with the objective to eliminate the need of an application-specific store for notably identity information,
Windows Azure AD aims at supporting data of common interest across the vast majority applications
whether they are cloud, SaaS, mobile, etc. applications as well as the possible relationships between
those data.

3.2.1.1 Data model and schema

Users and groups are typically good examples where organizations want to create them once and
reuse them across their applications or the ones for which they buy a subscription.
Information in the directory should generally have the following characteristics:
Public in the sense of something that is useful to share across the organization, and not
something private like the salary attribute of a user object,
Mostly static over the time, and not changed often,
Small, generally pointers to information vs. the information itself.
Unsurprisingly, Windows Azure AD follows the Windows Server AD data model with suitable changes
for cloud use. The core data model is as follows:
The directory is divided into directory contexts, one per tenant plus a system context. Each
directory context has an immutable,globally unique, non-reusable GUID-valued identifier – a
context ID – and contains a set of entities (or objects) and association (or links) between the
entities. Each object or link belongs to exactly one context.


Each object has anobject class or type (ObjectType): User, Contact, Group, etc. and an
immutable,globally unique, non-reusable GUID-valued identifier, i.e. an object ID (ObjectId).
An object contains a set of properties: DisplayName, UserPrincipalName, JobTitle,
Department, TelephoneNumber, etc. Each property has a name and, if set, contains a value
or a set of values. The object class determines which properties may appear on the object,
and the property determines the type (string, binary, integer, structure, etc.) and multiplicity of
the values.
An object may contain a set of navigationproperties that each corresponds to a link(or
association). A link is a directional, typed relationship from one object to another object, all in
the same context. The type of the link is its link class: Manager, DirectReports, MemberOf,
Members, etc. Links significantly contribute to establish an enterprise social graph as
34
discussed in the John Shewchuk blog post . Links maintain referential integrity: deleting the
source or target object of the relationship implicitly deletes the link.
Object (respectively link) instances may be group into set of
The Windows Azure AD directory schema defines the properties, object classes, and link classes;
much of it is a subset of standard LDAP v3 (and Windows Server AD) schemas.
It however differs from that of LDAP directories in the following ways:
Unlike entries in an LDAP directory, objects do not have distinguished names and are not
arranged into a distinguished multi-level hierarchy. Objects can be interpreted as having
various hierarchical relationships based on links and property values.
The directory does not support object class inheritance. In Windows Server AD, such a
capability was used in very limited ways but added significant complexity to the system.
The Windows Azure AD directory schema is fixed for a specific version of Windows Azure AD,
and, in particular for scaling reasons, it is not per-tenant. The Windows Azure AD directory
schema may evolve with versions of Windows Azure AD as it was the case for the Windows Server AD
directory schema over the time since its first introduction in the early 2000.
Generally speaking, applications that consume directory information tend to fall into the following
threeclasseswith respect to directory extensibility requirements.
1. A first class of application that corresponds to the vast majority doesn‘t need to extend the
directory and has no extensibility requirements to address.
2. A second class of applications has very simple extensibility needs where they need to publish
some information about a directory entity, such as a user, to other applications. As of today,a
built-in extensibility mechanism addresses this kind of extensibility requirements in the specific
and historical context of Microsoft Online Services applications. A similar mechanism for third-
party applications may be introduced in the future.
3. The final class of applications is the one without any surprise that has extensive extensibility
needs. They may maintain significant information about users and other objects, and also may
have complex query needs based on properties and links. These queries may be in the
mainline high volume path of the application. Exchange is an example of such an application.
The use of an application-specific local store for extensibility is probably the best option in this
case. With the advent of the cloud, storage capabilities are widely available through services
such as Windows Azure Storage and Windows Azure SQL database. An application that falls
into this model usually maintains its own tables in a storage service. A typical model might be
that rows in the table represent Windows Azure AD directory entities about which the

34


application maintains its information. One of the columns of the table would be a key that
identifies the entity in the directory (i.e. the join key). The other columns represent application-
specific information. The application can make use of the differential query capability
supported by the directory to manage the lifecycle of the rows in its tables utilizing the ―join
key‖.

3.2.1.2 Directory tenants

As most people know, the forest in Windows Server AD represents the administrative boundary.
Likewise, the directory tenant in Windows Azure AD represents an administrative boundary from a
customer viewpoint.
As a forest contains one or multiple domains, a directory tenant contains one or multiple domains.
After signing up for Windows Azure AD (or for a Microsoft Online service that leverage Windows Azure
AD such as Microsoft Office 365), the only domain associated with your subscription account and
created with the directory tenant is the <organization name>.onmicrosoft.comdomain chosen during
registration, for exampleidmgt.onmicrosoft.com.
This is the default domain.When you create a new user, the user‘s sign-in name and email address are
assigned to this default domain.
You can off course add one or more customs domains to a directory tenant rather than retaining the
onmicrosoft.com domain, and then assign users to sign in with any of the validated domains.
For that purpose, as you can declare enterprise administrator(s) for the forest, there are similarly
tenant wide administrators for the organization‘s directory tenant.
Tenant administrators can register multiple DNS domain names for theWindows Azure AD tenant of
the organization, for example demo.idmgt.archims.fr.The directory allows a tenant administrator to
register a DNS domain only after he proves that his organization owns the DNS namespace in the
public internet DNS. As of this writing, you can host up to 600 registered domains in your directory
tenant, each represented by a different DNS namespace.
A domain can be either a cloud (standard) domain or a federated (single sign-on) domain, meaning
that all users on a domain MUST use the same identity system: either cloud identity or federated
identity (see section § 3.1TYPE OF IDENTITIES).
For example, you could have one group of users that only needs a cloud identity because they don‘t
have an on-premises account and/or access on-premises systems, and another group of users who
have an on-premises account and/or use cloud applications and on-premises systems. You would use
add two domains to the directory tenant, such as contractors.demo.idmgt.archims.fr and
fte.demo.idmgt.archims.fr, and only set up the federation for one of them (see section § 5FEDERATE
YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY).

A domain can be converted from cloud to federated, or from federated to cloud.

3.2.1.3 Management surface

Windows Azure AD allows administrators to manage information in it through:
The use of the graphical user interface thanks to a Web-based management portal.


Note:

When you navigate to the (preview of the) Windows Azure AD Management Portal
(activedirectory.windowsazure.com), you will be potentially immediately redirected to the Windows
Azure AD sign-in service for authentication. The Windows Azure AD sign-in service is part of the
(logical) security token service (STS) of Windows Azure AD (see later in document in section §
3.2.2STS).

A set of Windows PowerShell cmdlets, that allows for scripting frequent operations: the
Microsoft Online Services Module for Windows PowerShell.
(On-premises management tools used to manage information in an on-premises directory and
then synchronized into Windows Azure AD with the directory synchronization.)
A Windows PowerShell "module" is a package that contains Windows PowerShell commands, cmdlets,
providers, functions, variables, and aliases. The
MicrosoftOnlineServicesModuleforWindowsPowerShell is a separate installation package
(AdministrationConfig-en.msi) for 32-bit35 or 64-bit36 Windows platforms, which includes cmdlets
specifically designed for Windows Azure AD/Office 365 administration. It indeed enables you to
connect a Windows PowerShell command shell to your Windows Azure AD directory tenant and then
to perform directory-oriented operations.
The cmdlets currently layer on the same SOAP based task oriented interface that the Web
management portal uses for accessing the directory.

Note:

Windows PowerShellis a task-based command-line shell and scripting language that is
designed for system/service administration and automation. It uses administrative tasks called
cmdlets. Each cmdlet has required and optional arguments, called parameters, that identify which
objects to act on or control how the cmdlet performs its task. You can combine cmdlets in scripts to
perform complex functions that give you more control and help you automate the administration of
Windows, applications and online services in the cloud. It has become a common way to manage the
latest generation of Microsoft products and services.

For more information about Windows PowerShell, please see the Windows PowerShell Web site37, the
Windows PowerShell online help38, and the Windows PowerShell Weblog39Windows PowerShell
Software Development Kit (SDK)40 that includes a programmer‘s guide along with a full reference.

Administrative privileges are needed on the local computer in order to install the Microsoft Online
Services Module for Windows PowerShell.
As an illustration, let‘s seehow to create custom domains within a directory tenant with the cmdlets
provided by this module.

35
Microsoft Online Services Module for Windows PowerShell (32-bit version): http://go.microsoft.com/fwlink/?linkid=236345
36
Microsoft Online Services Module for Windows PowerShell (64-bit version): http://go.microsoft.com/fwlink/p/?linkid=236293
37
Windows PowerShell Web site: http://www.microsoft.com/powershell
38
Windows PowerShell online help: http://technet.microsoft.com/en-us/library/bb978526.aspx
39
Windows PowerShell Weblog: http://blogs.msdn.com/powershell
40
Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx


The New-MsolDomain cmdlet enables to create a standard (managed) domain based on the specified
DNS domain names. After running this command, you have to prove that your organization owns the
DNS namespace in the public internet DNS.
For that purpose, you need to use the Get-MsolDomainVerificationDns cmdlet in order to get the
DNS record information required to create for the new managed domain. To prove that you control the
domain, you then use the output of the command to create a CNAME record in the authoritative DNS
server for the DNS domain used previously. Windows Azure AD indeed uses a DNS record that you
create at your registrar to confirm that you really own the domain. For additional information, please
refer to the Microsoft TechNet articles ADD YOUR DOMAIN41and VERIFY A DOMAIN AT ANY DOMAIN NAME
REGISTRAR42.

Once done, you finally prove your control of the DNS namespace by running the Confirm-
MsolDomain cmdlet.

Note:

The custom domain can also be added from the (preview of the)Windows Azure AD Management
Portal as well. The steps would be identical and the domain would still have to be verified in the same
way.

Similarly, you can use the New-MsolFederatedDomain cmdlet to create of custom federated (single
sign-on) domain in your directory tenant. Finally, the Set-MsolDomainAuthentication cmdlet enables
to convert a standard domain into a single-sign on domain.

Note:

For more information about the available cmdlets and how to use theme, see the Microsoft TechNet
articles USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR WINDOWS AZURE AD TENANT43and
WINDOWS POWERSHELL CMDLET DESCRIPTIONS44.

For more information about a cmdlet that you can run in Windows PowerShell, at the Windows
PowerShell command prompt, type ―Get-help‖ and the name of the cmdlet.

After creating one or multiple custom domains, you can verify that the domains were added correctly
via the (preview of the) Windows Azure AD Management Portal.

41
ADD YOUR DOMAIN:http://technet.microsoft.com/en-us/library/hh969247.aspx
42
VERIFY A DOMAIN AT ANY DOMAIN NAME REGISTRAR: http://technet.microsoft.com/en-us/library/jj151803.aspx
43
USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR W INDOWS AZURE AD TENANT: http://technet.microsoft.com/en-
us/library/jj151805
44
WINDOWS POWERSHELL CMDLET DESCRIPTIONS: http://technet.microsoft.com/en-us/library/jj151835.aspx


In the above screenshot, idmgt.onmicrosoft.com is the default domain created with the directory tenant.
The federated (single sign-on) domains demo.idmgt.archims.fr and sponline.demo.idmgt.archims.fr
have been successfully verified via the provided DNS information whereas thefederated (single sign-
on) domain idmgt.demo still needs to be verified.
When a domain is federated, you will no longer have the option to add the domain suffix to the user
accounts. The users will need to be created on-premises in order for them to have the federated
domain name available to them. You can still create accounts directly in the cloud, but they cannot
have the federated domain name assigned to them unless they are created on-premises. Remember
that the deployment model is ―federated identities + directory synchronization‖.
Moreover, and as expected, when the user signs-in to Windows Azure AD with his federated account,
he‘sinvited to authenticate on the on-premises identity infrastructure. If single sign-on is correctly set up
(see section § 5FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES
DIRECTORY), you will indeed notice that the user cannot even type a password in the login Web page of
the sign-in service of Windows Azure AD. Password will be indeed shaded. The user will beinstead
provided with a link to the declared on-premises identity provider.
You will see the following message: ―You are now required to sign at <your company>‖, i.e. the Sign in
at Demo.idmgt.archims.fr link from the screenshot hereafter. This is a redirect link to send the user to
the on-premises identity provider passive endpoint.


3.2.1.4 Programming interface

Windows Azure AD provides a query model for applications to access a Windows Azure AD directory
tenant. Applications can be cloud, SaaS/multi-tenant, mobile, etc. applications. Applications can also
publish information to the directory tenant subject to access control. (This will be later described in this
document with the notion of service principal.)
For that purpose, Windows Azure AD exposes a directory programming surface for querying and
updating the directory, and thus sustaining the identities lifecycle management as whole via aRESTful
API introduced in June 2012 called Windows Azure Active Directory Graph API.
This primary directory access protocol supports today the management of users, groups, etc. as well
as service licensing and directory tenant administration.
It represents a new way for application to connect to the directory through the use of REST/HTTP
interfaces.For that purpose, Windows Azure AD exposes a single common global URL for all tenants
for the Directory Graph API, where the tenant identifier is part of the URL to allow this.
The directory tenant‘s Graph endpoint is as follows:
https://graph.windows.net/<domain name or tenant ID>/45
Such as:
https://graph.windows.net/demo.idmgt.archims.fr/
An authorized application can then operate on information in Windows Azure AD through a URL such
as https://graph.windows.net/demo.idmgt.archims.fr/Users(‗philber@demo.idmgt.archims.fr‘), see the
MSDN article W INDOWS AZURE AD GRAPH COMMON QUERIES46 for a list of common queries with your
directory tenant.
Such a URL provides direct access to objects, here a user, in the directory tenant, for example, an
HTTP GET to this URL will provide the following JSON response (abbreviated for readability):

{ “d”: {
"Manager": { "uri":
"https://graph.windows.net/demo.idmgt.archims.fr/Users('User...')/Manager" },
"MemberOf": { "uri":
"https://graph.windows.net/demo.idmgt.archims.fr/Users('User...')/MemberOf" },
"ObjectId": "90ef7131-9d01-4177-b5c6-fa2eb873ef19",
"ObjectReference": "User_90ef7131-9d01-4177-b5c6-fa2eb873ef19",
"ObjectType": "User",
"AccountEnabled": true,
"DisplayName": "Philippe Beraud",
"GivenName": "Philippe",
"Surname": "Beraud",
"UserPrincipalName": "philber@demo.idmgt.archims.fr",
"Mail": "philber@idmgt.fr",
"JobTitle": "Architect",
"Department": "Office of CTO",
"TelephoneNumber": "00331577540yyyy",
"Mobile": "003366440xxxx",
"StreetAddress": "39, quai du President Franklin Roosevelt",
"PhysicalDeliveryOfficeName": "Oxygene",
"City": "Issy-Les-Moulineaux",
"State": "",
"Country": "FR",
"PostalCode": "92130" } }

This kind of Internet-friendly interface makes it easy for developers - building on any platformto
integrate their applications with Windows Azure AD. Using standard HTTP requests, a developer can
access any ―thing‖ in the directory (for instance, users), and they can access relationships between
things.

45
graph.windows.net now replaces directory.windows.net
46
W INDOWS AZURE AD GRAPH COMMON QUERIES: http://msdn.microsoft.com/en-us/library/windowsazure/jj126255.aspx


Continuing with the example above, you can see that it is easy to access a user‘s groups by using the
URL:
https://graph.windows.net/demo.idmgt.archims.fr/Users(‗philber@demo.idmgt.archims.fr‘)/MemberOf
Sending an HTTP GET to this URL would return the following JSON response (abbreviated for
readability) that provides a list of groups for the user who‘s the user principal name (UPN) is
philber@demo.idmgt.archims.fr:

…
"results": [
{ "__metadata": { … }
"ObjectId": "30a041bf-e43f-42d6-bec4-a24ce33d5d42",
"ObjectReference": "Group_30a041bf-e43f-42d6-bec4-a24ce33d5d42",
"ObjectType": "Group",
"DisplayName": "Architects",
"Mail": null
},
{ "__metadata": { … }
"ObjectId": "451758b1-a66e-4d74-b6ce-03c7ec2fee7e",
"ObjectReference": "Group_451758b1-a66e-4d74-b6ce-03c7ec2fee7e",
"ObjectType": "Group",
"DisplayName": "All Users",
"Mail": null
},
…

Because the Windows Azure Active Directory Graph APIis built using standard REST semantics, NO
special protocols or libraries are necessary to use yourWindows Azure AD directory tenant. HTTP is
enough.
As mentioned before, the November refresh of the developer preview adds the differential query
support. A differential query request returns all changes made to specified entities during the time
between two consecutive requests. For example, if you make a differential query request an hour after
the previous differential query request, only the changes made during that hour will be returned. This
functionality is especially useful when synchronizing directory tenant data with an application‘s data
store.
A differential query request URL is created by appending a query string to a directory tenant‘s Graph
endpoint. For example, a differential query request for a directory tenant with the
demo.idmgt.archims.fr domain name would begin with:
https://graph.windows.net/demo.idmgt.archims.fr/changes? (See MSDN article W INDOWS AZURE AD
GRAPH DIFFERENTIAL QUERY47).
The approach of using standard REST interfaces to operate over a graph containing entities (nodes)
and relationships (arcs) between entities - often referred to as a graph interface - is very common on
the Internet nowadays. For example, much of the information in Facebook48 is available in such a
manner.

Note:

For more information on networks and graphs, we advise you reading the book entitled NETWORKS,
CROWDS, AND MARKETS: REASONING ABOUT A HIGHLY CONNECTED WORLD49published by Cambridge
University Press.

47
W INDOWS AZURE AD GRAPH DIFFERENTIAL QUERY: http://msdn.microsoft.com/en-us/library/windowsazure/jj836245.aspx
48
Facebook Graph API: http://developers.facebook.com/docs/api/
49
NETWORKS, CROWDS, AND MARKETS: REASONING ABOUT A HIGHLY CONNECTED W ORLD:
http://www.cambridge.org/gb/knowledge/isbn/item2705443


Developers can build on this simple direct URL based access to take advantage of the sophisticated
filtering and metadata operations that are available via Open Data Protocol (OData)50 version 3. OData
v3 is a very rich protocol, and not all of it is applicable to the directory – the directory supports a subset.
The directory publishes it schema and the attributes that can be used in filter expressions for scale and
performance reasons.
Built on standards such as HTTP, JSON and AtomPub, OData v3 is a Web protocol for unlocking and
sharing data — freeing it from silos that exist in some software applications today. The OData protocol
supports serialization in multiple popular formats, including JSON and Atom/XML. With OData,
developers are able to build cross-platform Web and mobile applications. It benefits from a strong
ecosystem of OData producers, consumers and libraries — several of them open source — including
Java, PHP, Drupal, Joomla, Node.js, Microsoft .NET, etc.
The OData protocol is released under the Microsoft Open Specification Promise51 to allow anyone to
freely interoperate with OData implementations. As of this writing, an OASIS Open Data Protocol
(OData) TC52has been proposed53 in order to define an open data protocol for sharing data and
exposing data models interoperable on the Web:
"To accomplish the goal of open data for the open Web, we have seen a push for support to
enable access to and use of data across platforms, applications and devices. Taking steps to
standardize OData through OASIS allows developers to act on the data in a more well-defined
way."
Jean Paoli, Président de Microsoft Open Technologies Inc.
We are convinced that developers will find the Directory Graph API straightforward to write applications
that integrate with Windows Azure AD and also potentially with other cloud solutions that operate with
graph interfaces.

Note:

For additional information, see the MSDN documentation54 of the Windows Azure Active Directory
Graph.

3.2.2 STS

As previously mentioned, Windows Azure AD provides support for (federated) authentication, single
sign-on (SSO), and authorization.
There are flavors of this support for browsers and for rich clients, and for identities hosted in the cloud
(Cloud ID) as well as federated identity providers (Federated ID). These capabilities are provided by
the Security Token Services (STS) in Windows Azure AD.
The Security Token Services (STS) in Windows Azure AD is a multi-tenant STS.

50
Open Data Protocol (OData) : http://www.odata.org/
51
Open Specification Promise: http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx
52
OASIS Open Data Protocol (OData) TC: https://www.oasis-open.org/committees/odata/charter.php
53
TECHNOLOGY LEADERS SUPPORT OASIS STANDARDS FOR OPEN DATA PROTOCOL: http://www.microsoft.com/en-
us/news/press/2012/may12/05-24ODataPR.aspx
54
W INDOWS AZURE ACTIVE DIRECTORY GRAPH: http://msdn.microsoft.com/en-us/library/hh974476


3.2.3 Core security model

The core security model consists of tenants realms. There is a 1:1 mapping between a STS tenant
realm and a directory tenant. The notion of a realm is a well-known concept in security; and the tenant
realm in the STS is the equivalent of a Kerberos realm or a Windows Server AD domain.
Tenant realms have a single, immutable, globally unique and rename safe security identifier and one or
more names verified DNS names that act as friendly aliases.
Tenant realms contain principals, representing users, services, etc. A principal is an object of the
corresponding type in the directory.
Principals have one or more names (such as user principal name for a user, or a multiple service
principal names for a service or application) and a security identifier, that is globally unique, immutable,
and not re-usable.
Principals can have one or more credentials (such as password, certificate, and keys) that can be used
to authenticate the principal. Alternatively the principal can be authenticated by an identifier from an
external identity provider (such as an immutable ID from a security token issued by the organization
on-premises identity provider). A principal that has this kind of mapping setup is also known as a
Federated principal, because the principal conceptually represents a user from a federated system
(such as a corporate user from the on-premises identity infrastructure).
Principals can both request and accept security tokens, typically from the tenant realm in which they
reside. Tenant realms are supported by the STS that authenticates requestors and makes authoritative
statements about those requestors, usually in the context of the target for the request.
These authoritative statements are packaged in security tokens and are signed by the STS.Security
tokens consist of a collection of claims, which are statements made about users, for example name, id,
email, group, role, etc. used for authentication and authorization decision purposes.Security tokens
typically follow a secure, standardized method of packaging claims for transport.
Tenant realms can setup federation with other realms, i.e.to an existing on-premises identity
infrastructure such as a corporate Active Directory.

3.2.4 Supported protocols

Usual on-premises authentication mechanisms such as Kerberos and NTLM no longer apply in a
general manner in the cloud space since cloud applications do not have most of the time connectivity
to a Windows Server AD domain controller (DC) and/or the VMs underneath aren‘t domain-joined at
all.
Windows Azure Virtual Machines and Windows Azure Virtual Network certainly provide such
capabilities with the ability to instantiate a standalone DC in the cloud or to leverage secure site-to-site
connectivity back to the on-premises infrastructure (see section § 2AD IN W INDOWS AZURE IS NOT
W INDOWS AZURE AD!).
However, this should be seen more specifically rather as IaaS ―migration‖ paths than the general
situation for the workloads in the cloud. It‘s all the more so with the mobility and the BYOD phenomena
where users will also often be themselves considered outside of the organization infrastructure
perimeter. Furthermore, cloud solutions can by nature encompass multiple security realms.
Consequently, Internet identity federation protocols constitute a much more scalable and efficient way
to implement authentication in such context. Moreover, Internet identity federation protocols can also
relevantly respond to other concerns like single sign-on (SSO) between cloud applications that reside
in the same of different clouds as well as claims issuancewith the processing and transforming
capability of security tokens in terms of type of trust, token format, semantics and (values of) claims for
―impedance adaptation‖.
Unsurprisingly, Windows Azure AD opts to such protocols and furthermore systematically aims at
being open standards based wherever possible.


Currently, this translates by the support for the following OASIS standards widely established and
adopted:
WS-Federation (WS-Fed)55 (from the OASIS Web Services Federation (WSFED) TC56),
WS-Trust57 (from theOASIS Web Services Secure Exchange (WS-SX) TC58),
Security Assertion Markup Language (SAML) 2.059 (from the OASIS Security Services (SAML)
TC60).
All the above protocols use SAML security tokens.
WS-Federation and WS-Trust (WS-*) protocols are presently the primary authentication protocols for
Windows Azure AD as they supports both respectively Web (browser) based clients and rich smart
clients.
As far as the latter is concerned, it is very popular in the Public Sector with government agencies as
well as with enterprises and educational institutions. It‘s a suite of specifications and, as such,
comprises a set of normative and non-normative documents. As part of them, the normative document
PROFILES FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.061defines the use cases
or the ―How-to‖ in regards to the use of SAML to solve specific problems of the extended enterprise,
and as an important number of profiles.
As of today, Windows Azure AD more specifically supports the Web Browser SSO profile and the
Enhanced Client or Proxy (ECP) profile. The Web Browser SSO profile supports 12 possible
deployment models. The one implemented here is the ―SP-initiated SSO: Redirect/POST Bindings‖ or
the HTTP-POST binding specified in the documentBINDINGS FOR THE OASIS SECURITY ASSERTION
MARKUP LANGUAGE (SAML) V2.062.
The ECP profile is an adaptation of the above SAML profile used for Browser SSO with the parts that
were designed around the limitations of a browser removed. In other words, in the ECP profile, the
user agent is assumed to be something more than a browser (or perhaps a browser with a plugin for
example).

55
WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2: http://docs.oasis-open.org/wsfed/federation/v1.2/ws-
federation.pdf
56
OASIS Web Services Federation (WSFED) TC: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed
57
WS-TRUST VERSION 1.3: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
58
OASIS Web Services Secure Exchange (WS-SX) TC: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-
sx
59
SECURITY ASSERTION MARKUP LANGUAGE (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996
60
OASIS Security Services (SAML) TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
61
PROFILES FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis-
open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
62
BINDINGS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis-
open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf


Windows Azure AD also provides a protocol support for IETF OAUTH 2.063(from the IETF OAUTH WG64),
whichis gaining popularity in the Internet as an authorization protocol for accessing information. This is
the primarily protocol for authorization and delegated authentication (see blog post OAUTH 2.0 AND
SIGN-IN65).
Using OAuth2, an application can gain access (with consent from the resource owner – which could be
the end user or the administrator user) to impersonate the user, or users in his organization to access
the resource.
The OAuth2 protocol uses JSON Web Token (JWT)66. JWT is a compact token format also defined by
the IETF OAuth WG that is especially apt for REST-based development. JWT use is growing, and
products supporting the format are increasingly common in the industry.
Along with OAuth2, Windows Azure AD provides a model for representing applications as service
principals in the directory (see section § 6.2.1PROVISION THE APPLICATION IN YOUR W INDOWS AZURE AD
DIRECTORY TENANT). An application can then make an access in its own security context, or act as a
user to other applications, subject to constraints.
Future versions will likely introduce the support for additional standards such as OpenID Connect67.
OpenID Connect is a suite of lightweight specifications that provide a framework for identity
interactions via REST like APIs. It is based on OAuth2, and JWT is also one of the basic components
of it.

3.2.5 A deeper look at the structure of the Windows Azure AD STS

As of today, the Windows Azure AD STS is implemented by a combination of two STS:
1. The (core STS of the) Windows Azure AD sign-in service when the service was originally
introduced in 2011;
2. And an applicative STS that derives from the Windows Azure Access Control Service (ACS)
and that was introduced in June 2012 with the Web SSO support for cloud and SaaS
applications.

63
RFC 6749 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK: http://tools.ietf.org/html/rfc6749
64
IETF OAuth WG :http://tools.ietf.org/wg/oauth/
65
OAUTH 2.0 AND SIGN-IN: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx
66
JSON Web Token (JWT): http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05
67
OpenID Connect: http://openid.net/connect/


Important note:

The current implementation of the Security Token Services (STS) in Windows Azure AD will evolve in
the future but, from a logical perspective, the functionalities described hereafter will remain or be
further extended to support more protocols and to embrace additional scenarios.

In general terms for (the intent of) this paper, the (core STS of the) Windows Azure AD sign-in service
handles the user authentication step, i.e. username/password, and the applicative STS handles the
policy and claims generation steps.
However, (cloud) application/service authentication is handled directly by the applicative STS as its
name indicates. The applicative STS acts as a federation provider, which trusts a single authority: the
Windows Azure AD sign-in service, which, in turns, can federate with on-premises identity provider.
Albeit, as of today, you cannot directly trust any identity provider other than Windows Azure AD itself at
the applicative STS level,you can leverage the Windows Azure AD Access Control serviceif the
application/service authentication needs to trust other federated identity provider.
In such case, federated identity providers can be an enterprise identity provider (such as an on-
premises AD), or a social identity provider such as Microsoft Account, Facebook,Yahoo!, etc. This
scenario is more specifically explored in section § 7BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS
AZURE AD ACCESS CONTROL.
From a design perspective, this applicative STS has a tenant in it for each customer, each of these can
be thought of as a logical realm, one for each tenant. There is a 1:1 correspondence between a
directory tenant in the Windows Azure AD core directory and a tenant in the applicative STS.
The applicative STS exposes a single common global URL for all tenants where tokens can be
requested, in a similar fashion to the Windows Azure AD sign-in service. The tenant identifier is part of
the various security protocols to allow this:
https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/v2/<security protocol>
Such as:
https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/v2/wsfederation for the
OASIS WS-Federation protocol (more in section § 3.2.5.2EXPOSED APPLICATIVE STS PUBLIC endpoints).


The global URL variant of the applicative STS uses the same signing key for all the tenants, but varies
the issuer name in the security tokens to represent each tenant. This is an optimization for:
Scale: cloud applicationsand services do not need to trust many millions of different signing
keys;
Usability:cloud applications and services do not need to construct tenant specific URLs;
Discovery: there is a single discovery endpoint for federation metadata about an individual
tenant. As for the security protocol, The tenant identifier is part of the global URL to allow this:
https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/FederationMetadata/2007-
06/FederationMetadata.xml
The applicative STS synchronizes the principal and group membership information in the Windows
Azure AD core directory for the purposes of token issuance.The (core STS of the) Windows Azure AD
sign-in service is the authoritative store for organizations and security principals. The applicative STS
knows the keys corresponding to the security principals allowing it to authenticate those principals.
group membership information can be included in security tokens reducing friction when an
application/service is performing authorization.

3.2.5.1 Exposed sign-in servicepublic endpoints

The (core STS of the) Windows Azure AD sign-in service currently exposes several endpoints:

It indeed exposes two metadata endpoints to federate your Windows Azure AD domain(s) with your
on-premises identity infrastructure:
1. One for WS-* based federation exposed at the following URL:
https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml.
The general syntax and semantics of these metadata are defined in the OASIS W EB SERVICES
FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.268.It covers the configuration data
(endpoint URLs, key material for verifying signatures, etc.) to establish trusts between WS-*
entities.
2. One for SAML 2.0 based federation exposed at the following URL:
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

68
OASIS WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2: http://docs.oasis-
open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.pdf


The general syntax and semantics of metadata are defined in the METADATA FOR THE OASIS
SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.069. It covers the configuration data
(endpoint URLs, key material for verifying signatures, etc.) to establish trusts between SAML
2.0 entities.
These metadata globally define 2 public endpoints for the (core STS of the) Windows Azure AD sign-in
service for the interaction with organization‘s on-premisesidentity infrastructure:
1. One multipurpose endpoint located at: https://login.microsoftonline.com/login.srf. This endpoint
is indeed:
a. A passive endpoint for Web (browser) based clients on the WS-Federation protocol.
b. A passive endpoint for Web (browser) based clients on the SAML 2.0 Web Browser SSO
profile and the HTTP-POST binding.
c. An active endpoint based on the Enhanced Client or Proxy (ECP) profile along with the
HTTP-POST-SimpleSign binding.
2. Another onelocated athttps://login.microsoftonline.com/extSTS.srf. This is specifically a WS-
Trust-based active endpoint for smart clients.
The former endpoint is the one that renders the credential user interface of the Windows Azure AD
sign-in serviceand that triggers a home realm discovery (HRD) process for federated identities as
previously illustrated.

3.2.5.2 Exposed applicative STS public endpoints

As mentioned above, the applicative STS metadata is exposed with the global URL in order to
integrate your Windows Azure AD directory tenant in to your cloud applications or your SaaS
subscriptions:
https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/FederationMetadata/2007-
For example, the Windows Azure AD testing directory tenant idmgt.onmicrosoft.com (6d13453f-5d87-
44d3-b7f8-29bbca5ac3df) corresponds to:
https://accounts.accesscontrol.windows.net/idmgt.onmicrosoft.com/FederationMetadata/2007-
-or-
https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8-
29bbca5ac3df/FederationMetadata/2007-06/FederationMetadata.xml
These metadata follow the general syntax and semantics of metadataare defined in the OASIS W EB
SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.270.
These metadata globally define 2 public endpoints for the applicative STS for the Web SSO with cloud
applications:
A passive endpoint for Web clients (browser) based on the WS-Federation protocol, as follows:
https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/v2/wsfederation

69
METADATA FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis-
open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
70
OASIS WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2: http://docs.oasis-
open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.pdf


Active directory-from-on-premises-to-the-cloud

Active directory-from-on-premises-to-the-cloud

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Active directory-from-on-premises-to-the-cloud

Similar to Active directory-from-on-premises-to-the-cloud (20)

More from David J Rosenthal

More from David J Rosenthal (20)

Recently uploaded

Recently uploaded (20)

Active directory-from-on-premises-to-the-cloud