1. Active Directory from on-premises tothe cloudMicrosoft
FrancePublished: January 2013Version:1.0Author: Philippe Beraud
(Microsoft France)Contributors/Reviewers:Arnaud Jumelet (Microsoft
France), Christophe Leroux (MicrosoftCorporation), Philippe Maurent
(Microsoft Corporation)Copyright 2013Microsoft Corporation. All
rights reserved.AbstractIdentity management, provisioning, role
management, and authentication are key services bothon-premises and
through the (hybrid) cloud. With the Bring Your Own Apps (BYOA) for
the cloudand Software as a Service (SaaS) applications, the desire
to better collaborate a la Facebookwith the social enterprise, the
need to support and integrate with social networks, which lead toa
Bring Your Own Identity (BYOI) trend, identity becomes a service
where identity bridges in thecloud talk to on-premises directories
or the directories themselves move and/or are located in
thecloud.Active Directory (AD) is a Microsoft brand for identity
related capabilities. In the on-premisesworld, Windows Server AD
provides a set of identity capabilities and services and is
hugelypopular (88% of Fortune 1000 and 95% of enterprises use AD).
Windows Azure AD is ADreimagined for the cloud, designed to solve
for you the new identity and access challenges thatcome with the
shift to a cloud-centric, multi-tenant world.Windows Azure AD can
be truly seen as an IdentityManagementasaService (IDMaaS)
cloudmulti-tenant service. This goes far beyond taking AD and
simply running it within a VM inWindows Azure.This document is
intended for IT professionals, system architects, and developers
who areinterested 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.
2. This document is provided as-is. Information and views
expressed in this document, including URL andother 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
orconnection is intended or should be inferred.This document does
not provide you with any legal rights to any intellectual property
in any Microsoftproduct. You may copy and use this document for
your internal, reference purposes. You may modifythis document for
your internal, reference purposes. 2013 Microsoft Corporation. All
rights reserved.Microsoft, Active Directory, Internet Explorer, SQL
Server, Windows, Windows PowerShell, andWindows Server are
trademarks of the Microsoft group of companies. All other
trademarks are propertyof their respective owners
3. Content 1 INTRODUCTION
.............................................................................................................................
1 1.1OBJECTIVES OF THIS PAPER
....................................................................................................
2 1.2NON-OBJECTIVES OF THIS PAPER
............................................................................................
4 1.3ORGANIZATION OF THIS PAPER
................................................................................................
4 1.4ABOUT THE AUDIENCE
.............................................................................................................
5 2 AD IN WINDOWS AZURE IS NOT WINDOWS AZURE AD!
......................................................... 6 3 WHAT
IS WINDOWS AZURE AD?
................................................................................................
9 3.1TYPE OF IDENTITIES
..............................................................................................................13
3.2ANATOMY OF W INDOWS AZURE AD
.......................................................................................15
4 SYNCHRONIZE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-
PREMISES DIRECTORY
.......................................................................................................................31
4.1SYNCHRONIZE YOUR DIRECTORY TENANT WITH ACTIVE DIRECTORY
ON-PREMISES ...................32 4.2SYNCHRONIZE 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.1FEDERATE YOUR DIRECTORY TENANT WITH AN ON-PREMISES WS-* BASED
IDENTITY PROVIDER45 5.2FEDERATE 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.1LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS
SUBSCRIPTION .48 6.2LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY
TENANT WITH YOUR LOB APPLICATION IN THE CLOUD 51 6.3LEVERAGE YOUR
CUSTOMERS 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
.......................................................................................................................75Active
Directory from on-premises to the cloud ii
4. 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 OwnIdentity (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. 12013 PLANNING GUIDE:
IDENTITY AND PRIVACY: http://www.gartner.com/id=2221415 2IDENTITY
MANAGEMENT AS A SERVICE: http://www.identityblog.com/?p=1205Active
Directory from on-premises to the cloud 1
5. 1.1 Objectives of this paperActive 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 identitycapabilities 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 theWindows
Azure platform, it becomes possible to deploy virtual machines (VM)
that host AD domaincontroller.Whilst such an approach could be more
than appropriate for specific workloads on IaaS platforms likea
SharePoint environment, the Microsoft vision for the cloud consists
in recreating a similar identityservice, 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 4posts REIMAGING ACTIVE DIRECTORY FOR THE
SOCIAL ENTERPRISE (PART 1) , (PART 2) ), designed tosolve 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 inthe cloud with high
scale, high availability, and integrated disaster recovery. This
goes far beyondtaking AD and simply running it within a VM in a
hosted environment such as the IaaS capability ofWindows 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 OAuth2for mobile and
consumer scenarios, Windows Azure AD typically provides identity
and accesscapabilities 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 relieson it for its identity
infrastructure,Mobile applications (with or without a back-end in
the cloud like the one proposed through theWindows Azure Mobile
Services6),Etc.Windows Azure AD utilizes the enterprise-grade
quality and proven capabilities of Windows Server ADon-premises, so
you can bring your applications to the cloud easily. It offers
capabilities that can beleveraged 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 totake advantage of your on-premises
existing investment, to fully outsource to the cloud your
usersmanagement and anything in between.By connecting your existing
on-premises identity infrastructure to Windows Azure AD, you can
managea hybrid environment that provides unified authentication and
access management for both cloud andon-premises services and
servers, eliminating the need to maintain new, independent cloud
directories3 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.aspx4
REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART
2):http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining-active-directory-for-the-social-enterprise-part-2.aspx5
Microsoft Office 365 provides secure anywhere access to
professional email, shared calendars, instant messaging (IM),
videoconferencing, and document collaboration, see
http://office365.microsoft.com/6Windows Azure Mobile Services:
http://www.windowsazure.com/en-us/home/features/mobile-services/2
Active Directory from on-premises to the cloud
6. 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 SaaSsubscriptions (provided that
they support the integration with Windows Azure AD as it is thecase
today for the Microsoft Online Services such as Office 365). SSO is
the ability for a userto 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 simpleand seamless way for the
corporate users to connect to their resources running somewhere
inthe cloud7.Simple interoperability with your existing on-premises
identity infrastructure based on WindowsServer Active Directory
(AD) (or non-AD sources) through federation (and
synchronization).Federation is the ability for Windows Azure AD and
your existing on-premisesidentityinfrastructure to work
togetherdelivering a federated SSO experience for corporate users
whilekeeping user passwords on-premises and related policies
on-premises.(Federation also givesthe 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.0protocols, you can indeed quickly extend your existing
on-premises directory authentication toyour cloud applications
through Windows Azure AD. By using your existing
on-premisesidentityinfrastructure as the authoritative identity
provider, users are seamlessly authenticated to yourcloud
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. 7The
best user experience for corporate users on the corporate network
is provided with domain-joined machines. 8WINDOWS 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.aspxActive
Directory from on-premises to the cloud3
7. Furthermore, with Windows Azure AD Access Control (formerly
Windows Azure Access ControlServices or ACS), a unified federated
SSO experience in the cloud can now be planned. With theongoing
dissolution of the boundary between internal or at least
organizational identities and externalor social identities, it
indeed has out-of-the-box support for popular web identity
providers includingMicrosoft Account (formerly known as Windows
Live ID), Google, Yahoo!, and Facebook and anyOpen ID identity
providers. The interaction between your Windows Azure AD directory
tenant and yournamespaces 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:
WindowsAzure AD Rights Management.This paper can be seen a starting
point for anyone challenged with identity, provisioning, federation
orcloud based authentication.Special thanks toAlex Simons, Edward
Wu,John Shewchuk,Kim Cameron, Stuart Kwan, VittorioBertocci, and
Yannick Kristoficfor providing valuable content on thesetopics.1.2
Non-objectives of this paperThis document doesnt 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 AzureAD, and as such, it doesnt provides neither
in-depth description nor detailed step-by-step instructionson how
to implement a specific covered feature or capability. Where
necessary, it instead refers tomore 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 ofWindows Azure AD and
Microsoft Office 365. It indeed completes the following whitepapers
alreadyavailable 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
paperTo cover the aforementioned objectives, this document is
organized by themes which are covered inthe 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=2897110MICROSOFT
OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.0:
http://www.microsoft.com/en-us/download/details.aspx?id=3546411INFORMATION
PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH WINDOWS
AZURE AD RIGHTS
MANAGEMENT:http://www.microsoft.com/en-us/download/details.aspx?id=3476812
INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE
ONLINE WITH AD RMS:
http://www.microsoft.com/en-us/download/details.aspx?id=301394Active
Directory from on-premises to the cloud
8. 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
CLOUDAPPLICATIONS;BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS
AZURE AD ACCESS CONTROL;ENSURE INFORMATION PROTECTION AND CONTROL
(IPC) WITH W INDOWS AZURE AD RIGHTSMANAGEMENT. 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 doesnt replace the other.Active
Directory from on-premises to the cloud 5
9. 2 AD in Windows Azure is NOT Windows Azure AD!Microsoft
announced13 in June 2012 the release of Windows Azure Virtual
Machines14, an IaaS offeringin 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, attheir 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, thisincludes a persistent operating system (OS) disk,
possibly some persistent data disks, andinternal/external
networking glue/connectivity to hold it all together. With these
infrastructureingredients, itenables to create a platform where
customers and partners can deploy existingapplications 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 andforth between
on-premises and the cloud. This enables you to migrateyour existing
VM, to bring yourown customized Windows Server or Linux images,
etc. As a common virtualization file format, VHDhas been adopted by
hundreds of vendors and is a freely available specification15
covered under theMicrosoft Open Specification Promise (OSP) 16. The
new version VHDX17 is also available as a freespecification covered
under the OSP.While migration is a simple goal for any IaaS
offering, the ultimate objective consists in beingable to run the
exact same on-premises applications and infrastructure or part of
them in thecloud and thus enabling onboarding and offboarding of
workloads in order to improve theagility of the organization, i.e.
its ability to capitalize on new opportunities and respond
tochanges in business demands.Such a process might involve
transferring an entire multi-VM workload, which may require
virtualnetworks for hybrid connectivity to an on-premises
deployment.(This can be seen as a cross-premisesdeployment.) This
is where Windows Azure Virtual Networks comes into play.Windows
Azure Virtual Network, another capability of the Windows Azure IaaS
offering, lets youprovision and manage virtual networks (VNET) in
Windows Azure. A VNET is the ability for theadministrator to create
a logical boundary and place into it VMs. VNET also provides the
capability ofconnecting Windows Azure Cloud Services18 (web roles
and worker roles) that are in the same affinitygroup 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,13ANNOUNCING 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.aspx14
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=13717116 Open
Specification Promise:
http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx17
VHDX FORMAT SPECIFICATION V1.00:
http://www.microsoft.com/en-us/download/details.aspx?id=3475018
Windows Azure Cloud Services:
http://www.windowsazure.com/en-us/home/scenarios/cloud-services/6Active
Directory from on-premises to the cloud
10. 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 organizations corporate VPN gateway and
Windows Azure, and then to connect the organizations on-premises
corporate network to the organizations 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 organizations 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 19INSTALL A NEW ACTIVE DIRECTORY FOREST IN W INDOWS AZURE:
http://www.windowsazure.com/en-
us/manage/services/networking/active-directory-forest/ 20GUIDELINES
FOR DEPLOYING W INDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE
VIRTUAL MACHINES:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090Active
Directory from on-premises to the cloud7
11. highlights the requirements for deploying AD in a hybrid
scenario in which Windows Server AD is partlydeployed on-premises
and partly deployed on VMs in Windows Azure.Whatever the scenario
is, and as you understand, AD in Windows Azure simply meansWindows
Server AD running in your VMs in your Windows Azure tenant for the
bestcompatibility with existing applications and for hybrid
applications.AD in Windows Azure is NOT Windows Azure AD, a
REST-based service that provides identitymanagement 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
distributedhypermedia systems such as the World Wide Web. The term
Representational State Transfer wasintroduced and defined in 2000
by Roy Fielding in his doctoral dissertation. Fielding is one of
theprincipal 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
implementedusing 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 orYAML 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, lets
considerwhat Windows Azure AD is all about in the next section.21
REST :
http://en.wikipedia.org/wiki/Representational_State_Transfer8Active
Directory from on-premises to the cloud
12. 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 Azurebased 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 organizations 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 organizations Active Directory.
Because it is your organizations 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 isnt 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
Microsofts 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. 22REIMAGING 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.aspxActive
Directory from on-premises to the cloud9
13. 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. Its also possible to obtain a
standalone directory tenant through theprovisioning system.If you
dont already have a tenant, you can set up your own custom Windows
Azure AD standalone directory tenantfor free aspart of thedeveloper
preview programbyfollowingthe
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. 23Preview of the Windows Azure AD
Management Portal:
https://activedirectory.windowsazure.com/10Active Directory from
on-premises to the cloud
14. 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 25Windows Azure Active Directory
community forum:
http://social.msdn.microsoft.com/Forums/en-US/WindowsAzureAD/
26Windows Azure blog: http://blogs.msdn.com/b/windowsazure/
27ANNOUNCING 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
29DIRECTORY GRAPH API: DRILL DOWN:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA322Active
Directory from on-premises to the cloud11
15. 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
interfaceto 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 groupMembership, 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 AccessControl namespaces (see section 7BRING YOUR
OWN IDENTITY (BYOI) WITH W INDOWS AZUREAD 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.aspx12
Active Directory from on-premises to the cloud
16. 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.Its 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 users 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, users
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 organizations 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
identitiesare authenticated using traditional challenge/response,
where users type in their user nameand 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 andthe services and applications in the cloud that
leverage Windows Azure AD and potentially onefor
accessingon-premises services. Consequently, users are prompted for
credentials evenwhen logged into their on-premises infrastructure
(AD or non-AD sources) when accessingWindows Azure AD itself and
the services and applications in the cloud that leverage
WindowsAzure AD.User experience with federated identities: Users
sign in with corporate ID for access toonline and corporate
services. In other words, they are authenticated transparently
using theon-premises identity infrastructure when accessing Windows
Azure AD itself and the servicesand applications in the cloud that
leverage Windows Azure AD. Authentication happens on-Active
Directory from on-premises to the cloud13
17. premises against the organizations 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 Webbrowsers.
Other clients that do not have the capability to prompt users for
strong authenticationcredentials can therefore not be supported.
Strong authentication must only be applied to the passivefederation
endpoints on on-premises identity provider servers, as other
clients will otherwise not beable to connect.Administrator
experience with cloud identities:Organizations administrators
managethepassword policy both in the cloud and on-premises. The
cloud identities password policy isstored 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 perthe policy for both. Finally, there is no MFA
integration.Note:With the recent acquisition of PhoneFactor33 in
October 2012, MFA support could be introduced inWindows Azure AD in
the future. As Bharat Shah, corporate vice president, Server and
Tools Divisionfor Microsoft, said, The acquisition of PhoneFactor
will help Microsoft bring effective and easy-to-usemultifactor
authentication to our cloud services and on-premises
applications.By leveraging a device nearly every user already has a
phone PhoneFactor enables rapiddeployment of MFA across a wide
range of applications. It already works with many Microsoftproducts
and services, including Outlook Web Access and Internet Information
Services, andinteroperates with Active DirectoryAdministrator
experience with federated identities:Organizations
administratorsmanagethe password policy on-premises only and hence
do not need to separately worryabout password reset for federated
identities. The organizations identity infrastructure storesand
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, lets see how Windows Azure AD supports
both cloud identities and federated identities. 33MICROSOFT
ACQUIRES PHONEFACTOR:
http://www.microsoft.com/en-us/news/Press/2012/Oct12/10-04MFAPR.aspx14Active
Directory from on-premises to the cloud
18. 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
notsomething 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. Eachdirectory context has an
immutable,globally unique, non-reusable GUID-valued identifier
acontext ID and contains a set of entities (or objects) and
association (or links) between theentities. Each object or link
belongs to exactly one context.Active Directory from on-premises to
the cloud 15
19. 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 as34 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 doesnt 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 34REIMAGING
ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 2):
http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining-active-directory-for-the-social-enterprise-part-2.aspx16
Active Directory from on-premises to the cloud
20. application maintains its information. One of the columns
of the table would be a key thatidentifies 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 capabilitysupported by the directory to
manage the lifecycle of the rows in its tables utilizing the
joinkey. 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
.onmicrosoft.comdomain chosen during registration, for
exampleidmgt.onmicrosoft.com. This is the default domain.When you
create a new user, the users 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 organizations 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 dont 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.Active Directory from
on-premises to the cloud 17
21. 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 WindowsAzure 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
MicrosoftOnlineServicesModuleforWindowsPowerShellisa 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
isdesigned for system/service administration and automation. It
uses administrative tasks calledcmdlets. Each cmdlet has required
and optional arguments, called parameters, that identify
whichobjects to act on or control how the cmdlet performs its task.
You can combine cmdlets in scripts toperform complex functions that
give you more control and help you automate the administration
ofWindows, applications and online services in the cloud. It has
become a common way to manage thelatest generation of Microsoft
products and services.For more information about Windows
PowerShell, please see the Windows PowerShell Web site37,
theWindows PowerShell online help38, and the Windows PowerShell
Weblog39Windows PowerShellSoftware Development Kit (SDK)40 that
includes a programmers 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, lets seehow to create custom
domains within a directory tenant with the cmdlets provided by this
module. 35Microsoft Online Services Module for Windows PowerShell
(32-bit version): http://go.microsoft.com/fwlink/?linkid=236345
36Microsoft Online Services Module for Windows PowerShell (64-bit
version): http://go.microsoft.com/fwlink/p/?linkid=236293 37Windows
PowerShell Web site: http://www.microsoft.com/powershell 38Windows
PowerShell online help:
http://technet.microsoft.com/en-us/library/bb978526.aspx 39Windows
PowerShell Weblog: http://blogs.msdn.com/powershell 40Windows
PowerShell SDK:
http://msdn2.microsoft.com/en-us/library/aa830112.aspx18Active
Directory from on-premises to the cloud
22. 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 43USE
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.aspxActive
Directory from on-premises to the cloud 19
23. 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, hesinvited 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 , 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.20Active Directory from
on-premises to the cloud
24. 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 tenants Graph endpoint is as follows:
https://graph.windows.net//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([email protected]),
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":
"[email protected]","Mail":
"[email protected]","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.
45graph.windows.net now replaces directory.windows.net 46W INDOWS
AZURE AD GRAPH COMMON QUERIES:
http://msdn.microsoft.com/en-us/library/windowsazure/jj126255.aspxActive
Directory from on-premises to the cloud 21
25. Continuing with the example above, you can see that it is
easy to access a users groups by using the URL:
https://graph.windows.net/demo.idmgt.archims.fr/Users([email protected])/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 whos the user principal name (UPN) is
[email protected]:"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 applications data
store. A differential query request URL is created by appending a
query string to a directory tenants Graph endpoint. For example, a
differential query request for a directory tenant with the
demo.idmgt.archims.fr domain name wouldbegin 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 CambridgeUniversity Press. 47W INDOWS AZURE AD
GRAPH DIFFERENTIAL QUERY:
http://msdn.microsoft.com/en-us/library/windowsazure/jj836245.aspx
48Facebook Graph API: http://developers.facebook.com/docs/api/
49NETWORKS, CROWDS, AND MARKETS: REASONING ABOUT A HIGHLY CONNECTED
W ORLD: http://www.cambridge.org/gb/knowledge/isbn/item270544322
Active Directory from on-premises to the cloud
26. 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, Prsident 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/ 51Open Specification Promise:
http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx
52OASIS 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 54W INDOWS AZURE ACTIVE
DIRECTORY GRAPH:
http://msdn.microsoft.com/en-us/library/hh974476Active Directory
from on-premises to the cloud23
27. 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 arent
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. Its 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.24 Active Directory from on-premises to the cloud
28. Currently, this translates by the support for the following
OASIS standards widely established andadopted: 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. Its 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 56OASIS 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
61PROFILES 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 62BINDINGS FOR
THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0:
http://docs.oasis-
open.org/security/saml/v2.0/saml-bindings-2.0-os.pdfActive
Directory from on-premises to the cloud25
29. 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. 63RFC 6749 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK:
http://tools.ietf.org/html/rfc6749 64IETF OAuth WG
:http://tools.ietf.org/wg/oauth/ 65OAUTH 2.0 AND SIGN-IN:
http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx
66JSON Web Token (JWT):
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05
67OpenID Connect: http://openid.net/connect/26Active Directory from
on-premises to the cloud
30. 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//v2/ Such as:
https://accounts.accesscontrol.windows.net//v2/wsfederation for the
OASIS WS-Federation protocol (more in section 3.2.5.2EXPOSED
APPLICATIVE STS PUBLIC endpoints).Active Directory from on-premises
to the cloud27
31. 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 signingkeys;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 individualtenant. As for the security protocol, The tenant
identifier is part of the global URL to allow this:
https://accounts.accesscontrol.windows.net//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 SERVICESFEDERATION 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.pdf28Active
Directory from on-premises to the cloud