1. 1. Active Directory from on-premises tothe cloudMicrosoft FrancePublished: January 2013Version:1.0Author: Philippe Beraud (Microsoft France)Contributors/Reviewers:Arnaud Jumelet (Microsoft France), Christophe Leroux (MicrosoftCorporation), Philippe Maurent (Microsoft Corporation)Copyright 2013Microsoft Corporation. All rights reserved.AbstractIdentity management, provisioning, role management, and authentication are key services bothon-premises and through the (hybrid) cloud. With the Bring Your Own Apps (BYOA) for the cloudand Software as a Service (SaaS) applications, the desire to better collaborate a la Facebookwith the social enterprise, the need to support and integrate with social networks, which lead toa Bring Your Own Identity (BYOI) trend, identity becomes a service where identity bridges in thecloud talk to on-premises directories or the directories themselves move and/or are located in thecloud.Active Directory (AD) is a Microsoft brand for identity related capabilities. In the on-premisesworld, Windows Server AD provides a set of identity capabilities and services and is hugelypopular (88% of Fortune 1000 and 95% of enterprises use AD). Windows Azure AD is ADreimagined for the cloud, designed to solve for you the new identity and access challenges thatcome with the shift to a cloud-centric, multi-tenant world.Windows Azure AD can be truly seen as an IdentityManagementasaService (IDMaaS) cloudmulti-tenant service. This goes far beyond taking AD and simply running it within a VM inWindows Azure.This document is intended for IT professionals, system architects, and developers who areinterested in understanding the various options for managing and using identities in their (hybrid)cloud environment based on the AD foundation and how to leverage the related capabilities.AD,AD in Windows Azure and Windows Azure AD are indeed useful for slightly different scenarios.
2. 2. This document is provided as-is. Information and views expressed in this document, including URL andother Internet Web site references, may change without notice. You bear the risk of using it.Some examples depicted herein are provided for illustration only and are fictitious. No real association orconnection is intended or should be inferred.This document does not provide you with any legal rights to any intellectual property in any Microsoftproduct. You may copy and use this document for your internal, reference purposes. You may modifythis document for your internal, reference purposes. 2013 Microsoft Corporation. All rights reserved.Microsoft, Active Directory, Internet Explorer, SQL Server, Windows, Windows PowerShell, andWindows Server are trademarks of the Microsoft group of companies. All other trademarks are propertyof their respective owners
3. 3. Content 1 INTRODUCTION ............................................................................................................................. 1 1.1OBJECTIVES OF THIS PAPER .................................................................................................... 2 1.2NON-OBJECTIVES OF THIS PAPER ............................................................................................ 4 1.3ORGANIZATION OF THIS PAPER ................................................................................................ 4 1.4ABOUT THE AUDIENCE ............................................................................................................. 5 2 AD IN WINDOWS AZURE IS NOT WINDOWS AZURE AD! ......................................................... 6 3 WHAT IS WINDOWS AZURE AD? ................................................................................................ 9 3.1TYPE OF IDENTITIES ..............................................................................................................13 3.2ANATOMY OF W INDOWS AZURE AD .......................................................................................15 4 SYNCHRONIZE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON- PREMISES DIRECTORY .......................................................................................................................31 4.1SYNCHRONIZE YOUR DIRECTORY TENANT WITH ACTIVE DIRECTORY ON-PREMISES ...................32 4.2SYNCHRONIZE YOUR DIRECTORY TENANT WITH NON-AD DIRECTORIES ON-PREMISES ...............39 5 FEDERATE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY ..........................................................................................................................................42 5.1FEDERATE YOUR DIRECTORY TENANT WITH AN ON-PREMISES WS-* BASED IDENTITY PROVIDER45 5.2FEDERATE YOUR DIRECTORY TENANT WITH AN ON-PREMISES SAML 2.0 BASED IDENTITY PROVIDER .......................................................................................................................................46 6 ENABLE SINGLE SIGN-ON AND WINDOWS AZURE AD DIRECTORY SERVICES FOR CLOUD APPLICATIONS .......................................................................................................................48 6.1LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS SUBSCRIPTION .48 6.2LEVERAGE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR LOB APPLICATION IN THE CLOUD 51 6.3LEVERAGE YOUR CUSTOMERS W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR SAAS APPLICATION IN THE CLOUD ..............................................................................................................62 7 BRING YOUR OWN IDENTITY (BYOI) WITH WINDOWS AZURE AD ACCESS CONTROL ....70 8 ENSURE INFORMATION PROTECTION AND CONTROL (IPC) WITH WINDOWS AZURE AD RIGHTS MANAGEMENT .......................................................................................................................75Active Directory from on-premises to the cloud ii
4. 4. 1 Introduction The cloud is changing the way in which applications are written. Accelerated market cycles, multi- tenancy, pure cloud solutions and hybrid deployments, Web programmability, and the rise of devices (smartphones, tablets, etc.) as well as rich clients as consumption models offer without any doubt new opportunities. They also present at the same time new challenges for the key services both on-premises and through the (hybrid) cloud that represent the identity management, the provisioning, the role management, and the authentication. With:The Bring Your Own Apps (BYOA) for cloud and Software as a Service (SaaS) applications,The desire to better collaborate ala Facebook with the social enterprise,The need to support and integrate with social networks, which lead to a Bring Your OwnIdentity (BYOI) trend,Etc. Identity becomes a service where identity bridges in the cloud talk to on-premise directories or the directories themselves move and/or are located in the cloud (see Gartner report2013 PLANNING GUIDE: IDENTITY AND PRIVACY1). Identity, like compute and storage and networking, is an essential platform service. In the same way that identity played a critical role in the adoption of workgroup computing, identity services will play a critical role as organizations adopt the cloud. Organizations will use cloud services and applications created by ISVs, Platform as a Service (PaaS) cloud platforms for (Line of Business (LOB)) custom development, (as well as Infrastructure as a Service (IaaS) cloud environment for specific workloads to onboard the cloud for IT optimization reasons). Kim Cameron, Microsoft Chief Identity Architect, is convinced 2 that organizations will find they need new identity management capabilities to take full advantage of the cloud. They will also find that the most reliable and cost-effect way to obtain these capabilities is through Identity Management as a Service i.e. using the cloud to master the cloud. We can therefore predict with certainty that almost all organizations will subscribe to identity services that are cheaper, broader in scope and more capable than the systems of today. Enterprises will use these services to manage authentication and authorization of internal employees, the supply chain, and customers (including individuals), leads and prospects. Governments will use them when interacting with other government agencies, enterprises and citizens. Identity Management as a Service will require that we move beyond the models of identity management that have guided our thinking to date. A new service-based model will emerge combining more advanced capabilities with externalization of operations to achieve reduction in risk, effort and cost. 12013 PLANNING GUIDE: IDENTITY AND PRIVACY: http://www.gartner.com/id=2221415 2IDENTITY MANAGEMENT AS A SERVICE: http://www.identityblog.com/?p=1205Active Directory from on-premises to the cloud 1
5. 5. 1.1 Objectives of this paperActive Directory (AD) is a Microsoft brand for identity related capabilities. In the on-premises world,Windows Server Active Directory (Windows Server AD or simply AD) provides a set of identitycapabilities and services and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD).With the Infrastructure as aService (IaaS) capability in the cloud, such as the one offered by theWindows Azure platform, it becomes possible to deploy virtual machines (VM) that host AD domaincontroller.Whilst such an approach could be more than appropriate for specific workloads on IaaS platforms likea SharePoint environment, the Microsoft vision for the cloud consists in recreating a similar identityservice, but one that is optimized to support cloud applications and support modern protocols.Windows Azure Active Directory (Windows Azure AD or AAD) is AD reimagined for the cloud (see blog 3 4posts REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 1) , (PART 2) ), designed tosolve for you the new identity and access challenges that come with the shift to a cloud-centric, multi-tenant world.Windows Azure AD can be truly seen as an IdentityManagementasaService (IDMaaS) cloud multi-tenantservice that provides a robust and comprehensive cloud identity platformarchitected to operate inthe cloud with high scale, high availability, and integrated disaster recovery. This goes far beyondtaking AD and simply running it within a VM in a hosted environment such as the IaaS capability ofWindows Azure: Windows Azure AD is definitely different than running AD in a Windows Azure VM.Being optimized to support cloud services and supports modern protocols such as REST and OAuth2for mobile and consumer scenarios, Windows Azure AD typically provides identity and accesscapabilities for:Cloud-based applications on Windows Azure or in other clouds such Amazon Web Services(AWS),SaaS applications or multi-tenant applications such as the Microsoft Office 3655, which relieson it for its identity infrastructure,Mobile applications (with or without a back-end in the cloud like the one proposed through theWindows Azure Mobile Services6),Etc.Windows Azure AD utilizes the enterprise-grade quality and proven capabilities of Windows Server ADon-premises, so you can bring your applications to the cloud easily. It offers capabilities that can beleveraged to centralize the identity management needs of your solutions, whether they are cloud-based, hybrid, or even on-premises. Windows Azure AD is a complete offering that can help you totake advantage of your on-premises existing investment, to fully outsource to the cloud your usersmanagement and anything in between.By connecting your existing on-premises identity infrastructure to Windows Azure AD, you can managea hybrid environment that provides unified authentication and access management for both cloud andon-premises services and servers, eliminating the need to maintain new, independent cloud directories3 REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 1):http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining-active-directory-for-the-social-enterprise-part-1.aspx4 REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 2):http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining-active-directory-for-the-social-enterprise-part-2.aspx5 Microsoft Office 365 provides secure anywhere access to professional email, shared calendars, instant messaging (IM), videoconferencing, and document collaboration, see http://office365.microsoft.com/6Windows Azure Mobile Services: http://www.windowsazure.com/en-us/home/features/mobile-services/2 Active Directory from on-premises to the cloud
6. 6. and thus avoiding to recreate in the cloud identity silos for the applications with all the burden and hassle that comes with them in terms of operations. By leveraging the Windows Azure AD core directory and authentication capabilitiesand beyond handling authentication requests (e.g. to (cloud) services and applications user logins) that are sent from the user and/or devices to Windows Azure AD, you can enable:Single sign-on (SSO) across all your cloud applications as well as with your SaaSsubscriptions (provided that they support the integration with Windows Azure AD as it is thecase today for the Microsoft Online Services such as Office 365). SSO is the ability for a userto login in once and not have to re-enter their credentials each time when accessing different(cloud) or applications.It represents an important part of Windows Azure AD because it delivers a secure, yet simpleand seamless way for the corporate users to connect to their resources running somewhere inthe cloud7.Simple interoperability with your existing on-premises identity infrastructure based on WindowsServer Active Directory (AD) (or non-AD sources) through federation (and synchronization).Federation is the ability for Windows Azure AD and your existing on-premisesidentityinfrastructure to work togetherdelivering a federated SSO experience for corporate users whilekeeping user passwords on-premises and related policies on-premises.(Federation also givesthe option to require multifactor authentication for increased security.)Via the use of open standards such as the OASIS WS-Federation, WS-Trust, and SAML 2.0protocols, you can indeed quickly extend your existing on-premises directory authentication toyour cloud applications through Windows Azure AD. By using your existing on-premisesidentityinfrastructure as the authoritative identity provider, users are seamlessly authenticated to yourcloud applications with their existing corporate accounts. At the end, if you are an organization, Windows Azure AD provides your corporate users with a seamless, (federated) SSO experience across all your cloud applications, while simplifying the adoption of SaaS subscriptions, as well as the development of your own cloud applications. Conversely, if you are an ISV, you can leverage Windows Azure AD to reach a vast user population, which includes the ever-growing user base of the Office 365. As of today, since its introduction, Windows Azure AD has now processed 200 Billion authentications for 50 Million active user accounts. In an average week we receive 4.7 Billion authentication requests for users in over 420 Thousand different domains.8 Beyond the support of AD in Windows Azure, this paper provides you with a tour of Windows Azure AD to learn about its capabilities, interfaces, and to understand how it works in concert with Windows Server Active Directory (AD) (or non-AD sources). It discusses the possible options to perform federated provisioning and synchronization of identity information from Active Directory sources and non-AD directories sources to Windows Azure AD for the cloud and SaaS applications. This document also introduces the new Windows AzureDirectory Graph, a REST-based API that enables access to your Windows Azure AD directory tenant. It further presents the SSO and the Federation capabilities for your cloud (multi-tenant) applications and SaaS subscriptions. 7The best user experience for corporate users on the corporate network is provided with domain-joined machines. 8WINDOWS AZURE ACTIVE DIRECTORY PROCESSES 200 BILLION AUTHENTICATIONS - CONNECTING PEOPLE, DATA AND DEVICES AROUND THE GLOBE: http://blogs.msdn.com/b/windowsazure/archive/2012/11/27/windows-azure-active-directory-processes-200-billion- authentications-connecting-people-data-and-devices-around-the-globe.aspxActive Directory from on-premises to the cloud3
7. 7. Furthermore, with Windows Azure AD Access Control (formerly Windows Azure Access ControlServices or ACS), a unified federated SSO experience in the cloud can now be planned. With theongoing dissolution of the boundary between internal or at least organizational identities and externalor social identities, it indeed has out-of-the-box support for popular web identity providers includingMicrosoft Account (formerly known as Windows Live ID), Google, Yahoo!, and Facebook and anyOpen ID identity providers. The interaction between your Windows Azure AD directory tenant and yournamespaces in Windows Azure AD Access Control is also covered as part of this paper.Finally, a new capability for Information Protection and Control (IPC) is also introduced: WindowsAzure AD Rights Management.This paper can be seen a starting point for anyone challenged with identity, provisioning, federation orcloud based authentication.Special thanks toAlex Simons, Edward Wu,John Shewchuk,Kim Cameron, Stuart Kwan, VittorioBertocci, and Yannick Kristoficfor providing valuable content on thesetopics.1.2 Non-objectives of this paperThis document doesnt discuss the deployment and configuration of Windows Server AD on-premises.This document is intended as an overview document for AD in Windows Azure and Windows AzureAD, and as such, it doesnt provides neither in-depth description nor detailed step-by-step instructionson how to implement a specific covered feature or capability. Where necessary, it instead refers tomore detailed documents, articles, and blog posts that describe a specific feature or capability.Furthermore, this document is part of a document series on the identity and security features ofWindows Azure AD and Microsoft Office 365. It indeed completes the following whitepapers alreadyavailable on the Microsoft Download Center: MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.09; MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.010; INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH W INDOWS AZURE AD RIGHTS MANAGEMENT11; INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS12.1.3 Organization of this paperTo cover the aforementioned objectives, this document is organized by themes which are covered inthe following sections: AD IN W INDOWS AZURE IS NOT W INDOWS AZURE AD!; W HAT IS W INDOWS AZURE AD?;9 MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH AD FS 2.0: http://www.microsoft.com/en-us/download/details.aspx?id=2897110MICROSOFT OFFICE 365 SINGLE SIGN-ON (SSO) WITH SHIBBOLETH 2.0: http://www.microsoft.com/en-us/download/details.aspx?id=3546411INFORMATION PROTECTION AND CONTROL (IPC) IN OFFICE 365 PREVIEW WITH WINDOWS AZURE AD RIGHTS MANAGEMENT:http://www.microsoft.com/en-us/download/details.aspx?id=3476812 INFORMATION PROTECTION AND CONTROL (IPC) IN MICROSOFT EXCHANGE ONLINE WITH AD RMS: http://www.microsoft.com/en-us/download/details.aspx?id=301394Active Directory from on-premises to the cloud
8. 8. SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY;FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY;ENABLE SINGLE SIGN-ON AND W INDOWS AZURE AD DIRECTORY SERVICES FOR CLOUDAPPLICATIONS;BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZURE AD ACCESS CONTROL;ENSURE INFORMATION PROTECTION AND CONTROL (IPC) WITH W INDOWS AZURE AD RIGHTSMANAGEMENT. 1.4 About the audience This document is intended for IT professionals, system architects, and developers who are interested in understandingthe various options for managing and using identities in their (hybrid) cloud environment based on the AD foundation and how to leverage the related capabilities. AD, AD in Windows Azure and Windows Azure AD are indeed useful for slightly different scenarios. We recommend using Windows Azure AD in addition to on-premises AD (and AD in Windows Azure) in most cases as one doesnt replace the other.Active Directory from on-premises to the cloud 5
9. 9. 2 AD in Windows Azure is NOT Windows Azure AD!Microsoft announced13 in June 2012 the release of Windows Azure Virtual Machines14, an IaaS offeringin the Windows Azure platform in the cloud. Such an offering helps moving (part of) your business,applications and infrastructure to the cloud without changing existing code in their own unique way, attheir own unique speed.As its name clearly indicates, Windows Azure Virtual Machines provides support for virtual machines(VM).At a glance, a VM consists of a piece of infrastructure to deploy an application. Specifically, thisincludes a persistent operating system (OS) disk, possibly some persistent data disks, andinternal/external networking glue/connectivity to hold it all together. With these infrastructureingredients, itenables to create a platform where customers and partners can deploy existingapplications to take advantage of the reduced cost and ease of deployment offered in Windows Azure.VMs indeedgive you application mobility, allowing you to move your virtual hard disks (VHDs) back andforth between on-premises and the cloud. This enables you to migrateyour existing VM, to bring yourown customized Windows Server or Linux images, etc. As a common virtualization file format, VHDhas been adopted by hundreds of vendors and is a freely available specification15 covered under theMicrosoft Open Specification Promise (OSP) 16. The new version VHDX17 is also available as a freespecification covered under the OSP.While migration is a simple goal for any IaaS offering, the ultimate objective consists in beingable to run the exact same on-premises applications and infrastructure or part of them in thecloud and thus enabling onboarding and offboarding of workloads in order to improve theagility of the organization, i.e. its ability to capitalize on new opportunities and respond tochanges in business demands.Such a process might involve transferring an entire multi-VM workload, which may require virtualnetworks for hybrid connectivity to an on-premises deployment.(This can be seen as a cross-premisesdeployment.) This is where Windows Azure Virtual Networks comes into play.Windows Azure Virtual Network, another capability of the Windows Azure IaaS offering, lets youprovision and manage virtual networks (VNET) in Windows Azure. A VNET is the ability for theadministrator to create a logical boundary and place into it VMs. VNET also provides the capability ofconnecting Windows Azure Cloud Services18 (web roles and worker roles) that are in the same affinitygroup directly with them. Note: An affinity group is a container where you choose the location (Windows Azure region) and where you placed your Windows Azure resources. An affinity group represents also a convenient way to designate a Windows Azure data center region with the name of your choice. (As of this writing,13ANNOUNCING NEW WINDOWS AZURE SERVICES TO DELIVER HYBRID CLOUD:http://blogs.msdn.com/b/windowsazure/archive/2012/06/06/announcing-new-windows-azure-services-to-deliver-hybrid-cloud.aspx14 Windows Azure Virtual Machines: https://www.windowsazure.com/en-us/home/features/virtual-machines/15 VIRTUAL HARD DISK IMAGE FORMAT SPECIFICATION: http://go.microsoft.com/fwlink/p/?linkid=13717116 Open Specification Promise: http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx17 VHDX FORMAT SPECIFICATION V1.00: http://www.microsoft.com/en-us/download/details.aspx?id=3475018 Windows Azure Cloud Services: http://www.windowsazure.com/en-us/home/scenarios/cloud-services/6Active Directory from on-premises to the cloud
10. 10. Windows Azure Cloud Services can be added to an affinity group only at the time of creation of the service.). Windows Azure Virtual Networkprovides control over network topology, including configuration of IP addresses, routing tables and security policies. A VNET has its own private address space. The address space is initially IPv4 only, but could be extended to IPv6 in a future release. Windows Azure Virtual Networkallows securely extending on-premises networks into the cloud. With the ability to assign a private address range for its VNET, an organization can indeed treat it as an extension of its own corporate private network address space by establishing appropriate gates (VPN gateway) between their on-premises corporate private network and their virtual network(s) in Windows Azure. For that purpose, Windows Azure Virtual Networkenables to set up secure site-to-site connectivity between the organizations corporate VPN gateway and Windows Azure, and then to connect the organizations on-premises corporate network to the organizations Windows Azure tenant by using a VPN gateway along with the industry-standard IPSEC protocol. With such a capability, IT administrators can easily create a logically isolated private environment in Windows Azure, and connect it to the organizations on-premises IT infrastructure by using a secure VPN tunnel. Once set up, the isolated Windows Azure environment can be view as a natural extension of the on-premises corporate network. To synthetize, Windows Azure Virtual Network allows you to create private network(s) of VMs in your Windows Azure tenant environment that you can assign IP addresses to and then connect to your data center through a VPN gateway. Using this method, you can seamlessly connect on-premises (virtual) machines toVMs running in your Windows Azure tenant. The above capabilities enable the support of three key Microsoft workloads to deploy in the cloud: 1. Active Directory:An hybrid identity solution with extensive networking expectations; 2. SQL Server:A database workload with expectations for exceptional disk performance; 3. SharePoint Server: A large-scale, multi-tier application with a load-balanced front-end.Moreover, SharePoint Server deployments include Active Directory and SQL Server. These broad workload types canbe deployed either standalone or as part of a larger application, with or without on-premises connectivity. In the specific context of this paper, Windows Azure Virtual Machines and Windows Azure Virtual Network enable AD in Windows Azure a reality of today. The fundamental requirements for deploying Windows Server AD on VM(s) in Windows Azure differ very little from deploying it in VMs (and, to some extent, physical machines) on-premises. For example, if the domain controllers (DCs) that you deploy on WM are replicas in an existing on-premises corporate domain/forest, then the Windows Azure deployment can largely be treated in the same way as you might treat any other additional Windows Server AD site. That is, subnets must be defined in Windows Server AD, a site created, the subnets linked to that site, and connected to other sites using appropriate site-links. There are, however, a number of differences that are common to all Windows Azure deployments and some that vary according to the specific deployment scenario. The articles INSTALL A NEW ACTIVE DIRECTORY FOREST IN W INDOWS AZURE19 and GUIDELINES FOR DEPLOYING W INDOWS SERVER ACTIVE DIRECTORY ON W INDOWS AZURE VIRTUAL MACHINES20cover the fundamental differences and explained in great detail how successfully deploy and operate AD in Windows Azure. The former deals with a standalone configuration in the cloud whereas the latter 19INSTALL A NEW ACTIVE DIRECTORY FOREST IN W INDOWS AZURE: http://www.windowsazure.com/en- us/manage/services/networking/active-directory-forest/ 20GUIDELINES FOR DEPLOYING W INDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES: http://msdn.microsoft.com/en-us/library/windowsazure/jj156090Active Directory from on-premises to the cloud7
11. 11. highlights the requirements for deploying AD in a hybrid scenario in which Windows Server AD is partlydeployed on-premises and partly deployed on VMs in Windows Azure.Whatever the scenario is, and as you understand, AD in Windows Azure simply meansWindows Server AD running in your VMs in your Windows Azure tenant for the bestcompatibility with existing applications and for hybrid applications.AD in Windows Azure is NOT Windows Azure AD, a REST-based service that provides identitymanagement and access control capabilities for cloud applications.Wikipedia21 defines REST and RESTful service as follows:Representational State Transfer (REST) is a style of software architecture for distributedhypermedia systems such as the World Wide Web. The term Representational State Transfer wasintroduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Fielding is one of theprincipal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.Conforming to the REST constraints is referred to as being RESTful.A RESTful web service (also called a RESTful web API) is a simple web service implementedusing HTTP and the principles of REST. It is a collection of resources, with three defined aspects:the base URI for the web service, such as http://example.com/resources/the MIME type of the data supported by the web service. This is often JSON, XML orYAML but can be any other valid MIME type.the set of operations supported by the web service using HTTP methods (e.g., POST,GET, PUT or DELETE).With this definition in mind, lets considerwhat Windows Azure AD is all about in the next section.21 REST : http://en.wikipedia.org/wiki/Representational_State_Transfer8Active Directory from on-premises to the cloud
12. 12. 3 What is Windows Azure AD? Windows Azure Active Directory (Windows Azure AD or simply AAD) was introducedback in November 2011 as the cloud service that provides identity and access capabilities for services on Microsoft Office 365. John Shewchuk, the Microsoft Technical Fellow who plays a key role in getting our cloud identity offering engineered right, describes22 Windows Azure ADas follows: We have taken Active Directory, a widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a multi-tenant service with Internet scale, high availability, and integrated disaster recovery. Since we first talked about it in November 2011, Windows Azure AD has shown itself to be a robust identity and access management service for both Microsoft Office 365 and Windows Azurebased applications. In the interim, we have been working to enhance Windows Azure AD by adding new, Internet-focused connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms like Amazon Web Services, and technologies like Java. The easiest way to think about Windows Azure AD is that Microsoft is enabling an organizations Active Directory to operate in the cloud. Just like the Active Directory feature in the Windows Server operating system that operates within your organization, the Active Directory service that is available through Windows Azure is your organizations Active Directory. Because it is your organizations directory, you decide who your users are, what information you keep in your directory, who can use the information and manage it, and what applications are allowed to access that information. And if you already have on-premises Active Directory, this isnt an additional, separate copy of your directory that you have to manage independently; it is the same directory you already own that has been extended to the cloud. Meanwhile, it is Microsofts responsibility to keep Active Directory running in the cloud with high scale, high availability, and integrated disaster recovery, while fully respecting your requirements for the privacy and security of your information. As such, it provides easy-to-use, multi-tenant identity management services for applications running in the cloud and on any device and any platform with the Bring Your Own Device (BYOD) as a result of the Consumerization of IT. Windows Azure AD provides a multi-tenantcloud-based store for directory data and a core set of identity services including user logon processes, authentication and federation services. Windows Azure AD is able to scale to millions of customers and billions of objects. As of today, since its introduction, Windows Azure AD has now processed 200 Billion authentications for 50 Million active user accounts. In an average week we receive 4.7 Billion authentication requests for users in over 420 Thousanddifferent domains. This is a massive workload when you consider others in the industry are attempting to process 7B logins per year. A number of people are surprised to find out that every Office 365 customer already has a Windows Azure AD directory tenant. Windows Azure AD is indeed the directory used by Office 365 to store user identities and other tenant properties. 22REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 1): http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining-active-directory-for-the-social-enterprise-part-1.aspxActive Directory from on-premises to the cloud9
13. 13. If you are a Microsoft Office365 customer,you can then navigate to the (preview of the) Windows Azure AD Management Portal23 (activedirectory.windowsazure.com) and sign in with your organizational account. Windows Azure AD is used by a number of Microsoft cloud services today, and through the developer preview program it is possible to extend the usage of these directory tenants to other applications. Its also possible to obtain a standalone directory tenant through theprovisioning system.If you dont already have a tenant, you can set up your own custom Windows Azure AD standalone directory tenantfor free aspart of thedeveloper preview programbyfollowingthe linkhttp://g.microsoftonline.com/0AX00en/5. If you create a new tenant, the first user you generate as part of the sign-up process will also be an administrator. 23Preview of the Windows Azure AD Management Portal: https://activedirectory.windowsazure.com/10Active Directory from on-premises to the cloud
14. 14. The developer preview of Windows Azure AD is currently available as a free preview service. It is not intended for production use at this time. At general availability (GA), Windows Azure AD will remain available at NO charge. (See blog post W INDOWS AZURE ACTIVE DIRECTORY: MAKING IT EASIER TO ESTABLISH IDENTITY MANAGEMENT IN THE CLOUD24) Same is true for Windows Azure AD Access Control (see section 7BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZURE AD ACCESS CONTROL). The rest of this chapter describes the main characteristics of Windows Azure AD that organizations and cloud applications can leverage, and the functionalities that Windows Azure AD provides for the users of these applications and for the developers of these applications to be successful. As of today, Windows Azure AD is still in preview and keeps continuing to receive enhancements that make Windows Azure AD even more useful for IT professionals and developers. Note: Please make sure you periodically check the Windows Azure Active Directory community forum 25 as well as the MSDN Windows Azure blog26 for notification of upcoming enhancement and changes that relate to Windows Azure AD. For a short look back at the recent enhancements, the starting point since the initial introduction in 2011 is the announcement of the developer preview in June 2012 (see blog post ANNOUNCING THE DEVELOPER PREVIEW OF W INDOWS AZURE ACTIVE DIRECTORY27). New components have been introduced with the developer preview in order to make it easy for developers to take advantage of Windows Azure AD for adding single sign-on and directory management capabilities to Web applications, rich clients and RESTful services. Specifically, the following capabilities were announced: Web Single Sign-On (SSO) for cloud and SaaS applications with the support of the WS- Federation protocol (see section 6ENABLE SINGLE SIGN-ON AND W INDOWS AZURE AD DIRECTORY SERVICES FOR CLOUD APPLICATIONS), Windows Azure Active Directory Graph, a RESTful API to programmatically access identity relationships in the Windows Azure AD directory to build rich applications (see section 3.2.1.4PROGRAMMING INTERFACE). The Microsoft TechEd US 2012 session recordingsA LAP AROUND W INDOWS AZURE ACTIVE DIRECTORY28and DIRECTORY GRAPH API: DRILL DOWN29 provide an introduction to these capabilities. In August 2012 was introduced the Windows Azure Authentication Library (AAL), a new capability in the developer preview (see blog post INTRODUCING A NEW CAPABILITY IN THE W INDOWS AZURE AD 24 W INDOWS AZURE ACTIVE DIRECTORY: MAKING IT EASIER TO ESTABLISH IDENTITY MANAGEMENT IN THE CLOUD: http://blogs.msdn.com/b/windowsazure/archive/2012/11/30/windows-azure-active-directory-making-it-easier-to-establish-identity- management-in-the-cloud.aspx 25Windows Azure Active Directory community forum: http://social.msdn.microsoft.com/Forums/en-US/WindowsAzureAD/ 26Windows Azure blog: http://blogs.msdn.com/b/windowsazure/ 27ANNOUNCING THE DEVELOPER PREVIEW OF WINDOWS AZURE ACTIVE DIRECTORY: http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active- directory.aspx 28 A LAP AROUND WINDOWS AZURE ACTIVE DIRECTORY: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA209 29DIRECTORY GRAPH API: DRILL DOWN: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA322Active Directory from on-premises to the cloud11
15. 15. DEVELOPER PREVIEW: THE W INDOWS AZURE AUTHENTICATION LIBRARY30). Whilst developers can of course write directly to the standards based protocols supported in Windows Azure AD, this library is another option available for developers who are looking for a faster and simpler way to take advantage of Windows Azure ADin high value scenarios, including the ability to secure access to your cloud applications (see section 6.2.2ENABLE SINGLE SIGN-ON (SSO) WITH W INDOWS AZURE AD). In September 2012, three major enhancements have been made available to the developer preview as announced in the blog post MORE ADVANCES IN THE W INDOWS AZURE ACTIVE DIRECTORY DEVELOPER PREVIEW31:The ability to create a standalone Windows Azure AD directory tenant,A preview of the Windows Azure AD Management portal that gives a graphical user interfaceto manage the directory tenant,Write support in the Windows Azure Active Directory Graph API.Note:This latter update includes support for create, update, delete operations for users, groups, and groupMembership, user license assignments, contact management, and set JavaScript Object Notation(JSON) as the default data format, which is of interest for instance for mobile applications. Lastly, in November 2012, and as described on the blog post ENHANCEMENTS TO W INDOWS AZURE ACTIVE DIRECTORY PREVIEW32, the following enhancements have been added:Added graphical user interfaces for registering your cloud application in a directory tenant,Support for the SAML 2.0 protocol for Web SSO,Sign out support for the WS-Federation protocol in Web SSO,Differential query in the Windows Azure Active Directory Graph API,The ability to federate Windows Azure AD directory tenants with Windows Azure AD AccessControl namespaces (see section 7BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZUREAD ACCESS CONTROL),And an updated version of the Windows Azure Authentication Library (AAL). Even more Windows Azure AD functionalities will be integrated this year for your identities in the cloud. The rest of the document provides a description for all of the above. 30 INTRODUCING A NEW CAPABILITY IN THE WINDOWS AZURE AD DEVELOPER PREVIEW: THE WINDOWS AZURE AUTHENTICATION LIBRARY: http://blogs.msdn.com/b/windowsazure/archive/2012/08/01/introducing-a-new-capability-in-the-windows-azure-ad-developer- preview-the-windows-azure-authentication-library.aspx 31 MORE ADVANCES IN THE WINDOWS AZURE ACTIVE DIRECTORY DEVELOPER PREVIEW : http://blogs.msdn.com/b/windowsazure/archive/2012/09/12/more-advances-in-the-windows-azure-active-directory-developer- preview.aspx 32 ENHANCEMENTS TO W INDOWS AZURE ACTIVE DIRECTORY PREVIEW : http://blogs.msdn.com/b/windowsazure/archive/2012/11/07/enhancements-to-windows-azure-active-directory-preview.aspx12 Active Directory from on-premises to the cloud
16. 16. 3.1 Type of identities Windows Azure AD enables a customer to be able to start using its services with no on-premises footprint. Accordingly, Windows Azure AD provides for hosted (cloud) identities where customers can create users, groups and other principals for their organization.The cloud identities (Cloud ID) are mastered in Windows Azure AD. With cloud identities,users receive, for signing into Windows Azure AD and any services and applications that are integrated into Windows Azure AD (see section 6ENABLE SINGLE SIGN-ON AND W INDOWS AZURE AD DIRECTORY SERVICES FOR CLOUD APPLICATIONS),cloud credentials (that are separate from other desktop or corporate on-premises credentials if any). Many enterprise customers will want to federate their on-premises identity infrastructure with Windows Azure AD to establish a hybrid corporate identity platform.Its a more sophisticated approach in the sense that it requires setting up a federation between their on-premises identity infrastructure and Windows Azure AD(see section 5FEDERATE YOUR WINDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY).Users can then sign into Windows Azure AD or any services and applications that are integrated into Windows Azure AD using their own corporate credentials. The users IDs are mastered on-premises in the identity infrastructure and synchronized to the Windows Azure AD in the form of federated identities (federated ID). Users can gain access to Windows Azure ADor any services and applications that are integrated into Windows Azure AD by authenticating to their Windows Azure AD user accounts, either through a prompt to provide valid credentials or through a federated single sign-on (SSO) process. Once authenticated, users identities refer to the user names associated with the Windows Azure AD accounts. Considering the above, we have three authentication/deployment model types available: 1. Cloud identities; 2. Cloud identities + directory synchronization; 3. Federated identities + directory synchronization. Through directory synchronization, organizations can keep their existing on-premises identity infrastructure synchronized with their Windows Azure AD directory tenant. The directory synchronization is discussed in section 4SYNCHRONIZE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR on-premises directoryfor larger organizations that may want to streamline the provisioning and the synchronization of identities. The above type of identity (cloud vs. federated) affects the user experience, administrative requirements, deployment considerations, and capabilities using Windows Azure AD. The following is the simplified breakdown of the experience:User experience with cloud identities:Users sign in with their cloud identity. Cloud identitiesare authenticated using traditional challenge/response, where users type in their user nameand password.Authentication happens in the cloud. Users are always prompted for credentials.As mentioned above, users may have two IDs, i.e.Cloud ID for Windows Azure AD itself andthe services and applications in the cloud that leverage Windows Azure AD and potentially onefor accessingon-premises services. Consequently, users are prompted for credentials evenwhen logged into their on-premises infrastructure (AD or non-AD sources) when accessingWindows Azure AD itself and the services and applications in the cloud that leverage WindowsAzure AD.User experience with federated identities: Users sign in with corporate ID for access toonline and corporate services. In other words, they are authenticated transparently using theon-premises identity infrastructure when accessing Windows Azure AD itself and the servicesand applications in the cloud that leverage Windows Azure AD. Authentication happens on-Active Directory from on-premises to the cloud13
17. 17. premises against the organizations identity provider servers and users get true SSO.Furthermore, multifactor authentication (MFA) can be utilized if it is deployed on-premises.Important note:Multifactor authentication (MFA) support is available is not available for clients other than Webbrowsers. Other clients that do not have the capability to prompt users for strong authenticationcredentials can therefore not be supported. Strong authentication must only be applied to the passivefederation endpoints on on-premises identity provider servers, as other clients will otherwise not beable to connect.Administrator experience with cloud identities:Organizations administrators managethepassword policy both in the cloud and on-premises. The cloud identities password policy isstored in the cloud with Windows Azure AD. Password reset has to be managed for on-premises and the cloud identities and, hence, the users have to change the password as perthe policy for both. Finally, there is no MFA integration.Note:With the recent acquisition of PhoneFactor33 in October 2012, MFA support could be introduced inWindows Azure AD in the future. As Bharat Shah, corporate vice president, Server and Tools Divisionfor Microsoft, said, The acquisition of PhoneFactor will help Microsoft bring effective and easy-to-usemultifactor authentication to our cloud services and on-premises applications.By leveraging a device nearly every user already has a phone PhoneFactor enables rapiddeployment of MFA across a wide range of applications. It already works with many Microsoftproducts and services, including Outlook Web Access and Internet Information Services, andinteroperates with Active DirectoryAdministrator experience with federated identities:Organizations administratorsmanagethe password policy on-premises only and hence do not need to separately worryabout password reset for federated identities. The organizations identity infrastructure storesand controls the password policy. Password reset occurs for on premise IDs only. Eventually,several on-premises MFA integration options are offered. While the federated identities + directory synchronization model may require some server investments and deeper architectural decision making, it does allow support for richer federated single sign-on with the corporate credentials, integration with on-premises MFA and a configurable password policy. It enables organization to adequately manage their hybrid environment. Since organizations usually want to pilot/test something new with a small number of users and then enable it for their full end user population, Windows Azure AD supports staged federation to allow a customer to incrementally deploy or rollback federation. For the moment, lets see how Windows Azure AD supports both cloud identities and federated identities. 33MICROSOFT ACQUIRES PHONEFACTOR: http://www.microsoft.com/en-us/news/Press/2012/Oct12/10-04MFAPR.aspx14Active Directory from on-premises to the cloud
18. 18. 3.2 Anatomy of Windows Azure AD At the simplest level, Windows Azure AD (core directory and authentication) is a scalable directory infrastructure that provides for storage, data access, replication and synchronization, and security token services (STS). Below is a conceptual diagram showing the public interfaces, and the management surface: 3.2.1 Core Directory The core directory represents the heart of Windows Azure AD. As a directory (service in the cloud) and with the objective to eliminate the need of an application-specific store for notably identity information, Windows Azure AD aims at supporting data of common interest across the vast majority applications whether they are cloud, SaaS, mobile, etc. applications as well as the possible relationships between those data. 3.2.1.1 Data model and schema Users and groups are typically good examples where organizations want to create them once and reuse them across their applications or the ones for which they buy a subscription. Information in the directory should generally have the following characteristics:Public in the sense of something that is useful to share across the organization, and notsomething private like the salary attribute of a user object,Mostly static over the time, and not changed often,Small, generally pointers to information vs. the information itself. Unsurprisingly, Windows Azure AD follows the Windows Server AD data model with suitable changes for cloud use. The core data model is as follows:The directory is divided into directory contexts, one per tenant plus a system context. Eachdirectory context has an immutable,globally unique, non-reusable GUID-valued identifier acontext ID and contains a set of entities (or objects) and association (or links) between theentities. Each object or link belongs to exactly one context.Active Directory from on-premises to the cloud 15
19. 19. Each object has anobject class or type (ObjectType): User, Contact, Group, etc. and an immutable,globally unique, non-reusable GUID-valued identifier, i.e. an object ID (ObjectId). An object contains a set of properties: DisplayName, UserPrincipalName, JobTitle, Department, TelephoneNumber, etc. Each property has a name and, if set, contains a value or a set of values. The object class determines which properties may appear on the object, and the property determines the type (string, binary, integer, structure, etc.) and multiplicity of the values. An object may contain a set of navigationproperties that each corresponds to a link(or association). A link is a directional, typed relationship from one object to another object, all in the same context. The type of the link is its link class: Manager, DirectReports, MemberOf, Members, etc. Links significantly contribute to establish an enterprise social graph as34 discussed in the John Shewchuk blog post . Links maintain referential integrity: deleting the source or target object of the relationship implicitly deletes the link. Object (respectively link) instances may be group into set of The Windows Azure AD directory schema defines the properties, object classes, and link classes; much of it is a subset of standard LDAP v3 (and Windows Server AD) schemas. It however differs from that of LDAP directories in the following ways: Unlike entries in an LDAP directory, objects do not have distinguished names and are not arranged into a distinguished multi-level hierarchy. Objects can be interpreted as having various hierarchical relationships based on links and property values. The directory does not support object class inheritance. In Windows Server AD, such a capability was used in very limited ways but added significant complexity to the system. The Windows Azure AD directory schema is fixed for a specific version of Windows Azure AD, and, in particular for scaling reasons, it is not per-tenant. The Windows Azure AD directory schema may evolve with versions of Windows Azure AD as it was the case for the Windows Server AD directory schema over the time since its first introduction in the early 2000. Generally speaking, applications that consume directory information tend to fall into the following threeclasseswith respect to directory extensibility requirements.1. A first class of application that corresponds to the vast majority doesnt need to extend the directory and has no extensibility requirements to address.2. A second class of applications has very simple extensibility needs where they need to publish some information about a directory entity, such as a user, to other applications. As of today,a built-in extensibility mechanism addresses this kind of extensibility requirements in the specific and historical context of Microsoft Online Services applications. A similar mechanism for third- party applications may be introduced in the future.3. The final class of applications is the one without any surprise that has extensive extensibility needs. They may maintain significant information about users and other objects, and also may have complex query needs based on properties and links. These queries may be in the mainline high volume path of the application. Exchange is an example of such an application. The use of an application-specific local store for extensibility is probably the best option in this case. With the advent of the cloud, storage capabilities are widely available through services such as Windows Azure Storage and Windows Azure SQL database. An application that falls into this model usually maintains its own tables in a storage service. A typical model might be that rows in the table represent Windows Azure AD directory entities about which the 34REIMAGING ACTIVE DIRECTORY FOR THE SOCIAL ENTERPRISE (PART 2): http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining-active-directory-for-the-social-enterprise-part-2.aspx16 Active Directory from on-premises to the cloud
20. 20. application maintains its information. One of the columns of the table would be a key thatidentifies the entity in the directory (i.e. the join key). The other columns represent application-specific information. The application can make use of the differential query capabilitysupported by the directory to manage the lifecycle of the rows in its tables utilizing the joinkey. 3.2.1.2 Directory tenants As most people know, the forest in Windows Server AD represents the administrative boundary. Likewise, the directory tenant in Windows Azure AD represents an administrative boundary from a customer viewpoint. As a forest contains one or multiple domains, a directory tenant contains one or multiple domains. After signing up for Windows Azure AD (or for a Microsoft Online service that leverage Windows Azure AD such as Microsoft Office 365), the only domain associated with your subscription account and created with the directory tenant is the .onmicrosoft.comdomain chosen during registration, for exampleidmgt.onmicrosoft.com. This is the default domain.When you create a new user, the users sign-in name and email address are assigned to this default domain. You can off course add one or more customs domains to a directory tenant rather than retaining the onmicrosoft.com domain, and then assign users to sign in with any of the validated domains. For that purpose, as you can declare enterprise administrator(s) for the forest, there are similarly tenant wide administrators for the organizations directory tenant. Tenant administrators can register multiple DNS domain names for theWindows Azure AD tenant of the organization, for example demo.idmgt.archims.fr.The directory allows a tenant administrator to register a DNS domain only after he proves that his organization owns the DNS namespace in the public internet DNS. As of this writing, you can host up to 600 registered domains in your directory tenant, each represented by a different DNS namespace. A domain can be either a cloud (standard) domain or a federated (single sign-on) domain, meaning that all users on a domain MUST use the same identity system: either cloud identity or federated identity (see section 3.1TYPE OF IDENTITIES). For example, you could have one group of users that only needs a cloud identity because they dont have an on-premises account and/or access on-premises systems, and another group of users who have an on-premises account and/or use cloud applications and on-premises systems. You would use add two domains to the directory tenant, such as contractors.demo.idmgt.archims.fr and fte.demo.idmgt.archims.fr, and only set up the federation for one of them (see section 5FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY). A domain can be converted from cloud to federated, or from federated to cloud. 3.2.1.3 Management surface Windows Azure AD allows administrators to manage information in it through:The use of the graphical user interface thanks to a Web-based management portal.Active Directory from on-premises to the cloud 17
21. 21. Note:When you navigate to the (preview of the) Windows Azure AD Management Portal(activedirectory.windowsazure.com), you will be potentially immediately redirected to the WindowsAzure AD sign-in service for authentication. The Windows Azure AD sign-in service is part of the(logical) security token service (STS) of Windows Azure AD (see later in document in section 3.2.2STS). A set of Windows PowerShell cmdlets, that allows for scripting frequent operations: the Microsoft Online Services Module for Windows PowerShell. (On-premises management tools used to manage information in an on-premises directory and then synchronized into Windows Azure AD with the directory synchronization.) A Windows PowerShell "module" is a package that contains Windows PowerShell commands, cmdlets, providers,functions, variables,and aliases.The MicrosoftOnlineServicesModuleforWindowsPowerShellisa separate installation package (AdministrationConfig-en.msi) for 32-bit35 or 64-bit36 Windows platforms, which includes cmdlets specifically designed for Windows Azure AD/Office 365 administration. It indeed enables you to connect a Windows PowerShell command shell to your Windows Azure AD directory tenant and then to perform directory-oriented operations. The cmdlets currently layer on the same SOAP based task oriented interface that the Web management portal uses for accessing the directory.Note:Windows PowerShellis a task-based command-line shell and scripting language that isdesigned for system/service administration and automation. It uses administrative tasks calledcmdlets. Each cmdlet has required and optional arguments, called parameters, that identify whichobjects to act on or control how the cmdlet performs its task. You can combine cmdlets in scripts toperform complex functions that give you more control and help you automate the administration ofWindows, applications and online services in the cloud. It has become a common way to manage thelatest generation of Microsoft products and services.For more information about Windows PowerShell, please see the Windows PowerShell Web site37, theWindows PowerShell online help38, and the Windows PowerShell Weblog39Windows PowerShellSoftware Development Kit (SDK)40 that includes a programmers guide along with a full reference. Administrative privileges are needed on the local computer in order to install the Microsoft Online Services Module for Windows PowerShell. As an illustration, lets seehow to create custom domains within a directory tenant with the cmdlets provided by this module. 35Microsoft Online Services Module for Windows PowerShell (32-bit version): http://go.microsoft.com/fwlink/?linkid=236345 36Microsoft Online Services Module for Windows PowerShell (64-bit version): http://go.microsoft.com/fwlink/p/?linkid=236293 37Windows PowerShell Web site: http://www.microsoft.com/powershell 38Windows PowerShell online help: http://technet.microsoft.com/en-us/library/bb978526.aspx 39Windows PowerShell Weblog: http://blogs.msdn.com/powershell 40Windows PowerShell SDK: http://msdn2.microsoft.com/en-us/library/aa830112.aspx18Active Directory from on-premises to the cloud
22. 22. The New-MsolDomain cmdlet enables to create a standard (managed) domain based on the specified DNS domain names. After running this command, you have to prove that your organization owns the DNS namespace in the public internet DNS. For that purpose, you need to use the Get-MsolDomainVerificationDns cmdlet in order to get the DNS record information required to create for the new managed domain. To prove that you control the domain, you then use the output of the command to create a CNAME record in the authoritative DNS server for the DNS domain used previously. Windows Azure AD indeed uses a DNS record that you create at your registrar to confirm that you really own the domain. For additional information, please refer to the Microsoft TechNet articles ADD YOUR DOMAIN41and VERIFY A DOMAIN AT ANY DOMAIN NAME REGISTRAR42. Once done, you finally prove your control of the DNS namespace by running the Confirm- MsolDomain cmdlet. Note: The custom domain can also be added from the (preview of the)Windows Azure AD Management Portal as well. The steps would be identical and the domain would still have to be verified in the same way. Similarly, you can use the New-MsolFederatedDomain cmdlet to create of custom federated (single sign-on) domain in your directory tenant. Finally, the Set-MsolDomainAuthentication cmdlet enables to convert a standard domain into a single-sign on domain. Note: For more information about the available cmdlets and how to use theme, see the Microsoft TechNet articles USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR WINDOWS AZURE AD TENANT43and WINDOWS POWERSHELL CMDLET DESCRIPTIONS44. For more information about a cmdlet that you can run in Windows PowerShell, at the Windows PowerShell command prompt, type Get-help and the name of the cmdlet. After creating one or multiple custom domains, you can verify that the domains were added correctly via the (preview of the) Windows Azure AD Management Portal. 41 ADD YOUR DOMAIN:http://technet.microsoft.com/en-us/library/hh969247.aspx 42 VERIFY A DOMAIN AT ANY DOMAIN NAME REGISTRAR: http://technet.microsoft.com/en-us/library/jj151803.aspx 43USE WINDOWS POWERSHELL CMDLETS TO MANAGE YOUR W INDOWS AZURE AD TENANT: http://technet.microsoft.com/en- us/library/jj151805 44 WINDOWS POWERSHELL CMDLET DESCRIPTIONS: http://technet.microsoft.com/en-us/library/jj151835.aspxActive Directory from on-premises to the cloud 19
23. 23. In the above screenshot, idmgt.onmicrosoft.com is the default domain created with the directory tenant. The federated (single sign-on) domains demo.idmgt.archims.fr and sponline.demo.idmgt.archims.fr have been successfully verified via the provided DNS information whereas thefederated (single sign- on) domain idmgt.demo still needs to be verified. When a domain is federated, you will no longer have the option to add the domain suffix to the user accounts. The users will need to be created on-premises in order for them to have the federated domain name available to them. You can still create accounts directly in the cloud, but they cannot have the federated domain name assigned to them unless they are created on-premises. Remember that the deployment model is federated identities + directory synchronization. Moreover, and as expected, when the user signs-in to Windows Azure AD with his federated account, hesinvited to authenticate on the on-premises identity infrastructure. If single sign-on is correctly set up (see section 5FEDERATE YOUR W INDOWS AZURE AD DIRECTORY TENANT WITH YOUR ON-PREMISES DIRECTORY), you will indeed notice that the user cannot even type a password in the login Web page of the sign-in service of Windows Azure AD. Password will be indeed shaded. The user will beinstead provided with a link to the declared on-premises identity provider. You will see the following message: You are now required to sign at , i.e. the Sign in at Demo.idmgt.archims.fr link from the screenshot hereafter. This is a redirect link to send the user to the on-premises identity provider passive endpoint.20Active Directory from on-premises to the cloud
24. 24. 3.2.1.4 Programming interface Windows Azure AD provides a query model for applications to access a Windows Azure AD directory tenant. Applications can be cloud, SaaS/multi-tenant, mobile, etc. applications. Applications can also publish information to the directory tenant subject to access control. (This will be later described in this document with the notion of service principal.) For that purpose, Windows Azure AD exposes a directory programming surface for querying and updating the directory, and thus sustaining the identities lifecycle management as whole via aRESTful API introduced in June 2012 called Windows Azure Active Directory Graph API. This primary directory access protocol supports today the management of users, groups, etc. as well as service licensing and directory tenant administration. It represents a new way for application to connect to the directory through the use of REST/HTTP interfaces.For that purpose, Windows Azure AD exposes a single common global URL for all tenants for the Directory Graph API, where the tenant identifier is part of the URL to allow this.The directory tenants Graph endpoint is as follows: https://graph.windows.net//45 Such as: https://graph.windows.net/demo.idmgt.archims.fr/ An authorized application can then operate on information in Windows Azure AD through a URL such as https://graph.windows.net/demo.idmgt.archims.fr/Users(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. 45graph.windows.net now replaces directory.windows.net 46W INDOWS AZURE AD GRAPH COMMON QUERIES: http://msdn.microsoft.com/en-us/library/windowsazure/jj126255.aspxActive Directory from on-premises to the cloud 21
25. 25. Continuing with the example above, you can see that it is easy to access a users groups by using the URL: https://graph.windows.net/demo.idmgt.archims.fr/Users(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 whos 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 applications data store. A differential query request URL is created by appending a query string to a directory tenants Graph endpoint. For example, a differential query request for a directory tenant with the demo.idmgt.archims.fr domain name wouldbegin with: https://graph.windows.net/demo.idmgt.archims.fr/changes? (See MSDN article W INDOWS AZURE AD GRAPH DIFFERENTIAL QUERY47). The approach of using standard REST interfaces to operate over a graph containing entities (nodes) and relationships (arcs) between entities - often referred to as a graph interface - is very common on the Internet nowadays. For example, much of the information in Facebook48 is available in such a manner.Note:For more information on networks and graphs, we advise you reading the book entitled NETWORKS,CROWDS, AND MARKETS: REASONING ABOUT A HIGHLY CONNECTED WORLD49published by CambridgeUniversity Press. 47W INDOWS AZURE AD GRAPH DIFFERENTIAL QUERY: http://msdn.microsoft.com/en-us/library/windowsazure/jj836245.aspx 48Facebook Graph API: http://developers.facebook.com/docs/api/ 49NETWORKS, CROWDS, AND MARKETS: REASONING ABOUT A HIGHLY CONNECTED W ORLD: http://www.cambridge.org/gb/knowledge/isbn/item270544322 Active Directory from on-premises to the cloud
26. 26. Developers can build on this simple direct URL based access to take advantage of the sophisticated filtering and metadata operations that are available via Open Data Protocol (OData)50 version 3. OData v3 is a very rich protocol, and not all of it is applicable to the directory the directory supports a subset. The directory publishes it schema and the attributes that can be used in filter expressions for scale and performance reasons. Built on standards such as HTTP, JSON and AtomPub, OData v3 is a Web protocol for unlocking and sharing data freeing it from silos that exist in some software applications today. The OData protocol supports serialization in multiple popular formats, including JSON and Atom/XML. With OData, developers are able to build cross-platform Web and mobile applications. It benefits from a strong ecosystem of OData producers, consumers and libraries several of them open source including Java, PHP, Drupal, Joomla, Node.js, Microsoft .NET, etc. The OData protocol is released under the Microsoft Open Specification Promise51 to allow anyone to freely interoperate with OData implementations. As of this writing, an OASIS Open Data Protocol (OData) TC52has been proposed53 in order to define an open data protocol for sharing data and exposing data models interoperable on the Web: "To accomplish the goal of open data for the open Web, we have seen a push for support to enable access to and use of data across platforms, applications and devices. Taking steps to standardize OData through OASIS allows developers to act on the data in a more well-defined way." Jean Paoli, Prsident de Microsoft Open Technologies Inc. We are convinced that developers will find the Directory Graph API straightforward to write applications that integrate with Windows Azure AD and also potentially with other cloud solutions that operate with graph interfaces. Note: For additional information, see the MSDN documentation54 of the Windows Azure Active Directory Graph. 3.2.2 STS As previously mentioned, Windows Azure AD provides support for (federated) authentication, single sign-on (SSO), and authorization. There are flavors of this support for browsers and for rich clients, and for identities hosted in the cloud (Cloud ID) as well as federated identity providers (Federated ID). These capabilities are provided by the Security Token Services (STS) in Windows Azure AD. The Security Token Services (STS) in Windows Azure AD is a multi-tenant STS. 50 Open Data Protocol (OData) : http://www.odata.org/ 51Open Specification Promise: http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx 52OASIS Open Data Protocol (OData) TC: https://www.oasis-open.org/committees/odata/charter.php 53 TECHNOLOGY LEADERS SUPPORT OASIS STANDARDS FOR OPEN DATA PROTOCOL: http://www.microsoft.com/en- us/news/press/2012/may12/05-24ODataPR.aspx 54W INDOWS AZURE ACTIVE DIRECTORY GRAPH: http://msdn.microsoft.com/en-us/library/hh974476Active Directory from on-premises to the cloud23
27. 27. 3.2.3 Core security model The core security model consists of tenants realms. There is a 1:1 mapping between a STS tenant realm and a directory tenant. The notion of a realm is a well-known concept in security; and the tenant realm in the STS is the equivalent of a Kerberos realm or a Windows Server AD domain. Tenant realms have a single, immutable, globally unique and rename safe security identifier and one or more names verified DNS names that act as friendly aliases. Tenant realms contain principals, representing users, services, etc. A principal is an object of the corresponding type in the directory. Principals have one or more names (such as user principal name for a user, or a multiple service principal names for a service or application) and a security identifier, that is globally unique, immutable, and not re-usable. Principals can have one or more credentials (such as password, certificate, and keys) that can be used to authenticate the principal. Alternatively the principal can be authenticated by an identifier from an external identity provider (such as an immutable ID from a security token issued by the organization on-premises identity provider). A principal that has this kind of mapping setup is also known as a Federated principal, because the principal conceptually represents a user from a federated system (such as a corporate user from the on-premises identity infrastructure). Principals can both request and accept security tokens, typically from the tenant realm in which they reside. Tenant realms are supported by the STS that authenticates requestors and makes authoritative statements about those requestors, usually in the context of the target for the request. These authoritative statements are packaged in security tokens and are signed by the STS.Security tokens consist of a collection of claims, which are statements made about users, for example name, id, email, group, role, etc. used for authentication and authorization decision purposes.Security tokens typically follow a secure, standardized method of packaging claims for transport. Tenant realms can setup federation with other realms, i.e.to an existing on-premises identity infrastructure such as a corporate Active Directory. 3.2.4 Supported protocols Usual on-premises authentication mechanisms such as Kerberos and NTLM no longer apply in a general manner in the cloud space since cloud applications do not have most of the time connectivity to a Windows Server AD domain controller (DC) and/or the VMs underneath arent domain-joined at all. Windows Azure Virtual Machines and Windows Azure Virtual Network certainly provide such capabilities with the ability to instantiate a standalone DC in the cloud or to leverage secure site-to-site connectivity back to the on-premises infrastructure (see section 2AD IN W INDOWS AZURE IS NOT W INDOWS AZURE AD!). However, this should be seen more specifically rather as IaaS migration paths than the general situation for the workloads in the cloud. Its all the more so with the mobility and the BYOD phenomena where users will also often be themselves considered outside of the organization infrastructure perimeter. Furthermore, cloud solutions can by nature encompass multiple security realms. Consequently, Internet identity federation protocols constitute a much more scalable and efficient way to implement authentication in such context. Moreover, Internet identity federation protocols can also relevantly respond to other concerns like single sign-on (SSO) between cloud applications that reside in the same of different clouds as well as claims issuancewith the processing and transforming capability of security tokens in terms of type of trust, token format, semantics and (values of) claims for impedance adaptation. Unsurprisingly, Windows Azure AD opts to such protocols and furthermore systematically aims at being open standards based wherever possible.24 Active Directory from on-premises to the cloud
28. 28. Currently, this translates by the support for the following OASIS standards widely established andadopted: WS-Federation (WS-Fed)55 (from the OASIS Web Services Federation (WSFED) TC56), WS-Trust57 (from theOASIS Web Services Secure Exchange (WS-SX) TC58), Security Assertion Markup Language (SAML) 2.059 (from the OASIS Security Services (SAML) TC60). All the above protocols use SAML security tokens. WS-Federation and WS-Trust (WS-*) protocols are presently the primary authentication protocols for Windows Azure AD as they supports both respectively Web (browser) based clients and rich smart clients. As far as the latter is concerned, it is very popular in the Public Sector with government agencies as well as with enterprises and educational institutions. Its a suite of specifications and, as such, comprises a set of normative and non-normative documents. As part of them, the normative document PROFILES FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.061defines the use cases or the How-to in regards to the use of SAML to solve specific problems of the extended enterprise, and as an important number of profiles. As of today, Windows Azure AD more specifically supports the Web Browser SSO profile and the Enhanced Client or Proxy (ECP) profile. The Web Browser SSO profile supports 12 possible deployment models. The one implemented here is the SP-initiated SSO: Redirect/POST Bindings or the HTTP-POST binding specified in the documentBINDINGS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.062. The ECP profile is an adaptation of the above SAML profile used for Browser SSO with the parts that were designed around the limitations of a browser removed. In other words, in the ECP profile, the user agent is assumed to be something more than a browser (or perhaps a browser with a plugin for example). 55 WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2: http://docs.oasis-open.org/wsfed/federation/v1.2/ws- federation.pdf 56OASIS Web Services Federation (WSFED) TC: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed 57 WS-TRUST VERSION 1.3: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf 58 OASIS Web Services Secure Exchange (WS-SX) TC: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws- sx 59 SECURITY ASSERTION MARKUP LANGUAGE (SAML) 2.0: http://go.microsoft.com/fwlink/?LinkId=193996 60 OASIS Security Services (SAML) TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 61PROFILES FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis- open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf 62BINDINGS FOR THE OASIS SECURITY ASSERTION MARKUP LANGUAGE (SAML) V2.0: http://docs.oasis- open.org/security/saml/v2.0/saml-bindings-2.0-os.pdfActive Directory from on-premises to the cloud25
29. 29. Windows Azure AD also provides a protocol support for IETF OAUTH 2.063(from the IETF OAUTH WG64), whichis gaining popularity in the Internet as an authorization protocol for accessing information. This is the primarily protocol for authorization and delegated authentication (see blog post OAUTH 2.0 AND SIGN-IN65). Using OAuth2, an application can gain access (with consent from the resource owner which could be the end user or the administrator user) to impersonate the user, or users in his organization to access the resource. The OAuth2 protocol uses JSON Web Token (JWT)66. JWT is a compact token format also defined by the IETF OAuth WG that is especially apt for REST-based development. JWT use is growing, and products supporting the format are increasingly common in the industry. Along with OAuth2, Windows Azure AD provides a model for representing applications as service principals in the directory (see section 6.2.1PROVISION THE APPLICATION IN YOUR W INDOWS AZURE AD DIRECTORY TENANT). An application can then make an access in its own security context, or act as a user to other applications, subject to constraints. Future versions will likely introduce the support for additional standards such as OpenID Connect67. OpenID Connect is a suite of lightweight specifications that provide a framework for identity interactions via REST like APIs. It is based on OAuth2, and JWT is also one of the basic components of it. 3.2.5 A deeper look at the structure of the Windows Azure AD STS As of today, the Windows Azure AD STS is implemented by a combination of two STS:1. The (core STS of the) Windows Azure AD sign-in service when the service was originally introduced in 2011;2. And an applicative STS that derives from the Windows Azure Access Control Service (ACS) and that was introduced in June 2012 with the Web SSO support for cloud and SaaS applications. 63RFC 6749 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK: http://tools.ietf.org/html/rfc6749 64IETF OAuth WG :http://tools.ietf.org/wg/oauth/ 65OAUTH 2.0 AND SIGN-IN: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx 66JSON Web Token (JWT): http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 67OpenID Connect: http://openid.net/connect/26Active Directory from on-premises to the cloud
30. 30. Important note: The current implementation of the Security Token Services (STS) in Windows Azure AD will evolve in the future but, from a logical perspective, the functionalities described hereafter will remain or be further extended to support more protocols and to embrace additional scenarios. In general terms for (the intent of) this paper, the (core STS of the) Windows Azure AD sign-in service handles the user authentication step, i.e. username/password, and the applicative STS handles the policy and claims generation steps. However, (cloud) application/service authentication is handled directly by the applicative STS as its name indicates. The applicative STS acts as a federation provider, which trusts a single authority: the Windows Azure AD sign-in service, which, in turns, can federate with on-premises identity provider. Albeit, as of today, you cannot directly trust any identity provider other than Windows Azure AD itself at the applicative STS level,you can leverage the Windows Azure AD Access Control serviceif the application/service authentication needs to trust other federated identity provider. In such case, federated identity providers can be an enterprise identity provider (such as an on- premises AD), or a social identity provider such as Microsoft Account, Facebook,Yahoo!, etc. This scenario is more specifically explored in section 7BRING YOUR OWN IDENTITY (BYOI) WITH W INDOWS AZURE AD ACCESS CONTROL. From a design perspective, this applicative STS has a tenant in it for each customer, each of these can be thought of as a logical realm, one for each tenant. There is a 1:1 correspondence between a directory tenant in the Windows Azure AD core directory and a tenant in the applicative STS. The applicative STS exposes a single common global URL for all tenants where tokens can be requested, in a similar fashion to the Windows Azure AD sign-in service. The tenant identifier is part of the various security protocols to allow this: https://accounts.accesscontrol.windows.net//v2/ Such as: https://accounts.accesscontrol.windows.net//v2/wsfederation for the OASIS WS-Federation protocol (more in section 3.2.5.2EXPOSED APPLICATIVE STS PUBLIC endpoints).Active Directory from on-premises to the cloud27
31. 31. The global URL variant of the applicative STS uses the same signing key for all the tenants, but varies the issuer name in the security tokens to represent each tenant. This is an optimization for:Scale: cloud applicationsand services do not need to trust many millions of different signingkeys;Usability:cloud applications and services do not need to construct tenant specific URLs;Discovery: there is a single discovery endpoint for federation metadata about an individualtenant. As for the security protocol, The tenant identifier is part of the global URL to allow this: https://accounts.accesscontrol.windows.net//FederationMetadata/2007- 06/FederationMetadata.xml The applicative STS synchronizes the principal and group membership information in the Windows Azure AD core directory for the purposes of token issuance.The (core STS of the) Windows Azure AD sign-in service is the authoritative store for organizations and security principals. The applicative STS knows the keys corresponding to the security principals allowing it to authenticate those principals. group membership information can be included in security tokens reducing friction when an application/service is performing authorization. 3.2.5.1 Exposed sign-in servicepublic endpoints The (core STS of the) Windows Azure AD sign-in service currently exposes several endpoints: It indeed exposes two metadata endpoints to federate your Windows Azure AD domain(s) with your on-premises identity infrastructure:1. One for WS-* based federation exposed at the following URL:https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml.The general syntax and semantics of these metadata are defined in the OASIS W EB SERVICESFEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.268.It covers the configuration data(endpoint URLs, key material for verifying signatures, etc.) to establish trusts between WS-*entities.2. One for SAML 2.0 based federation exposed at the following URL:https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml 68 OASIS WEB SERVICES FEDERATION LANGUAGE (WS-FEDERATION) VERSION 1.2: http://docs.oasis- open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.pdf28Active Directory from on-premises to the cloud