• Share
  • Email
  • Embed
  • Like
  • Private Content
Active directory-from-on-premises-to-the-cloud
 

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

on

  • 2,203 views

 

Statistics

Views

Total Views
2,203
Views on SlideShare
2,203
Embed Views
0

Actions

Likes
0
Downloads
48
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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.
    • 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
    • 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 .......................................................................................................................75Active 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=1205Active 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 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.aspx 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.aspxActive Directory from on-premises to the cloud 3
    • 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- us/download/details.aspx?id=35464 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- us/download/details.aspx?id=301394 Active Directory from on-premises to the cloud
    • 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.Active Directory from on-premises to the cloud 5
    • 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/6 Active Directory from on-premises to the cloud
    • 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/jj156090Active Directory from on-premises to the cloud 7
    • 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_Transfer8 Active Directory from on-premises to the cloud
    • 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 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.aspxActive Directory from on-premises to the cloud 9
    • 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/10 Active Directory from on-premises to the cloud
    • 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/SIA322Active Directory from on-premises to the cloud 11
    • 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.aspx12 Active Directory from on-premises to the cloud
    • 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-Active Directory from on-premises to the cloud 13
    • 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.aspx14 Active Directory from on-premises to the cloud
    • 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.Active Directory from on-premises to the cloud 15
    • 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 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.aspx16 Active Directory from on-premises to the cloud
    • 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.Active Directory from on-premises to the cloud 17
    • 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.aspx18 Active Directory from on-premises to the cloud
    • 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.aspxActive Directory from on-premises to the cloud 19
    • 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.20 Active Directory from on-premises to the cloud
    • 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.aspxActive Directory from on-premises to the cloud 21
    • 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/item270544322 Active Directory from on-premises to the cloud
    • 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/hh974476Active Directory from on-premises to the cloud 23
    • 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.24 Active Directory from on-premises to the cloud
    • 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.pdfActive Directory from on-premises to the cloud 25
    • 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/26 Active Directory from on-premises to the cloud
    • 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).Active Directory from on-premises to the cloud 27
    • 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.pdf28 Active Directory from on-premises to the cloud
    • 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- 06/FederationMetadata.xml 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- 06/FederationMetadata.xml -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.pdfActive Directory from on-premises to the cloud 29
    • For our Windows Azure AD testing directory tenant idmgt.onmicrosoft.com, this corresponds to: https://accounts.accesscontrol.windows.net/idmgt.onmicrosoft.com/v2/wsfederation -or- https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8- 29bbca5ac3df/v2/wsfederation Another passive endpoint for Web clients (browser) based on the SAML 2.0 Web Browser SSO profile and the HTTP-POST binding, as follows: https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/v2/saml2 For our Windows Azure AD testing directory tenant idmgt.onmicrosoft.com, this corresponds to: https://accounts.accesscontrol.windows.net/idmgt.onmicrosoft.com/v2/saml2 -or- https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8-29bbca5ac3df/v2/saml2 Finally, the applicative STS exposes an OAuth2 public endpoint to enable cloud applications that have a service principal declared in the targeted Windows Azure AD directory tenant (and consequently in the related tenant of the applicative STS) to obtain a bearer access token to further use with the Windows Azure Directory Graph API against the targeted Windows Azure AD directory tenant. The OAuth2 public endpoint corresponds to: https://accounts.accesscontrol.windows.net/tokens/oauth/2 The target resource for the POST request to this endpoint is: 00000002-0000-0000-c000-000000000000/directory.windows.net@<tenant ID> Where00000002-0000-0000-c000-000000000000 is the service principal ID for the Windows Azure Directory Graph service principal. This service principal ID is a universal (reserved) identifier for all Windows Azure AD directory tenants (see section § 6.2.3QUERY YOURW INDOWS AZURE AD DIRECTORY TENANT DATA USING THE W INDOWS AZURE AD GRAPH API for additional information). The following diagram synthetizes the above endpoints:30 Active Directory from on-premises to the cloud
    • 4 Synchronize your Windows Azure AD directory tenant with your on-premises directory Generally speaking, identity provisioning and synchronization is a complex space. This has generated in the past some burden and hassle on-premises for the organizations to keep in sync all their identities silos resulting from the deployment of various LOB solutions. Directory synchronization is the first integration capability offered by Windows Azure AD. As an IDaaS offering, Windows Azure AD provides, as anyone can imagine, many options, to support a myriad of customer configurations – from the very simple to the most complex one. (Regardless of your own specific situation, we strongly recommend leading with ―simple‖ this space in a hybrid manner with the cloud.) Windows Azure AD indeed enables the support of on-premises Windows Server Active Directory mono and multi-forest environments as well as non-Active Directory directories environments. Furthermore, it provides multiple technical choices to sustain the identity provisioning and synchronization: Microsoft Online Directory Synchronization Tool (DirSync), Forefront Identity Manager (FIM) 2010 (R2) Sync Engine with the Windows Azure AD Connector, Microsoft Online Services Module for Windows PowerShell (see section § 3.2.1.3MANAGEMENT SURFACE), Windows Azure Active Directory Graph API (see section § 3.2.1.4PROGRAMMING INTERFACE). This chapter consequently aims at describing the main situations, and in those contexts, providing recommendations and guidance for the selection of the right directory provisioning and/or synchronization tools, when working with Windows Azure AD. For that purpose, this also includes when required specifics considerations for Office 365 customers. Directory provisioning refers to the creation and management of directory entries. In the context of Windows Azure AD, directory provisioning is different from directory synchronization, in that objects that are provisioned are mastered in the Windows Azure AD and can be edited online. Directory provisioning can be performed through Windows Azure AD management or programming interfaces such as the (preview of the) Windows Azure AD Management portal, the bulk upload using .csv files, the Microsoft Online Services Module for Windows PowerShell cmdlets or the Windows Azure Active Directory Graph API. While some form of directory synchronization can be implemented using these interfaces, this remains different from Windows Azure AD directory synchronization where objects are mastered on-premises and the online object is a copy of the on-premises object and cannot be edited online. Note: Third party synchronization tools are not explicitly covered, as they typically fall under the above Microsoft Online Services Module or the Windows Azure Active Directory Graph API categories.Active Directory from on-premises to the cloud 31
    • 4.1 Synchronize your directory tenant with Active Directory on- premises 4.1.1 Consider first the DirSync tool In order to stay with the aforementioned simplicity principle, the preferred option is naturally the Microsoft Online Services Directory Synchronization Tool (DirSync)71. For a single Active Directory forest, it used to replicate Windows Server AD user accounts (and other Active Directory objects) in your Windows Azure AD directory tenant, whether it is a standalone one (as enabled by the developer preview) or the directory of, for instance, your Office 365 subscription. Unlike manually created accounts, accounts created by the DirSync tool are fully populated with user account information from Active Directory. The KB article 2256198LIST OF ATTRIBUTES THAT ARE SYNCHRONIZED TO OFFICE 365 AND ATTRIBUTES THAT ARE WRITTEN BACK TO THE ON-PREMISES ACTIVE DIRECTORY DOMAIN SERVICES72 provides an exhaustive list of the attributes that are synced with the DirSync tool. It enables service administrators keeping Windows Azure AD objects updated with changes made in the on-premises Windows Server AD. It provides the best experience for most customers.Setting up directory synchronization for domain(s) within your Windows Azure AD directory tenant with the DirSync tool requires to conduct a few steps as outlined at the following URL: https://activedirectory.windowsazure.com/DirSync/DirectorySynchronization.aspx. 71 INSTALL AND UPGRADE THE MICROSOFT ONLINE SERVICES DIRECTORY SYNCHRONIZATION TOOL: http://onlinehelp.microsoft.com/en- us/office365-enterprises/ff652545.aspx 72 2256198 LIST OF ATTRIBUTES THAT ARE SYNCHRONIZED TO OFFICE 365 AND ATTRIBUTES THAT ARE WRITTEN BACK TO THE ON- PREMISES ACTIVE DIRECTORY DOMAIN SERVICES:http://support.microsoft.com/kb/225619832 Active Directory from on-premises to the cloud
    • The first step consists in activating directory synchronization, which should be considered a long-term commitment to coexistence scenarios between your on-premises Windows Server AD and your Windows Azure AD directory tenant in the cloud. After directory synchronization has been activated, synchronized objects are mastered on-premises and can only be edited using on-premises applications. The online objects are a copy of the on-premises objects with which they‘re synced. Thisfirst operation results in enabling the DirSync Web Service endpoint (known as AWS). This endpoint provides support for batch methods as well as proprietary sync features.It is thus only available to the DirSync tool (and to the Windows Azure AD Connector for FIM 2010, which is discussed later in the next section). This interface is not available to support custom synchronization solutions.Active Directory from on-premises to the cloud 33
    • After ensuring that both your on-premises and cloud environments are ready for directory synchronization (steps two and three) notably via the Microsoft Deployment Readiness Tool73, you can download the DirSync tool installation package (dirsync.exe) and install it. This is the fourth step. Directory synchronization is not something that is new for Windows Azure AD. The DirSync tool is built on top of Microsoft Forefront Identity Manager (FIM) 2010. The configuration of directory synchronization has been simplified for the Windows Azure AD environment. There is no manual configuration that you need to be concerned with, everything being configured via wizards. This said some customers may have in this context a requirement to scope what objects are synchronized from their on-premises Active Directory to theirWindows Azure AD directory tenant.Common requests in this area are typically: The ability to exclude an Active Directory domain from the scope, The ability to exclude an organizational unit (OU) from the scope, The ability to exclude specific objects from the scope, based on attribute-level filtering. Directory synchronization scoping is something supported through the DirSync tool at the following levels: Domain-based: You can use this filtering type to manage the properties of the sourceAD management agent (connector) in the DirSync tool. This type enables you to select which domains are allowed to synchronize to the cloud. Organizational unit–based: You can use this filtering type to manage the properties of the sourceAD management agent (connector)in the DirSync tool. This filtering type enables you to select which OUs are allowed to synchronize to the cloud. User attribute–based: You can use this filtering method to specify attribute-based filters for user objects (and user objects only). This enables you to control which objects should not be synchronized to the cloud. Important note: Preventing the replication of certain attributes to Windows Azure AD is not supported today. All attributes must be part of the scope. Please refer to the related instructions to completely setup the directory synchronization for your domain(s) within your Windows Azure AD directory tenant.For additional details, please refer to CONFIGURE DIRECTORY SYNCHRONIZATION74in the Windows Azure AD online documentation. 73 Microsoft Deployment Readiness Tool: http://go.microsoft.com/fwlink/?linkid=235650 74 CONFIGURE DIRECTORY SYNCHRONIZATION: http://technet.microsoft.com/en-us/library/hh967629.aspx34 Active Directory from on-premises to the cloud
    • As previously mentioned, the initial version of the DirSync tool was intended for an on-premises Active Directory mono-forest. However, many customers are operating with more than one on-premises Active Directory forest for a variety of reasons, such as: Multiple account forests, where user accounts exist in multiple Active Directory forests; Account and resource forests, where the Exchange organization is typically hosted in a resource forest model. Through the above, the following scenarios can also be considered: Multiple account forests, with no on-premises Exchange; Single account forests, single exchange resource forest; Multiple account forest, single exchange resource forest. Multi-forest topologies will be supported with Windows Azure AD for customers that meet certain prerequisites, allowing synchronizing from multiple forests. For that purpose, a new version of the DirSync tool is soon going to be available, to support ―simple‖ multi-forest configurations. Only limited ―simple‖ multi-forest scenarios can be supported, as categorizedby the table hereafter. Criteria Simple Complex Do you move objects between on-premises AD forests? No Yes Do you have security groups that contain objects from more than one on- No Yes premises AD forest? Do you have duplicated objects across on-premises AD forests, i.e. either the No Yes same object appears in multiple forests, or some subset of attributes are mastered for a user object in one forest, another subset are mastered in another forest? Do you have an Exchange resource forest, or require an Exchange hybrid No Yes deployment, aka "rich coexistence"?Active Directory from on-premises to the cloud 35
    • Important note: Users in each on-premises AD forest require a different User Principal Name (UPN)suffix. For example @forestA.com in forest A and @forestB.com in forest B. Shared UPN namespaces across forest are not supported by design, i.e. you cannot provide a single UPN namespace for all users across multiple AD forests. The table below provides an overview of some of the limitations of the ―simple‖ multi-forest DirSync tool: No support for multi-forest Exchange hybrid deployment features; No support for scenarios where users have some attributes mastered in one AD forest, and other attributes mastered in another (such as in the account/resource forest model); No support for user moves between on-premises forests. This would indeed result in user being deleted in the cloud THEN recreated; will result in mailbox deletion. 4.1.2 When the Windows Azure AD Connector for FIM 2010 should be considered For an Active Directory multi-forest environment, the FIM 2010 (R2) Sync Engine and theWindows Azure AD Connector for FIM 2010 (formerly known as the Office 365 Connector for FIM 2010) can cover scenarios that are impacted by the limitations of the ―simple‖ multi-forest DirSync tool. The Windows Azure AD Connector is only recommended for scenarios where the DirSync tool is not appropriate(such as a “complex” multi-forest Active Directory environment). Generally speaking, if the DirSynctool meets your requirements, its use should be preferred over the Windows Azure AD Connector. The primary reasons are listed hereafter: The DirSync tool has been designed to be easy to deploy and its configuration is automated through setup. The deployment of the Windows Azure AD Connector is a custom task, which is more complex and can be associated with configuration errors. The deployment and maintenance is more effort intensive and therefore more costly. In case of issues with directory synchronization, troubleshooting of the DirSync tool will typically be easier. No licensing requirements apply for the DirSync tool, while a FIM 2010 (R2) server license and possibly Visual Studio licenses are required for the Windows AzureAD Connector. Important note: It should also be called out that not all scenarios that the Windows Azure AD Connector enables are supported. For example, for Office 365 customers, it is not supported to synchronize only a subset of the attributes that are normally synchronized to Office 365, as removing attributes from the synchronization flow can adversely impact service functionality.See KB article 2256198LIST OF ATTRIBUTES THAT ARE SYNCHRONIZED TO OFFICE 365 AND ATTRIBUTES THAT ARE WRITTEN BACK TO THE ON- PREMISES ACTIVE DIRECTORY DOMAIN SERVICES75. 75 2256198 LIST OF ATTRIBUTES THAT ARE SYNCHRONIZED TO OFFICE 365 AND ATTRIBUTES THAT ARE WRITTEN BACK TO THE ON- PREMISES ACTIVE DIRECTORY DOMAIN SERVICES:http://support.microsoft.com/kb/225619836 Active Directory from on-premises to the cloud
    • Important note: The Windows Azure AD Connector provides support for directory synchronization only. In other words, the Windows Azure AD Connector does not cover licensing or service provisioning. For Office 365 customers, they will still have to assign licenses to their users in a second step, after directory synchronization completes – which can be achieved through custom PowerShell commands. It is recommended to deploy the Windows Azure AD Connector on a dedicated FIM instance. While the deployment of the Windows Azure AD on an existing FIM server is possible (but not supported), it will also increase the complexity of the configuration and make troubleshooting and maintenance more difficult. Availability of the Windows Azure AD Connector for FIM 2010 (R2)is currently subject to certain pre- requisites and an organization must work directly with Microsoft. As of writing, the Windows Azure AD Connector for FIM 2010 (R2) is indeed provided via Microsoft Premier Deployment (MPD) only. Please contact your local Microsoft Office 365 CXP Solution Architectif “complex” multi-forest support is a requirement for your organization. 4.1.3 Other options to consider As you already know, the Microsoft Online Services Module for Windows PowerShell allows administrators to perform a variety of management tasks from the command line, including user management, group and group membership management and license management. The Directory Graph API enables similar functions, through a REST-based API interfaces. Likewise, it allows accessing the most common properties of all object types in the directory. The MSDN documentation76 describes these properties and shows which ones are write-able.It supports managing all directory objects includingUsers, Groups, Contacts (delete/update), user license assignment, and managing user‘s manager and directReport relationships. Through these two interfaces, you can automate provisioning operations such as the creation, modification or deletion of objects in your Windows Azure AD directory tenant. For Office 365 customers, whilst they also allow the creation of Exchange mailboxes through license assignment, they do not permit the creation of mail-enabled groups or contacts. The management of Exchange objects is not covered. Mail-enabled objects need to be created through Exchange Online remote PowerShell, after objects have been replicated from the Windows Azure AD directory tenant to the Exchange Online directory. 76 W INDOWS AZURE AD GRAPH ENTITIES REFERENCE: http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspxActive Directory from on-premises to the cloud 37
    • Note: Exchange Online remote PowerShell is in no way tied to the Microsoft Online Module for Windows PowerShell. By connecting to the Microsoft Exchange Online services, you connect to the Microsoft Exchange Online datacenters server environment, i.e. a server-side session, which contains the commands used in the cloud-based service. In other words, a remote PowerShell interface is available to you so that you can access the Exchange Online configuration information using a separate set of Windows PowerShell cmdlets.For additional information, see the article CONNECT WINDOWS POWERSHELL TO THE SERVICE77and the blog post USING EXCHANGE MANAGEMENT SHELL TO MANAGE YOUR EXCHANGE ONLINE AND EXCHANGE ON PREMISES ENVIRONMENT78. Using Exchange Online remote PowerShell, administrators can manage Exchange Online objects and properties, either for automation purposes or to manage items that are otherwise not exposed through the portal. Note: Exchange Online remote PowerShell offers the same PowerShell cmdlets as Exchange Server 2010 Service Pack 1 (SP1) and above, with certain commands and parameters disabled because these features do not apply in the hosted environment. For a list of the cmdlets available to Exchange Online administrators, see REFERENCE TO AVAILABLE POWERSHELL CMDLETS IN EXCHANGE ONLINE79. Be aware thattheses interfaces do not provide the same set of capabilities as the previously discussed directory synchronization tools provided by Microsoft. More specifically: These interfaces only provide access to a subset of attributes that can be managed through DirSync or the Windows Azure AD connector for FIM 2010. Service-side throttling is applied on these interfaces in order to protect the service and the customers against large batches of commands. This may slow down provisioning / synchronization of users, and each full synchronization cycle may take a very long time to complete. Microsoft Online Services Module for Windows PowerShell doesn‘t provide mechanisms to enumerate changes that occurred in the Windows Azure ADdirectory tenant, making it not well suited to directory synchronization processes. (The Directory Graph API supports the differential query since November 2012.) From a service perspective, objects provisioned through the cmdlets of Microsoft Online Services Module for Windows PowerShell will not appear as ―synchronized‖ objects. Consequently, the use of interfacesfor object provisioning purposes should currently be limited to scenarios where: A limited number of objects need to be managed. Exchange Hybrid (―rich coexistence‖) is not required for Office 365 customers. Directory synchronization is available only through the DirSync tool or the Windows Azure AD 77 CONNECT W INDOWS POWERSHELL TO THE SERVICE: http://help.outlook.com/en-us/140/cc952755.aspx 78 USING EXCHANGE MANAGEMENT SHELL TO MANAGE YOUR EXCHANGE ONLINE AND EXCHANGE ON PREMISES ENVIRONMENT: http://blogs.technet.com/b/ilvancri/archive/2012/03/17/3487056.aspx 79 REFERENCE TO AVAILABLE POWERSHELL CMDLETS IN EXCHANGE ONLINE: http://help.outlook.com/en-us/140/dd575549.aspx38 Active Directory from on-premises to the cloud
    • Connector. Directory Synchronization is mandatory to support certain features such as Exchange hybrid coexistence. As such, the Microsoft Online Services Module for Windows PowerShell (and potentially the (preview of the) Windows Azure AD Management portal) can be recommended to customers who only need cloud identities and do not require a synchronization solution at all – falling in the ―zero on-premises hardware‖ category. The following table synthetizes the available options for on-premises AD scenarios: Scenario DirSync (or Windows Windows Directory Graph API Azure AD Connector) PowerShell provisioning provisioning Cloud identities: Recommended Available Available No Federation Performance Performance No Exchange coexistence limitations may apply limitations may apply for Office 365 customers Federated identities Required Available Not available Cannot create federated users Exchange Hybrid deployments Required Not available Not available (―rich coexistence‖)for Office Required attributes Required attributes are 365 customers are not exposed not exposed 4.2 Synchronize your directory tenant with non-ADdirectories on- premises The Windows Azure AD Connector does not require an Active Directory to synchronize from. (It uses the FIM 2010 metaverse as a source).Consequently, almost any directory or combination of directories may be used as a synchronization source, provided that a FIM 2010 management agent(or connector) is available to support this directory or directories. The TechNet articleManagement Agents in FIM 201080 provides a list of management agents that are available with FIM 2010 Alternatively, it is also possible to develop custom management agents, to use other interfaces such as text files, or to leverage management agents that are provided by third party vendors or in the public domain as open source solutions such as the OpenLDAP Extensible Management Agent (XMA) project on SourceForge81. As for Active Directory multi-forest support, availability of this solution is currently subject to same pre-requisitesand through an early onboarding program.Please contact your local Microsoft Office 365 CXP Solution Architectif Non-AD directories are a requirement for your organization. As also discussed in the previous section, Microsoft Online Services Module for Windows PowerShell and the Directory Graph API may also be used to automate the provisioning and maintenance of Windows Azure AD identities. 80 MANAGEMENT AGENTS IN FIM 2010: http://technet.microsoft.com/en-us/library/ff608275%28WS.10%29.aspx 81 OpenLDAP Extensible Management Agent (XMA): http://sourceforge.net/projects/openldap-xma/Active Directory from on-premises to the cloud 39
    • The Microsoft Online Services Module for Windows PowerShell provisioning can be recommended today, for customers who have extensive scripting experience or are willing to work with a partner to develop a custom solution. For instance, to create a federated user for Office 365, proceed with the following steps: 1. Open a Windows PowerShell prompt and import the module:PS: C:Windowssystem32>Import-Module MSOnline 2. Establish a session with your Windows Azure AD directory tenant with the Connect- MsolService cmdlet. You will be prompted to enter your admin credentials (such as admin@xxx.onmicrosoft.com and password) to authenticate against your Windows Azure AD directory tenant.PS: C:Windowssystem32>Connect-MsolService 3. Obtain the unique string ID of the account/SKU combination that will be needed to assign a license, for example ―idmgt:ENTERPRISEPACK‖ in our configuration with the Get- MsolAccountSkucmdlet.PS C:Windowssystem32>Get-MsolAccountSku 4. Create the user with theNew-MsolUser cmdlet:PS C:Windowssystem32> New-MsolUser -DisplayName user1 –UserPrincipalName user1@demo.idmgt.archims.fr -UsageLocation FR -BlockCredential $false –ImmutableId 81372 5. Set the user‘s license with the Set-MsolUserLicense cmdlet:PS: C:Windowssystem32> Set-MsolUserLicense -UserPrincipalName user1@demo.idmgt.archims.fr -AddLicenses"idmgt:ENTERPRISEPACK" Several third-party solutions built on these interfaces are available today, providing a simple solution for such scenarios. As an example, we can mention theOptimal IdM82 solution. This said, keep in mind notably that: These two interfaces were not designed for directory synchronization The operations will take longer time to complete due to server-side throttling, Certain features are not supported with the provisioning based on these interfaces. 82 Optimal IdM: http://www.optimalidm.com/40 Active Directory from on-premises to the cloud
    • The following table synthetizes the available options for on-premises non-AD directories scenarios: Scenario Windows Azure AD Windows Directory Graph API Connector PowerShell provisioning provisioning Cloud identities Available Available Available No Federation (Non-AD Performance Performance synchronization limitations may apply limitations may apply through early onboarding program) Federated identitieswith a Available Available Not available supported on-premises identity Non-AD Cannot create providers synchronization federated users through early onboarding program) For Office 365 customers, Exchange coexistence is not available in non-AD directories scenarios since by definition customer cannot have Exchange server in this case.Active Directory from on-premises to the cloud 41
    • 5 Federate your Windows Azure AD directory tenant with your on-premises directory This sectionas its title indicates addresses the identity federationtopic (also called single sign-on) from the Windows Azure AD perspective, which is the second integration capability provided by Windows Azure AD. Setting up identity federation for domain(s) within your Windows Azure AD directory tenant requires to conduct a few steps as outlined at the following URL: https://activedirectory.windowsazure.com/IdentityFederation/IdentityFederation.aspx Identity federationin general is also a broad topic, with many facets, depths of understanding, protocols, standards, tokens, etc. As an illustration, Wikipedia83 defines identity federation as follows: ―Federated identity, or the ‗federation‘ of identity, describes the technologies, standards and use- cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration.‖ 83 Identity federation definition from Wikipedia: http://en.wikipedia.org/wiki/Federated_identity42 Active Directory from on-premises to the cloud
    • As such, it requires preparation to be successful in this area and, more specifically in the context of Windows Azure AD, to fulfill the requirements for this integration capability. This is the purpose of the step1. Moreover, as the above step five indicates, whilst federation is not required for directory synchronization (but it will provide a richer user experience), directory synchronization is however a requirement for federation. Hence, the implementation of directory synchronization is needed in order to keep the on-premises identities in sync with the organization‘s Windows Azure AD directory tenant. One of the benefits is that it enables controlling and managing the corporate user accounts in the traditional way through the existing tooling that accompanies the on-premises identity infrastructure. This one piece really does provide seamless user management between the on-premises and Windows Azure AD environments. Please refer to the previous section § 4SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR on-premises directory to see how to synchronize your AAD directory tenant with your on- premises directory. When an organization leverages these two integration capabilities, i.e. directory synchronization and federation(also called single sign-on), its identity management capability are stretching over both an on-premises deployment and a cloud deployment. This ability to operate across both on-premises and cloud deployments in a hybrid mode enables an organization to easily take advantage of cloud (SaaS) applications while all of its existing identity management processes and existing on-premises applications can continue unaffected. This aspect is critical for some organizations that need to comply with business or regulatory requirements that mandate that certain critical information, such as passwords, be maintained in on-premises servers. As of writing, Active Directory Federation Service (AD FS) 2.0, Shibboleth 2, Optimal IDM Virtual Identity Server Federation Services and PingFederate 6.10 are the only supported technologies in terms of on-premises single sign-on servers or enterprise identity providers to enable this integration capability (even if this is something that may evolve in the future). Federation standards such as OASIS WS-Federation/WS-Trust (WS-*) or SAML 2.0 are indeed complex and each implementation tends to have its own ―specificity‖. This may introduce (slight) differences in the way various features work and some may break resulting in unpredictability of customer experience due to the use of non-tested configurations even if interoperability profiles greatly helps in reducing the probability of such side-effects. This is the reason why neither generic WS-* support nor generic SAML 2.0 support are provided today with Windows Azure AD. rd If you require assistance with a specific 3 party solution, for which support has not yet been announced, please contact your local Office 365 CXP Solution Architect. As seen in the previous chapter, directory synchronization options differ whether your on-premises identity infrastructure relies on Windows Server Active Directory or not.Active Directory from on-premises to the cloud 43
    • Since directory synchronization is mandatory with federation, the following table provides a comprehensive overview of the possible scenarios with the aforementioned technologies. Active Directory source Non-AD directory source Directory Synchronization provided Directory Synchronization to be through the DirSync tool/FIM 2010 + implemented using FIM 2010 + Windows Windows Azure AD Connector Azure AD Connector or custom solutions AD FS 2.0 Available Not available (WS-*) Supports Web clients AD FS 2.0 only supports Active Supports rich clients Directory sources for authentication Federation chaining or protocol conversion through AD FS 2.0 is not supported Shibboleth Available Available, through early onboarding (SAML 2.0) Supports Web clients SupportsWeb clients For Office 365 customers: For Office 365 customers: Supports Office 2007, 2010 Supports Office 2007, 2010 Supports Outlook (*) Supports Outlook (*) Supports ActiveSync, POP, IMAP Supports ActiveSync, POP, IMAP (*) (*) Doesn‘t support Lync, Office Doesn‘t support Lync, Office Subscription, CRM Subscription, CRM Doesn‘t support Office 2013 (Word, Doesn‘t support Office 2013 (Word, Excel, PowerPoint) Excel, PowerPoint) (*) Requires installation of the Shibboleth (*) Requires installation of the Shibboleth 2 Enhanced Client Proxy extension. 2 Enhanced Client Proxy extension. Ping Federate 6.10 Available Available, through early onboarding (WS-*) Supports Web clients SupportsWeb clients For Office 365 customers: For Office 365 customers: Supports Office Suite 2007, 2010 Supports Outlook Supports Outlook Supports ActiveSync, POP, IMAP Supports ActiveSync, POP, IMAP Supports Lync, Office Subscription, Supports Lync, Office Subscription, CRM CRM Optimal IDM Available Available, through early onboarding (WS-*) Supports Web clients Supports Web clients For Office 365 customers: For Office 365 customers: Supports Outlook Supports Outlook Supports ActiveSync, POP, IMAP Supports ActiveSync, POP, IMAP Supports Lync, Office Subscription, Supports Lync, Office Subscription, CRM CRM Other WS-* providers Not available Not available (Generic WS-*) Other SAML providers Not available Not available (Generic SAML 2.0) The rest of this chapter further discusses the integration with AD FS 2.0 and Shibboleth 2.44 Active Directory from on-premises to the cloud
    • Note: For more information on leveraging Optimal IDM Virtual Identity Server Federation Services and PingFederate 6.10 solutions as identity providers to implement single sign-on, see the online help topic USE THIRD-PARTY IDENTITY PROVIDERS TO IMPLEMENT SINGLE SIGN-ON84.For the PingFederate instructions on how to configure the solution to provide the single sign-on experience to your Active Directory users, see the documentWEB SSO TO OFFICE 365 USING PINGFEDERATE85. Once successfully configured, the federated domain(s) are managed via the cmdlets of the Microsoft Online Services Module for Windows PowerShell (see section § 3.2.1.3MANAGEMENT SURFACE). 5.1 Federate your directory tenant with an on-premises WS-* based Identity Provider As of writing, the primary option in terms of enterprise identity providers for the federation (single sign- on)feature of Windows Azure ADis the Active Directory Federation Services (AD FS) 2.0service that the organization deploys on-premises and then configures Windows Azure AD to securely communicate with. AD FS 2.0 is a component of the Windows (Server) platform and, as such, the right to use it is included in the associated license costs. Important note: The AD FS role available in Windows Server 2008 (R2) doesn‘t correspond to AD FS 2.0; this is the previous version 1.1 instead. TheAD FS 2.0 software package for your specific operating system version (either Windows Server 2008 or Windows Server 2008 R2) is the AdfsSetup.exe setup file. To download this file, go to Active Directory Federation Services 2.0 RTW 86. 84 USE THIRD-PARTY IDENTITY PROVIDERS TO IMPLEMENT SINGLE SIGN-ON: http://technet.microsoft.com/en-us/library/jj679342.aspx 85 WEB SSO TO OFFICE 365 USING PINGFEDERATE: http://go.microsoft.com/fwlink/?LinkID=266321 86 Active Directory Federation Services 2.0 RTW: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10909Active Directory from on-premises to the cloud 45
    • Important note: As of writing, update rollup 2 for AD FS 2.0 is available. This update rollup (or the previous one87) includes hotfixes and updates for AD FS 2.0 RTW that are of special interest in the context of this paper for the single sign-on feature of Office 365. For more information about this update rollup and its download, please see article 2681584 DESCRIPTION OF UPDATE ROLLUP 2 FOR ACTIVE DIRECTORY FEDERATION SERVICES (AD FS) 2.088. The white paper entitled MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.089available on the Microsoft Download Center, and part of this series of document, provides detailed information on planning and configuring the SSO feature for Windows Azure AD with AD FS 2.0. It indeed aims at providing a better understanding of the different single sign-on deployment options for Windows Azure AD (and the services in Office 365) with AD FS 2.0, how to enable single sign-on using corporate Active Directory (AD) credentials and AD FS 2.0 to the services in Office 365, and the different configuration elements to be aware of for such deployment. 5.2 Federate your directory tenant with an on-premises SAML 2.0based Identity Provider In addition to AD FS 2.0, support for additional identity providers has been added, so that organizations may continue to use their existing on-premises identity infrastructure for single sign-on with Windows Azure AD and the Microsoft Online services such as Office 365, whether this identity infrastructure is based on AD or on non-AD directories. For organizations that already have a federated SSO infrastructure in place, it is indeed highly desirable to reuse it for Windows Azure AD. Along with the Optimal IDM Virtual Identity Server Federation Services and PingFederate 6.10 solutions cited before, Shibboleth 2 is one of these additional identity providers. Shibboleth (as a reference to the Hebrew word "shibbóleth‖ and the related Biblical use, i.e. to discover hiding members of the opposing group) was designed to fill higher education needs in terms of identity federation and attributes propagation for a number of partners. The Shibboleth project was initiated by the Internet2/MACE (Middleware Architecture Committee for Education) 90 in 2000. The project now hosted by the Shibboleth Consortium91refers to both a specification and an open source project that implements them as a distributed system. As of today, considering its origin, the Shibboleth 2 Identity Management system is notably and unsurprisingly leveraged by many educational and research institutions around the world. Shibboleth 2 supports different data sources (Active Directory, other LDAP directory, SQL databases, etc.) that can be used as an identity repository. 87 Article 2607496 DESCRIPTION OF UPDATE ROLLUP 1 FOR ACTIVE DIRECTORY FEDERATION SERVICES (AD FS) 2.0: http://support.microsoft.com/kb/2607496 88 Article 2681584DESCRIPTION OF UPDATE ROLLUP 2 FOR ACTIVE DIRECTORY FEDERATION SERVICES (AD FS) 2.0: http://support.microsoft.com/kb/2681584 89 MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.0: http://www.microsoft.com/en- us/download/details.aspx?id=28971 90 Internet2/MACE (Middleware Architecture Committee for Education): http://middleware.internet2.edu/MACE 91 Shibboleth Consortium: http://shibboleth.net46 Active Directory from on-premises to the cloud
    • Shibboleth 2 is an implementation of identity provider using the OASIS SAML 2.0 protocol to provide Web single sign-on across or within organizational boundaries. As previously noticed, the sign-in service of Windows Azure AD 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.092. 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). Shibboleth 2 supports the two profiles and related deployment model if any. Beyond the Shibboleth 2 support, it should be noted that generic SAML 2.0 support is not provided today. Shibboleth 2 provides cross-domain (Web)SSO(also known as identity federation) with Microsoft and non-Microsoft federation solutions. The white paper entitled MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.093available on the Microsoft Download Center, and also part of this series of document, provides information on planning and configuring the SSO feature for Windows Azure AD with Shibboleth 2. It has the exact same objectives of the aforementioned white paper on AD FS 2.0 but with the Shibboleth 2 technology. The information provided is based on our experience in setting up a test Shibboleth 2 implementation, and is not intended to be an exhaustive guide to installing and configuring Shibboleth 2. Shibboleth 2 is a third-party product and therefore Microsoft does not provide support for the deployment, configuration, troubleshooting, best practices, etc. issues and questions regarding Shibboleth 2. For information on the prerequisites as well as on the installation and the configuration of a ShibbolethIdP, we invite you to visit complementarily the documentation made available by the Shibboleth Community94. 92 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 93 MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.0: http://www.microsoft.com/en- us/download/details.aspx?id=35464 94 SHIBBOLETH INSTALLATION: https://wiki.shibboleth.net/confluence/display/SHIB2/InstallationActive Directory from on-premises to the cloud 47
    • 6 Enable Single Sign-On and Windows Azure AD Directory Services for cloud applications As you are now aware of, Windows Azure AD provides authentication and single sign-on (SSO) capabilities for cloud applications (and beyond). These capabilities enable organizations to easily manage user access to cloud applications and services without the additional cost, burden, and hassle of having to acquire and manage new user credentials. As its title indicates, this chapter covers the SSO support as a whole and gives the information and the pointers to successfully leverage this key capability in your (hybrid) cloud environment. The //BUILD/conference session recordingW INDOWS AZURE ACTIVE DIRECTORY: ENABLING SINGLE SIGN ON AND DIRECTORY SERVICES FOR CLOUD SAAS APPS95 provides an overview of these key capabilities. There are flavors of this support for browsers and for rich clients, and for identities hosted in the cloud as well as federated identity providers. For the latter situation, a seamless end-to-end SSO experience can be delivered for userslogging on their domain-joined machines, on on-premises servers and other cloud applications and services.In addition to enable SSO between your cloud applications and your Windows Azure AD directory tenant as covered in this chapter, such an experience also requires to federate your WindowsAzure AD domain(s) with your on-premises identity providers as discussed in the previous chapter. 6.1 Leverage your Windows Azure AD directory tenant with your SaaS subscription Services and applications that falls into this category are the ones that are exclusively cloud-based and that are offered through a subscription-based licensing model. They don‘t need to explicitly support multi-tenancy even if the vast majority of them do. As the customer purchases access to the service or the application, a new application copy gets suitably customized, deployed to an exclusive instance of some sort (for example, a set of Windows Azure instances) and started. This model offers the advantage of establishing a consumption based model for the customer organization. Suchservices and applications can benefit from Windows Azure AD and as an illustration, we describe in this section how the Microsoft Online Services natively leverage Windows Azure AD. Such capability can be easily reproduced for any multi-tenant application as described in the section § 6.3LEVERAGE YOUR CUSTOMER‘S W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS APPLICATION IN THE CLOUD. Let‘s start with Microsoft Office 36596, which provides secure anywhere access to professional email, shared calendars, instant messaging (IM), video conferencing, and document collaboration. Note: For information on Microsoft Office 365, please refer to the product online documentation97, the OFFICE 365 DEPLOYMENT GUIDE FOR ENTERPRISES98, the Office 365 Tech Center web site99, and the Office 365 Community web site (blogs, forums, wikis, etc.)100. 95 WINDOWS AZURE ACTIVE DIRECTORY: ENABLING SINGLE SIGN ON AND DIRECTORY SERVICES FOR CLOUD SAAS APPS: http://channel9.msdn.com/Events/Build/2012/3-042 96 Microsoft Office 365: http://office365.microsoft.com/48 Active Directory from on-premises to the cloud
    • With the exception of Internet sites for anonymous access created with SharePoint Online, users must be authenticated when accessing services in Office 365. Office 365 relies on the Windows Azure AD capabilities for the identity management of your subscription. Interestingly enough, organizations that subscribe to Office 365 indeed transparently get underneath a Windows Azure AD directory tenant for the Office 365 identity management. They can then use Windows Azure AD to configure the directory synchronization with their on- premises directories (see section § 4SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR on-premises directory) and federate with their on-premises identity provider (see section § 5FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR on-premises directory) to allow interoperability with their existing on-premises identity management environment and seamlessly manage this hybrid environment as one environment. Such capabilities can be configured via either the Microsoft Online Portal (MOP) or the (preview of the) Windows Azure AD Management Portal101. 97 OFFICE 365 HELP: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ 98 OFFICE 365 DEPLOYMENT GUIDE FOR ENTERPRISES: http://www.microsoft.com/download/en/details.aspx?id=26509 99 Office 365 Tech Center web site: http://technet.microsoft.com/en-us/office365/default 100 Office 365 Community web site: http://community.office365.com/en-us/default.aspx 101 Preview of the Windows Azure AD Management Portal: https://activedirectory.windowsazure.com/Active Directory from on-premises to the cloud 49
    • Note: These two portals all read from and write to a single shared instance of Windows Azure AD that is associated with your organization‘s tenant. In this way, the portals act as a front-end interface that pull in and/or modify your tenant data. This said, you can use the Windows Azure AD portal to do most of the functions, with the added benefit of having a single place to see all of the users, groups, domains, licenses associated with all of the cloud services that your organization subscribes to. By leveraging the federation feature of the Windows Azure AD organization‘s directory tenant, Office 365 provides in turn organizations with the ability to authenticate against the organization‘s on- premises identity infrastructure (such as Windows Server AD or LDAP), allowing their users to use their corporate credentials to access their services in Office 365 that they have been provisioned for. Thus, users that are on the internal corporate network or connected through a VPN will have seamless access to services in Office 365. If users are accessing services in Office 365 from home or from any computer not connected to the corporate network, they will also still have access to services in Office 365 using their corporate credentials. Such a user sign-in experience is awaited by many of the organizations: Work computer on a corporate network: When users are at work and signed in to the corporate network, SSO enables them to access the services in Office 365 (without signing in again, depending on the on-premises identity provider being used to sustain this feature); Home or public computer: The users must sign in with corporate credentials to access the services in Office 365. This is still an advantage since they will only have to remember one set of credentials for their corporate and Office 365 accesses; Smartphone: On a smartphone, in order to access Microsoft Exchange Online using Microsoft Exchange ActiveSync (EAS), the users must sign in with their corporate credentials. This is still an advantage since they will only have to remember one set of credentials for their corporate and Office 365 accesses; Microsoft outlook or other e-mail clients: The users must sign in with their corporate credentials to access their e-mail messages if they are using Outlook or an e-mail client that is not part of Office such as an IMAP or a POP client. Note: You only need to sign up for a Windows Azure AD directory tenant one time and then you can sign-in to that same tenant when you want to subscribe to other Microsoft cloud services like Windows Intune102for instance. By using your organization‘s Windows Azure AD directory tenant in this way, any additional services that you might decide to subscribe to in the future can fully leverage the existing user accounts, policies, settings or on-premises server deployments you may have already configured previously to help improve efficiencies between your organization‘s identity infrastructure on-premises and Windows Azure AD. For instance, if you originally signed up for an Office 365 subscription and previously went through the steps to further integrate your on-premises identity infrastructure with your Windows Azure AD directory tenant by configuring directory synchronization and/or single sign-on, you can later sign up for another Microsoft cloud service such as Windows Intune which can also leverage the precise same directory integration benefits as Office 365. Beyond Microsoft Office 365, Dynamics CRM Online, Windows Intune, and now Windows Azure offers the exact same capabilities. 102 Windows Intune: http://technet.microsoft.com/en-us/windows/intune.aspx50 Active Directory from on-premises to the cloud
    • The Windows Azure Management portal is now integrated with Windows Azure AD and supports federation with theorganization on-premisesidentity infrastructure. In addition, this integration also means that Office 365 customers can use the same tenants and identities they use for the Office 365 services to manage sign-on and access to Windows Azure. For considerations that pertain to Windows Azure, you can refer more specifically to the blogpost W INDOWS AZURE NOW SUPPORTS FEDERATION WITH W INDOWS SERVER ACTIVE DIRECTORY103. 6.2 Leverage your Windows Azure AD directory tenant with your LOB application in the cloud Web applications are by far the most popular business application types. From corporate portals to collaboration solution, including cloud Line-Of-Business (LOB) applications, the ease of distribution (no client distribution and lifecycle management required), the flexibility of the application updates and the user familiarity with the browser put this form factor firmly on top of the list. The topology is the usual: there is a Web frontend of some sort which relies on some sort of middle-tier in the cloud (connected to the on-premises infrastructure). The combined influence of growing presence of devices in business environments with the Consumerization of IT and the Bring Your Own Device (BYOD) phenomena, and success of the various marketplace (iTunes, Google Play, Windows (Phone)Store make this form factor one of the fastest growing ones. The main areas of application revolve around mobile workforce scenarios (sales people, pharmaceutical promoters, etc.), scenarios in which mobility and free hands are of essence (manufacturing, logistic, healthcare services) and the like. More and more mobile applications make use of a cloud-based back-end for the notifications, storage, etc. For all of those aforementioned applications, the ability to sign-in a user is an essential identity service. However, while essential, it is typically perceived by both end users and developers as a ―speed bump‖ the user must cross before being productive. Emphasis is thus placed on making sign-in unobtrusive but without compromising security. The support for Windows Azure AD can essentially be seen as an exercise in adding incremental capability. The (preview of the) Windows Azure AD Management Portal provides guidance for these applications (activedirectory.windowsazure.com/develop) whether they‘re applications of your organization or multi- tenant applications you want to expose to multiple organizations. 103 WINDOWS AZURE NOW SUPPORTS FEDERATION WITH W INDOWS SERVER ACTIVE DIRECTORY: http://blogs.msdn.com/b/windowsazure/archive/2012/11/28/windows-azure-now-supports-federation-with-windows-server-active- directory.aspxActive Directory from on-premises to the cloud 51
    • Let‘sstart with your own applications with the page W INDOWS AZURE ACTIVE DIRECTORY: DEVELOP APPS FOR YOUR ORGANIZATION104. 104 W INDOWS AZURE ACTIVE DIRECTORY: DEVELOP APPS FOR YOUR ORGANIZATION: https://activedirectory.windowsazure.com/Develop/Single-Tenant.aspx52 Active Directory from on-premises to the cloud
    • The integration of your application with your Windows Azure AD directory tenant (step three above) entails three steps: 1. Provision the application in your Windows Azure AD directory tenant, 2. Enable single sign-on (SSO) with Windows Azure AD, 3. Query yourWindows Azure AD directory tenant data using the Windows Azure AD Graph API. The following sections further describe each step. Note: For additional information on the first two steps, see the article WEB SINGLE SIGN-ON WITH .NET AND WINDOWS AZURE ACTIVE DIRECTORY105. It provides a tutorial that shows how to create and configure a single tenant application that uses the single sign-on capabilities of Windows Azure AD. You can also see theblog post SINGLE SIGN ON WITH WINDOWS AZURE ACTIVE DIRECTORY: A DEEP DIVE106. 6.2.1 Provision the application in your Windows Azure AD directory tenant In order to establish single sign-on between your cloud application and your Windows Azure AD directory tenant, your cloud application needs to be ―registered‖ to your Windows Azure AD directory tenant to gain access to it – this is a common practice accessing protected services. In effect, in a directory tenant, and as already mentioned (see section § 3.2.3CORE SECURITY MODEL), every entity that can be accessed is defined as a security object (a user account for example) and every entity that can actively access those objects is represented as a principal. Consequently, each cloud application that need to access a Windows Azure AD directory tenant must have a principal, more specifically a service principal, associated with it in that Windows Azure AD directory tenant. The service principal represents an instance of the cloud application, or in the case of multi-tenant application (see section § 6.3LEVERAGE YOUR CUSTOMER‘S W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS APPLICATION IN THE CLOUD), a logical instance of the application. The cloud applications will later use this service principal to authenticate itself when it will try to access your directory tenant (see next section § Error! Reference source not found.ERROR! REFERENCE SOURCE NOT FOUND.). Service principals are completely analogous to users in that: 1. They are identified by a fixed naming schema, i.e.a service principal name (SPN), much like users are identified by a user principal name (UPN). Windows Azure AD uses here a comparable naming schema as the one used in Active Directory where the SPN helps to identify a specific service class/type, where it is running, and so on. The SPN is a multi-valued attribute of the principal object. The SPN value represents the cloud application and its host; it will be used as part of the service‘s SPN. You derive its value from what you know about the cloud application you are provisioning. 105 W EB SINGLE SIGN-ON WITH .NET AND WINDOWS AZURE ACTIVE DIRECTORY: http://www.windowsazure.com/en- us/develop/net/how-to-guides/web-sso/ 106 SINGLE SIGN ON WITH WINDOWS AZURE ACTIVE DIRECTORY: A DEEP DIVE: http://blogs.msdn.com/b/vbertocci/archive/2012/07/05/single-sign-on-with-windows-azure-active-directory-a-deep-dive.aspxActive Directory from on-premises to the cloud 53
    • SPN‘s value can be considered as logically having up to 3 parts: service class/hostname[@tenant domainname] as explained below: a. The service class that represents the (type of the) application. This parallels the notion of service class in the SPN model for Windows Server AD. b. The hostname that identifies a unique instance (or deployment) of the cloud application. This parallels the notion of hostname in the SPN model for Windows Server AD. This is the hostname of the cloud application, for example aadauthndemo.azurewebsites.net for an ASP.NET MVC 4 Web application hosted on Windows Azure Web Sites107accessible at the application endpoint URL https://aadauthndemo.azurewebsites.net/. Note: When using SSL/TLS connections, the hostname is also the identity that the cloud application can prove to the client by means of an SSL/TLS certificate. In many cases, bearer security tokens are used to access protected resources. Since these tokens do not carry proof of possession keys, they are susceptible to man-in-the-middle replay attacks. An attacker fools the client into obtaining a token and handing it to the attacker who them immediately replays it to the real protected resource and obtains access to that resource. The use of the hostname in service principals, and requiring it to be sent to the applicative STS, when requesting a security token, provides a means of verifying that a particular cloud applicationeffectively resides at that hostname. The client must also verify, via SSL/TLS, that the target service is using the same hostname. c. The tenant domain name component that identifies the directory tenant of the application when accessing a multi-tenant application. At the simplest form, the SPN‘s value can be just the application endpoint URL if you don‘t want to adhere to the above schema. 2. There are a set of credentials on the principal. The credentials can be: a. A secret symmetric key that is shared between the applicative STS for the realm and the cloud application. The domain owner has control over the key that is used to authenticate the service principal. b. A certificate that the application uses to authenticate and establish itself as the service principal 3. A service principal can be enabled or disabled much like users. If a service principal is disabled then then the applicative STS refuses access tokens to the service and thus access to the service is disallowed. The account is also not allowed to authenticate to any other service. 4. A cloud application can specify its own principal, using its SPN, when it is acting as a client to access another cloud application in the context of its service principal. Finally, a service principal has a redirection URL associated with it. To prevent security exposure when using browser authentication flows, this service principal address is indeed required on the service principal, so that the applicative STS can verify that the redirection URL supplied in the query string (such as the wreply parameter in the WS-Federation protocol) matches the service principal address in the service principal; otherwise the browser authentication flows are open to an elevation of privilege attack. 107 Windows Azure Web Sites: http://www.windowsazure.com/en-us/home/features/web-sites/54 Active Directory from on-premises to the cloud
    • The redirection URL is the root URL of the cloud applicationhttps://<hostname>/, where <hostname> is the application endpoint that the user will be redirected to after the single sign-on is complete; for example https://aadauthndemo.azurewebsites.net/ for an ASP.NET MVC 4 Web application hosted on Windows Azure Web Sites. When Windows Azure Active Directory Preview was first launched, the only way to provision service principals in your Windows Azure AD directory tenant was by using the Microsoft Online Services cmdlets for Windows PowerShell module. To create a service principal for your cloud application and to grant applications access to your Windows Azure AD directory tenant with the Microsoft Online Services Module for Windows PowerShell, proceed with the following steps after having installed this module: 1. Open a Windows PowerShell prompt and import the required modulesto support service principal management:PS C:Windowssystem32>Import-Module MSOnlinePS C:Windowssystem32>Import-Module MSOnlineExtended –Force 2. Establish a session with your Windows Azure AD directory tenant with the Connect- MsolService cmdlet. You will be prompted to enter your admin credentials (such as admin@xxx.onmicrosoft.com and password) to authenticate against your directory tenant.PS C:Windowssystem32>Connect-MsolService 3. Using the New-MsolServicePrincipalAddresses cmdlet, create a service principal address that corresponds to the redirection URL to which the(bearer) security tokens issued by the applicative STS will be returned.PS C:Windowssystem32>$replyUrl = New-MsolServicePrincipalAddresses –Address “https://<your application endpoint>/” 4. Finally create the service principal representing your cloud applicationinside your Windows Azure ADdirectory tenant with the New-MsolServicePrincipal cmdlet.PS C:Windowssystem32>$sp = New-MsolServicePrincipal –ServicePrincipalNames @(“<service class>/<hostname>") -DisplayName "<service principalname>" -Addresses $replyUrl-Type Symmetric The permissions must be granted to the application by the directory tenant. The creation of the service principal only enables single-sign-on (SSO). For that purpose, the service principal must be added to a role to enable specific application permissions with the Windows Azure directory tenantby using the Add-MsolRoleMember cmdlet. There are two supportedrole name for this cmdlet: 1. “User Account Administrator”: Grants permission to read and write data, such as users, groups and information about your organization. 2. “Directory Reader”: Grants permission to read directory data, such as user accounts, groups, and information about your organization. The following commands set permissions to allow the service principal to have Read and Write permissions for your Windows Azure AD directory tenant:PS C:Windowssystem32>$ReadWrite = "User Account Administrator"PS C:Windowssystem32>Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName $ReadWrite -RoleMemberObjectId$sp.objectid While the Add-MsolRoleMembercommands hereafter set them to allow the service principal to have only Read permissions for your Windows Azure AD directory tenant:Active Directory from on-premises to the cloud 55
    • PS C:Windowssystem32>$Read = "Directory Reader"PS C:Windowssystem32>Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName $Read -RoleMemberObjectId$sp.objectid Once the service principal is created, you can view it by using the Get-MsolServicePrincipal cmdlet from this PowerShell window. For a full list of commands available, including removing service principal, run the following command:PS C:Windowssystem32>Get-help *-msolserviceprincipal* While Windows PowerShell represents a great approach for administrators, having a graphical user interface that made it easy to grant your applications access with a few simple clicks is also required. Announced at the latest //BUILD/ conference108 in November 2012, the Windows Azure Authentication extension to Visual Studio 2012 enables toadd authentication with your Windows Azure AD directory tenant to any Web ASP.NET project directly in Visual Studio 2012. It not only creates the above service principal for the application but also establish the trust relationship between the application and the SSO endpoint of the directory as described in the next section. In other words, it completely automates the configurationof your application to authenticate users using your single Windows Azure Active Directory tenant. This extension is part of the ASP.NET Fall 2012 Update109. You can read more about this Windows Azure AD authentication extension part of the update in in the article W INDOWS AZURE 110 AUTHENTICATION . 6.2.2 Enable single sign-on (SSO) with Windows Azure AD The next step consists in establishing a trust relationship between the application and the SSO endpoint of the directory, which is one of the endpoints exposed by the applicative STS of Windows Azure AD. 108 //BUILD/: http://www.buildwindows.com/ 109 ASP.NET Fall 2012 Update: http://www.asp.net/vnext/overview/fall-2012-update/aspnet-fall-2012-update-release-notes 110 W INDOWS AZURE AUTHENTICATION: http://go.microsoft.com/fwlink/?LinkID=26794056 Active Directory from on-premises to the cloud
    • As described in section § 3.2.5.2EXPOSED APPLICATIVE STS PUBLIC ENDPOINTS, the applicative STS exposes metadata at the global URL: https://accounts.accesscontrol.windows.net/<domain name or tenant ID>/FederationMetadata/2007- 06/FederationMetadata.xml For example in our configuration: https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8- 29bbca5ac3df/FederationMetadata/2007-06/FederationMetadata.xml Any application that supports the WS-Federation or the SAML 2.0 protocols can consume these metadata to ease the trust configuration on its side. For example, .NET based applications typically leverage for that purpose the Windows Identity Foundation (WIF)111. WIF enables externalizing the identity logic from the application, improving developer productivity, enhancing application security, and enabling interoperability. WIF is now a part of the .NET Framework, and has been updated for .NET 4.5. For such an application, the Identity and Access Tool for Visual Studio 2012 112for example automates the establishment of the trust on the application side. It does this by updating the configurationfile web.config with the proper settings to enable the Windows Identity Foundation in .NET 4.5 and adding the necessary configuration for the identity provider you select: in this context your Windows Azure AD directory tenant based on the aforementioned metadata. The realm you specify in the wizard for your application should match the SPN value you enter when creating the application service principal (see previous section § 6.2.1PROVISION THE APPLICATION IN YOUR W INDOWS AZURE AD DIRECTORY TENANT) otherwise the token will be rejected by the application. Once configured, when a user signs in to the cloud application, such as by clicking a sign-in button, the users browser will be redirected to the sign-in service of Windows Azure AD (via a redirection through the applicative STS for the organization‘s realm). 111 Windows Identity Foundation: http://msdn.microsoft.com/en-us/library/hh377151.aspx 112 Identity and Access Tool for Visual Studio 2012: http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3- 795cb104066eActive Directory from on-premises to the cloud 57
    • Once signed in, the sign-in service of Windows Azure AD will return a sign-in response to the application (via a first redirection to the applicative STS for the customer‘s realm) such as in our configuration with the WS-Federation protocol: Redirection to https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8- 29bbca5ac3df/v2/wsfederation And then redirection to https://aadauthndemo.azurewebsites.net/ As previously mentioned, the Windows Azure Authentication extension to Visual Studio 2012 further simplifies the configuration and makes it really very simple to enable authentication for Web applications using Windows Azure AD. You just need to specify the Windows Azure AD domain and authenticate accordingly. The Windows Azure Authentication extension internally leverages the Windows Azure Authentication Library (AAL). Introduced in August 2012, Windows Azure Authentication Library (AAL) is a developer library that can help you to handle authentication in your rich client applications and in your services. It‘s a single assembly Microsoft.WindowsAzure.ActiveDirectory.dll containing only client-side features.58 Active Directory from on-premises to the cloud
    • Note: The assembly gives you access to the feature sets from both your Windows Azure AD directory tenants and your Windows Azure AD Access Control namespaces (see section § 7BRING YOUR OWN IDENTITY (BYOI) WITH WINDOWS AZURE AD ACCESS CONTROL). It enables you to prompt the user to authenticate against Windows Azure AD directory tenants, any on-premises WS-Federation identity providers such as AD FS 2.0 servers and all the identity providers supported by Windows Azure AD Access Control (Microsoft Account, Facebook, Google, Yahoo!, any OpenID provider, any WS- Federation provider). It also leverages service principal credentials for obtaining tokens for server to server service calls. All of those features are offered through a simple programming model. Your Windows Azure AD tenant already knows about many aspects of your scenario: the service you want to call, the identity providers that the service trusts, the keys that Windows Azure AD will use for signing tokens, and so on. AAL leverages that knowledge, saving you from having to deal with low level configurations and protocol details. For more details on how the library operates, please refer to the blog post WINDOWS AZURE AUTHENTICATION LIBRARY: A DEEP DIVE113 as well as the MSDN documentation114. You can pretty much get this done on any development platform, beyond.NET115, see examples on Java116 and PHP117 on GitHub to give you an idea of that. 6.2.3 Query yourWindows Azure AD directory tenant data using the Windows Azure AD Graph API While the token obtained during sign in (see previous section) contains user information such as a name and email address, your cloud application may need additional information such as group memberships or the name of the users manager. As already illustrated (see section § 3.2.1.4PROGRAMMING INTERFACE), such an information can be obtained from the organizations directory tenant by using the Directory Graph API, instead of LDAP as you will do with Active Directory on-premises. Before your cloud application can call the Directory Graph API, it must authenticate itself against (the applicative STS of) Windows Azure AD via the OAuth2.0 protocol (see section § 3.2.2STS) and obtain an access token to secure the calls to the Directory Graph API. 113 WINDOWS AZURE AUTHENTICATION LIBRARY: A DEEP DIVE: http://blogs.msdn.com/b/vbertocci/archive/2012/08/01/windows- azure-authentication-library-a-deep-dive.aspx 114 W INDOWS AZURE AUTHENTICATION LIBRARY: http://msdn.microsoft.com/en-us/library/jj573266.aspx 115 WAAD.WebSSO.ASPNET example:https://github.com/WindowsAzure/azure-sdk-for-dotnet-samples 116 WAAD.WebSSO.JAVA example: https://github.com/WindowsAzure/azure-sdk-for-java-samples 117 WAAD.WebSSO.PHP example: https://github.com/WindowsAzure/azure-sdk-for-php-samplesActive Directory from on-premises to the cloud 59
    • As described in section § 3.2.5.2EXPOSED APPLICATIVE STS PUBLIC ENDPOINTS, your cloud application should send a POST request to the applicative STS OAuth2 public endpoint for the target resource 00000002-0000-0000-c000-000000000000/directory.windows.net@<tenant ID> Where00000002-0000-0000-c000-000000000000 is the service principal ID for the Windows Azure Directory Graph service principal and <tenant ID> your Windows Azure AD directory tenant ID. The access token format being used here is aJSON Web Token (JWT)118. As outlined before, JWT is indeed a compact token format that is especially apt for REST-based development. Note: Windows Azure AD issues JWT‘s security token for a number of other important scenarios, including Office 365 integration scenarios and protection of 3rd party RESTful services. The recently released JSON Web Token Handler for the Microsoft .NET Framework 4.5119 greatly facilitates the use of the JWT capabilities of Windows Azure AD for these scenarios. The JWT handler indeed provides a collection of classes for deserializing, validating, manipulating, generating, issuing and serializing JWT tokens. It then enables the .NET developers to use the JWT format both as part of existing workloads (such as Web SSO) and within new scenarios (such as the REST-based solutions made possible by the Windows Azure Authentication Library (AAL)) with the same ease they‘d experience when using security token formats supported out of the box, such as SAML 2.0. For more details on how to use the JWT handler, including some concrete examples, please refer to the blog post INTRODUCING THE DEVELOPER PREVIEW OF THE JSON WEB TOKEN HANDLER FOR THE MICROSOFT .NET FRAMEWORK 4.5120. 118 JSON Web Token (JWT): http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 119 JSON Web Token Handler for the Microsoft .NET Framework 4.5: https://nuget.org/packages/Microsoft.IdentityModel.Tokens.JWT 120 INTRODUCING THE DEVELOPER PREVIEW OF THE JSON WEB TOKEN HANDLER FOR THE MICROSOFT .NET FRAMEWORK 4.5: http://blogs.msdn.com/b/vbertocci/archive/2012/11/20/introducing-the-developer-preview-of-the-json-web-token-handler-for-the- microsoft-net-framework-4-5.aspx60 Active Directory from on-premises to the cloud
    • The header of the JWT access token request consists of two fields that indicate the signing algorithm (―alg‖) and the format of the assertion (―typ‖). The implementation relies on the HMAC SHA-256 algorithm and the JWT token format. As a result, the JSON representation of the header is as follows:{"alg":"HS256","typ":"JWT"} The body of the JWT access token requestcontains a set of the desired claims as a JSON object that is base64url encoded, and notably: ―aud‖ that identifies the JWT audience that the JWT is intended for. It respects the following structure: 00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@<tenant ID> Where 00000001-0000-0000-c000-000000000000 is the applicative STS principal ID and <tenant ID> your Windows Azure AD directory tenant ID. ―iss‖that identifies your cloud application service principal ID.{ "aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@<tenant ID>", "iss": "<service principal ID>", …} The body is ―signed‖ with the HMAC SHA-256 algorithm using your cloud application service principal symmetric key to produce an HMAC. Once the request is successfully processed, you get back an HTTP 200 along with the requested JWT access token in the body. You need then to create a proxy class to call the Directory Graph API. Such a proxy class should: 1. Create an organization‘s tenant-specific Directory Graph endpoint, for example in our configuration: https://graph.windows.net/6d13453f-5d87-44d3-b7f8-29bbca5ac3df 2. Use the endpoint to instantiate the proxy to call the Directory Graph API 3. Add two HTTP headers for the Directory Graph endpoint, one (accept) that specified the format and another one (x-ms-dirapi-data-contract-version) that mentions the version of the Directory Graph API supported:Accept: Application/json ;odata=verbosex-ms-dirapi-data-contract-version: 0.8 4. Add the authorization HTTP header to the request withthe acquired JWT access token On Microsoft platforms, and as already mentioned, this can be easily achieved through the client-side library Windows Azure Authentication Library (AAL). For the developers using non-Microsoft platforms, they‘re able to access the directory for instance using their existing favorite open source stacks thanks to the RESTful based interface provided by the Directory Graph API and along with the JSON schematization by default (see post HOW TO OBTAIN JWT WITHOUT AAL121). 121 HOW TO OBTAIN JWT WITHOUT AAL: http://social.msdn.microsoft.com/Forums/en-US/WindowsAzureAD/thread/fc528ebe-96ac- 4614-b454-22cb573343bdActive Directory from on-premises to the cloud 61
    • Once the JWT token is obtained, it is simply passed to your Windows Azure AD directory as an HTTP header as part of the REST calls.You can then call the Directory Graph API to query the information you need in your application. The article GETTING STARTED W ITH W INDOWS AZURE ACTIVE DIRECTORY GRAPH122 illustrates how to create an application that uses the Directory Graph API. For additional information, see the MSDN documentation123 of the Windows Azure Active Directory Graph API. 6.3 Leverage your customer’s Windows Azure AD directory tenant with your SaaS application in the cloud Even if this is not mandatory, and as mentioned before, the vast majority of SaaS applications are multi-tenant applications. Multi-tenant applications are application instances accessed by multiple customers. Although there is only one application (regardless of the tangible aspects of how many VMs it is running on in the cloud, etc.), every tenant has the illusion of accessing its own exclusive instance, customized accordingly and isolated from any other concurrent user from other tenants. This is a very popular model thanks to the good utilization of the underlying resources; in the market right now you can find a wide array of solutions at different level of maturity.However, it is also a challenging one, as proper tenant isolation and provisioning flows can be non-trivial and the field is still relatively new, and the support of identity makes no exception to that with the identity management itself, the provisioning, the role management, the authentication, etc. In such a context, Windows Azure AD represents for ISVs a compelling free of charge service offering that can be easily integrated with theirs, rather than having to implement those capabilities into their platform. It‘s all the more so that such an integration can directly leverage the customer organization‘s Windows Azure AD directory tenant so that no prior synchronization is needed and the user‘s authentication is directly handled by Windows Azure AD for the considered tenant. Integrating with Windows Azure AD indeed allows your customers to sign up and sign in to your application using an identity management system that they already maintain, which reduces or eliminates the need to do separate identity management tasks with your application. This functionality gives your customers a more seamless experience when using your application, and it frees up the time spent doing management tasks. The page W INDOWS AZURE ACTIVE DIRECTORY: DEVELOP APPS FOR MULTIPLE ORGANIZATIONS124describes the steps required to develop multi-tenant applications that leverages Windows Azure AD. 122 GETTING STARTED WITH WINDOWS AZURE ACTIVE DIRECTORY GRAPH: http://msdn.microsoft.com/en- us/library/windowsazure/hh974487.aspx 123 W INDOWS AZURE ACTIVE DIRECTORY GRAPH: http://msdn.microsoft.com/en-us/library/hh974476 124 WINDOWS AZURE ACTIVE DIRECTORY: DEVELOP APPS FOR MULTIPLE ORGANIZATIONS: https://activedirectory.windowsazure.com/Develop/Multi-Tenant.aspx62 Active Directory from on-premises to the cloud
    • Developing a multi-tenant application that leverages Windows Azure AD basically entails six steps: 1. Get a Client ID for accessing Windows Azure AD 2. Enable customers to sign-up using Windows Azure AD 3. Enable customers to sign up for your application using Windows Azure AD 4. Enable single sign-on (SSO) with Windows Azure AD 5. Query a customers directory data using the Windows Azure AD Graph API 6. Publish your application 6.3.1 Get a Client ID for accessing Windows Azure AD This section describes how to get a Client ID and Client Secret after you have created a Microsoft Seller Dashboard account. To develop and publish applications that integrate with Windows Azure AD, you must sign up for a Microsoft Seller Dashboard125 account. 125 Microsoft Seller Dashboard: https://sellerdashboard.microsoft.com/Active Directory from on-premises to the cloud 63
    • Then you will be prompted to create an account profile126 as either a company or an individual. This profile is then used to publish applications on the Windows Azure Marketplace or other marketplaces, and it is required to generate a Client ID and Client Secret. A Client ID is the unique identifier for your application, and it is primarily used to identify an application for single sign-on or for authenticating calls to the Directory Graph API. The Client Secret is the 126 CREATE OR EDIT YOUR ACCOUNT IN THE MICROSOFT SELLER DASHBOARD: http://msdn.microsoft.com/en-us/library/jj552460.aspx64 Active Directory from on-premises to the cloud
    • associated key required when making requests using the Client ID. Both are required to integrate your cloud application with Windows Azure AD. The Client ID is used for single sign-on (SSO), and both the Client ID and Client Secret are used to obtain an access token to call the Directory Graph API. For more information about obtaining a Client ID and Client Secret, see CREATE CLIENT IDS AND SECRETS IN THE MICROSOFT SELLER DASHBOARD127. Note: New accounts are put into an "Account Pending Approval" state. This state does not prevent you from starting development – you can still create Client IDs as well as draft app listings. However, an app listing can only be submitted for approval once the account itself is approved. The submitted app listing will only be visible to customers in the Azure Marketplace after it has been approved. To generate a Client ID and Client Secret, you will need to enter the following properties in the Microsoft Seller Dashboard: App Domain: The hostname of your cloud application. This property must not contain any port number. During development, this property should be set to "localhost". App Redirect URL: The redirection URL where Windows Azure AD will send a response after user sign-in and when an organization has authorized your application. During development, this property should be set to https://localhost:<port number> As you can see, this is very similar to the information associated with a SPN for mono-tenant cloud application. 6.3.2 Enable customers to sign-up using Windows Azure AD Before a customer can use a multi-tenant application integrated with its organization Windows Azure AD directory tenant, a tenant administrator must authorize the application. This authorization process starts with a consent request from your application to Windows Azure, which generates a response that must be handled by your application. 6.3.2.1 Request consent for your application The following interaction typically demonstrates the process of requesting consent for your application: 1. The customer clicks a "sign up using Azure AD" link on a web page in your application. 2. You redirect the customer to the Windows Azure AD authorization page with your applications information appended to the request. 3. The customer either grants or denies consent for your application. 4. Windows Azure AD redirects the customer to your specified App Redirect URL. You specified this URL when you generated a Client ID and Client Secret on the Microsoft Seller Dashboard. The redirect request indicates the result of the consent request, including information about their tenant if consent was granted. To generate the redirect request in step 2 above, you must append query string parameters to the following URL for the Windows Azure AD authorization page: http://activedirectory.windowsazure.com/Consent/AuthorizeApplication.aspx The query string parameters are described below: 127 CREATE CLIENT IDS AND SECRETS IN THE MICROSOFT SELLER DASHBOARD: http://msdn.microsoft.com/en-us/library/jj552461.aspxActive Directory from on-premises to the cloud 65
    • ApplicationID (required): The Client ID value you received in the Microsoft Seller Dashboard. RequestedPermissions (optional): The permissions that must be granted to your application by the directory tenant. During development, these permissions are used for testing unpublished applications. For published applications, this parameter will be ignored. Instead, the requested permissions in your application listing will be used. There are three possible values for this parameter: a. DirectoryReader: Grants permission to read directory data, such as user accounts, groups, and information about your organization. Enables single sign-on (SSO). b. UserAccountAdministrator: Grants permission to read and write data, such as users, groups and information about your organization. Enables single sign-on (SSO). c. None: Enables single sign-on but disables access to directory data. The default value is "None" if the parameter is unspecified or incorrectly specified. The following is an example valid consent request URL: https://activedirectory.windowsazure.com/Consent/AuthorizeApplication.aspx?ApplicationId=6a433ae0 -a59c-4421-82e7-1a7eff790469&RequestedPermissions=DirectoryReader When you test your unpublished application, you will go through a consent experience that is similar to your customers. However, the authorization page for an unpublished application looks different than the authorization page for a published application. A published application instead displays your app name, logo, and publisher details, whereas an unpublished application does not. 6.3.2.2 Handle the consent response After a customer has granted or denied consent for your application, the Windows Azure AD sends a response to your applications App Redirect URL. This response contains the following query string parameters: TenantId: The unique GUID for the Windows Azure AD directory tenant that has authorized your application. This parameter will only be specified if the customer has authorized your application. Consent: The value will be set to ―Granted" if the application has been authorized, or ―Denied" if the request has been rejected.66 Active Directory from on-premises to the cloud
    • The following is an example valid response to the consent request that indicates the application has been authorized: https://localhost:44301/redirect.aspx&TenantId=6d13453f-5d87-44d3-b7f8- 29bbca5ac3df&Consent=Granted Your application will need to maintain context such that the request sent to the Windows Azure AD authorization page is tied to the response (and would reject any responses without an associated request). After a customer has granted consent to your application, its important to associate and store the newly created tenant in your application with the tenant ID returned by the consent response. This value will be used for future sign-in requests. On the customer‘s side, the related service principal is displayed on the services page in the (preview of the) Windows Azure AD Management portal (activedirectory.windowsazure.com/Admin/): 6.3.3 Enable single sign-on with Windows Azure AD The process starts with constructing a sign-in request to Windows Azure AD that authenticates a user to your application, then verifies in the sign-in response that the customer belongs to a tenant that has authorized your application. The sign-in request requires your Client ID from the Microsoft Seller Dashboard and the tenant ID of the customers organization. As you know, the sign-in request is specific to a Windows Azure AD directory tenant. When a customer signs in to your application, such as by clicking a sign-in button, the sign-in request must be generated by using your applications Client ID and the customers tenant ID. Clicking the button will navigate the users browser to the sign-in serviceof Windows Azure AD (via a redirection through the applicative STS for the customer‘s realm).Active Directory from on-premises to the cloud 67
    • Once signed in, the sign-in service of Windows Azure AD will return a sign-in response to the application (via a first redirection to the applicative STS for the customer‘s realm) such as in our configuration: Redirection to https://accounts.accesscontrol.windows.net/6d13453f-5d87-44d3-b7f8- 29bbca5ac3df/v2/wsfederation And then redirection to https://locahost:44301 When a customer signs in to your application, you indeed need to validate that their tenant has authorized your application. Their sign-in response contains a token, and the token contains properties and claims that can be inspected by your application. To perform this validation, you must get the Tenant ID from the Issuer property in the token and ensure that it exists in your list of customer/Tenant ID. 6.3.4 Access Windows Azure AD Graph While the token obtained during sign in contains user information such as a name and email address, your application may need additional information such as group memberships or the name of the users manager. As already illustrated (see section § 3.2.1.4PROGRAMMING INTERFACE), this information can be obtained from the customers directory tenant by using the Directory Graph API. Before your cloud application can call the Directory Graph API, it must authenticate itself and obtain an access token. Access tokens are obtained by authenticating your application with its Client ID and Client Secret. For that purpose, you need to a proxy class to call the Directory Graph API. Such a proxy class should: 1. Create an tenant-specific Directory Graph endpoint, for example in our configuration: https://graph.windows.net/6d13453f-5d87-44d3-b7f8-29bbca5ac3df 2. Use the endpoint to instantiate the proxy to call the Directory Graph API 3. Add two HTTP headers for the Directory Graph endpoint, one (accept) that specified the format and another one (x-ms-dirapi-data-contract-version) that mentions the version of the Directory Graph API supported:Accept: Application/json ;odata=verbose68 Active Directory from on-premises to the cloud
    • x-ms-dirapi-data-contract-version: 0.8 4. Add the authorization HTTP header to the request and acquire the JWT access token. On Microsoft platforms, and as already mentioned, this can be easily achieved through the client-side library Windows Azure Authentication Library (AAL). For the developers using non-Microsoft platforms, they‘re able to access the directory for instance using their existing favorite open source stacks thanks to the RESTful based interface provided by the Directory Graph API and along with the JSON schematization by default. You can then call the Directory Graph API to query the information you need in your application. For additional information, see the MSDN documentation128 of the Windows Azure Active Directory Graph API. 6.3.5 Publish your application Once you have thoroughly tested your application, you can create an application listing and publish your application listing on the Windows Azure Marketplace by following the instructions in the MSDN articleADD APPS AND PAYOUT INFORMATION IN THE MICROSOFT SELLER DASHBOARD129. When creating an application listing, you need to make sure to select the Windows Azure AD application type. Once you have finished creating your application listing, click "submit" to publish your application to the Windows Azure Marketplace. Youll need to wait until your application is approved before publication completes. These steps are performed on the Microsoft Seller Dashboard. The tutorial INTEGRATING MULTI-TENANT CLOUD APPLICATIONS WITH W INDOWS AZURE ACTIVE DIRECTORY130 covers all of the above steps and describes the application publishing flow with the Microsoft Seller Dashboard. 128 W INDOWS AZURE ACTIVE DIRECTORY GRAPH: http://msdn.microsoft.com/en-us/library/hh974476 129 ADD APPS AND PAYOUT INFORMATION IN THE MICROSOFT SELLER DASHBOARD: http://msdn.microsoft.com/en- us/library/jj552460.aspx 130 INTEGRATING MULTI-TENANT CLOUD APPLICATIONS WITH WINDOWS AZURE ACTIVE DIRECTORY: http://www.windowsazure.com/en- us/develop/net/tutorials/multitenant-apps-for-active-directory/Active Directory from on-premises to the cloud 69
    • 7 Bring Your Own Identity (BYOI) with Windows Azure AD Access Control With the notion of extended enterprise, organizations often interact with partners, and/or customers that don‘t have an enterprise identity provider of their own. To allow organizations to work with those people, and as an alternative to manage these users accounts directly within their solution, many enterprise applications want to enable people to sign-in using Web identity accounts that they already have. This has several advantages to the application developer: The application can seamlessly integrate with services provided by the Web identity provider, for example post on the user‘s Facebook wall, read their Facebook graph, read their LinkedIn graph, author a tweet, The user is less likely to forget their username/password, If the user forgets their password, the burden of helping the user is on the web identity provider, not the enterprise application. Windows Azure AD Access Control (formerly known as Windows Azure Access Control Service or ACS) provides centralized authentication and authorization by notably integrating with popular consumer (Web) identity providers, such as Microsoft Account, Google, Yahoo!, and Facebook while allowing the features of authentication and authorization to be factored out of your code. Windows Azure AD Access Controlenables authorization decisions to be pulled out of the cloud application and into a set of declarative rules that can transform incoming security claims into claims that applications and services understand. These rules are defined by using a simple and familiar programming model, resulting in cleaner code. Windows Azure AD Access Control can also be used to manage client permissions, thus saving the effort and complexity of developing these capabilities. Windows Azure AD Access Control is compatible with most popular programming and runtime environments, and supports many standard protocols including OpenID, OAuth2, WS-Federation, and WS-Trust as well as many standard security token format such as Simple Web Token (SWT),JWT, SAML 1.1, and SAML 2.0token formats. An OData-based management service provides programmatic access to the Windows Azure AD Access Control configuration. Windows Azure AD Access Control is a free of charge service.(See blog post W INDOWS AZURE ACTIVE DIRECTORY: MAKING IT EASIER TO ESTABLISH IDENTITY MANAGEMENT IN THE CLOUD131) For more information on Windows Azure AD Access Control, see the MSDN documentation on Windows Azure AD Access Control132. Initially release as a feature of the PaaS offering of Windows Azure, Windows Azure AD Access Control has to be seen as a feature of Windows Azure AD and the work of integrating the two together has already started even if it will take several iterations to make this happen completely but the planning and development work is well underway. 131 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 132 Windows Azure AD Access Control: http://go.microsoft.com/fwlink/?LinkID=27272470 Active Directory from on-premises to the cloud
    • As the first part of that work, the ACS namespace management experience has been merged into the Windows Azure Management portal (manage.windowsazure.com). To create an Access Control namespace, proceed with the following steps: 1. Click NEW in the Windows Azure Management portal. 2. Select APP SERVICES, ACCESS CONTROL, and then QUICK CREATE. 3. In the NAMESPACE field, type the name of the Access Control namespace that you want to create.To manage the newly created Access Control namespace, click the ACTIVE DIRECTORYnode in thenavigation bar on the left-hand side of the portal and click the name of your namespace. The base URL of your namespace is https://<Access Control namespace>.accesscontrol.windows.net/, for example https://idmgtaad.accesscontrol.windows.net/ for the above screenshot. You can alternatively navigate to the following URL: https://<Access Control namespace>.accesscontrol.windows.net/v2/mgmt/web For examplehttps://idmgtaad.accesscontrol.windows.net/v2/mgmt/web in our illustration.Active Directory from on-premises to the cloud 71
    • Note: For additional information on the integration within the management portal, see the blog post ACS IN WINDOWS AZURE MANAGEMENT PORTAL133. By having a Windows Azure AD Access Control namespace available,and as mentioned above, you can develop cloud(SaaS) application that can allow users to: Login with their organizational credentials stored in a Windows Azure AD tenant and leverage the capabilities already covered in this paper. (Windows Azure AD Access Control supports any WS-Federation identity provider) ; -or- Login in using popular consumer service identity providerssuch as Microsoft Account, Facebook, Yahoo!, Google, or any Open ID provider of your choice. The blog post PROVISIONING A W INDOWS AZURE ACTIVE DIRECTORY TENANT AS AN IDENTITY PROVIDER IN AN ACS NAMESPACE134 fully depicts how to accept both organizational identities from Windows Azure AD directory tenants and consumer identities from social providers such as Facebook. It provides detailed instructions on how to implement this scenario from end-to-end. When you create a namespace, you get (among other things) a number of endpoints rooted on the previous base URL and offering the ability to process and issue tokens using different protocols: https://<Access Control namespace>.accesscontrol.windows.net/v2/wsfederation for WS- Federation, https://<Access Control namespace>.accesscontrol.windows.net/v2/wstrust for WS-Trust, https://<Access Control namespace>.accesscontrol.windows.net/v2/Oauth2-13/ for OAuth2, Etc. For the former endpoint, Windows Azure AD Access Control exposes metadata on the following URL: https://<Access Control namespace>.accesscontrol.windows.net/FederationMetadata/2007- 06/FederationMetadata.xml 133 ACS IN WINDOWS AZURE MANAGEMENT PORTAL: http://blogs.msdn.com/b/windowsazure/archive/2012/12/21/acs-in-windows- azure-management-portal.aspx 134 PROVISIONING A WINDOWS AZURE ACTIVE DIRECTORY TENANT AS AN IDENTITY PROVIDER IN AN ACS NAMESPACE: http://blogs.msdn.com/b/vbertocci/archive/2012/11/07/provisioning-a-directory-tenant-as-an-identity-provider-in-an-acs- namespace.aspx72 Active Directory from on-premises to the cloud
    • For example https://idmgtaad.accesscontrol.windows.net/v2/FederationMetadata/2007- 06/FederationMetadata.xml in our illustration. These metadata follow the general syntax and semantics of metadataare defined in the OASIS W EB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2135. They can be consumed by the application to setup a trust between your application and your Windows Azure AD Access Control namespace as traditionally done with Web applications for example via the Identity and Access Tool for Visual Studio 2012 (see section § 6.2.2ENABLE SINGLE SIGN-ON (SSO) WITH W INDOWS AZURE AD). To integrate in turn your Windows Azure AD Access Control namespace with your Windows Azure AD directory tenant, this implies to create in your Windows Azure AD directory tenant a service principal for your Windows Azure AD Access Control namespace as described in section §6.2.1PROVISION THE APPLICATION IN YOUR W INDOWS AZURE AD DIRECTORY TENANT. 135 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.pdfActive Directory from on-premises to the cloud 73
    • The cinematic of Web authentication with Windows Azure AD Access Control is illustrated in the next scheme: The integrated and customizable Home Realm Discovery (HRD)feature of Windows Azure AD allows users to choose their trusted consumer/enterprise identity provider.74 Active Directory from on-premises to the cloud
    • 8 Ensure Information Protection and Control (IPC) with Windows Azure AD Rights Management Organizations of all sizes are challenged to protect a growing amount of valuable digital information against careless mishandling and malicious use. The increasing impacts of information theft and the emergence of new regulatory requirements to protect data emphasize the need for better protection of digital information. This digital information may include confidential e-mail messages, strategic planning documents, financial forecasts, contracts, dynamic, database-driven reports, and other sensitive information. The growing use of computers and devices to create and work with this information, the introduction of extensive connectivity through networks and the Internet, and the appearance of increasingly powerful computing devices have made protecting enterprise data a key security consideration. In addition to the threats of theft and mishandling, a growing list of regulatory requirements adds on top of the ongoing task of protecting digital files and information. For example: the financial, government, healthcare, and legal sectors are increasingly taxed by the need to better protect digital files and information due to emerging regulatory standards such as the Healthcare Insurance Portability and 136 137 Accessibility Act (HIPAA) and the Gramm-Leach-Bliley Act (GLBA) in the financial services market. Digital information must be better protected. Although no form of information will ever be completely risk-free from unauthorized use and no single approach will shield data from misuse in all cases, the best defense is a comprehensive solution for safeguarding information. As an essential part of an organizations overall security strategy, a solution for better Information Protection and Control (IPC) should provide the means to control how data is used and distributed beyond the use of simple access control. IPC is also known under various other names such as: data leakage prevention, data loss protection, content filtering, enterprise rights management, etc. An IPC solution should indeed help protect an organizations records and documents on the company intranet, as well as from being shared with unauthorized users. It should help ensuring that data is protected and tamper-resistant. When necessary, information should expire based on time requirements, even when that information is sent over the internet to other individuals. Such IPC capabilities (encryption, and usage rights expression and enforcement) are provided today by Windows Azure AD Rights Management, another feature under the ―umbrella‖ of Windows Azure AD. Windows Azure AD Rights Management provides the ability to enable the use of digital rights management technology for those organizations who choose to subscribe to Microsoft Office 365 Enterprise Preview as of writing. Windows Azure AD Rights Management provides software as a service (SaaS) for rights protecting content created and exchanged using Microsoft Office. By implementing a cloud- based rights management service running on Windows Azure, Rights Management helps providing an alternative to a full on-premises deployment of AD RMSfor customers seeking lightweight information protection capabilities within Microsoft Office 365 (Enterprise Preview) and other supporting (SaaS) applications. 136 Passed in 1996, HIPAA relates to healthcare coverage and, for example, how companies may use medical information. 137 Gramm-Leach-Bliley, also known as the Financial Services Modernization Act, was passed in 1999.Active Directory from on-premises to the cloud 75
    • Easy to setup and use as illustrated in the rest of is document, organizations can start protecting data within minutes of when they subscribe to Office 365. No on-premises infrastructure is required. With Windows Azure AD Rights Management, organization can protect their data by encrypting and managing usage rights, including Office documents, Exchange e-mail messages and attachments, and SharePoint document libraries across Office 365 services and applications. The technology is highly integrated into Office 2010, Office Professional (Plus) 2013 (or Office 365 ProPlus), Exchange Online, and SharePoint Online, and offers a seamless experience for both end users and administrators in document authoring, e-mail, and SharePoint publishing. Integrated within Exchange Online, SharePoint Online and Office, users use applications and services they are already familiar with today. Windows Azure AD Rights Management is initially focusing on customers whose e-mail (Exchange Online) and document workloads are stored in the cloud (SharePoint Online). It broadens rights management capabilities to a new set of customers and,in this context, it provides the core features needed for information protection. Windows Azure AD Rights Management enables secure collaboration by default within Office 365 tenants. In other words, it’s enabled for Office 365 cross-tenant collaboration and anyone with an Office 365 ID can consume rights-protected content. This capability is available in each workload for both cloud identities and federated identities (see section § 3.1TYPE OF IDENTITIES). Once you have established your organization with an account in Office 365, enabling Windows Azure AD Rights Management capabilities within the Office 365 just takes a few additional stepsto enable and configure for use. By default, Windows Azure AD Rights Management is disabled when you sign up for your Office 365 account in Microsoft Office 365. To enable Windows Azure AD Rights Management for use your Windows Azure AD directory tenant, you need to: Use Windows Azure AD Rights Management service from Windows PowerShell -or- Use the (preview of the) Windows Azure AD Management Portal by navigating to https://activedirectory.windowsazure.com/RmsOnline/Manage.aspx?BrandContextID=WAAD.76 Active Directory from on-premises to the cloud
    • Once activated, Windows Azure AD Rights Management can then be administered via Windows PowerShell and/or through the (preview of the)Windows Azure AD Management portal to provide an organization with the following benefits: Safeguard sensitive information: Applications and services such as Outlook 2010, Outlook 2013, Word 2010, Word 2013, Exchange Online, and SharePoint Online are enabled to help safeguard sensitive information138. Users and Administrators can define who can open, modify, print, forward, or take other actions with the information. Organizations are provided rights policy templatessuch as "Company - Confidential View Only",which can be applied directly to the information. Organizations can also create their own custom ad-hoc rights policy templates; Persistent protection with the data: Windows Azure AD Rights Management persists protection of Office data when at rest and in motion. Once information is locked, only trusted entities that were granted usage rights under the specified conditions (if any) can unlock or decrypt the information. Organizations remain in control of who has access to the data, whether in the cloud, on premise in the existing IT infrastructure, or at the individual‘s computer; Closer management of rights and conditions: Organizations and individuals can assign usage rights and conditions using Windows Azure AD Rights Management,which define how a specific trusted entity can use rights-protected content according to the business requirements. Examples of usage rights are: permission to read, copy, print, save, forward, and edit. Usage rights can be enhanced with conditions, such as rights expiration definition; Rights management with Office 365: Windows Azure AD Rights Management is integrated with Exchange Online, SharePoint Online, and other Office 2010/Office Professional Plus 2013 applications in order to provide rights management functionality across the Microsoft Office suite. Note: For additional information on Windows Azure AD Rights Management, see the online documentation139 on the Microsoft TechNet Web site as well as the several dedicated posts of the AD RMS Team Blog140. The white paper entitled INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH W INDOWS AZURE AD RIGHTS MANAGEMENT141available on the Microsoft Download Center, and also part of this series of document, provides detailed information on planning and configuring this feature of Windows Azure AD. Beyond a short description of the Windows Azure AD Rights Management service technology to introduce key concepts and requirements for the rest of the paper, and how it differs from on-premises Active Directory Rights Management Services (AD RMS),this paper further presents how to leverage, configure, and use Windows AzureAD Rights Management service technology in the organization‘s Windows Azure AD/Office 365 directory tenant(s), and more especially with both Microsoft Exchange Online and SharePoint Online in the cloud, and with Office locally. 138 Publishing rights-protected content requires the Professional version of Office. The Standard version of Office can only consume rights-protected content. 139 Windows Azure AD Rights Management: http://technet.microsoft.com/en-us/library/jj585024 140 AD RMS Team Blog: http://blogs.technet.com/b/rms/ 141 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=34768Active Directory from on-premises to the cloud 77
    • It contains step-by-step information on how to configure and use Windows Azure AD Rights Management to perform rights protection on your corporate content, as well as other details and requirements that you need to make a successful evaluation of Windows Azure AD Rights Management service technology in your environment. This concludes our ―tour‖ of Windows Azure AD and we hope that you now have some great ideas on how to leverage it in your organization.78 Active Directory from on-premises to the cloud