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.
Modern business applications 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:
Identity becomes a service where identity "bridges" in the cloud "talk" to on-premises directories or the directories themselves move and/or are located in the cloud (see Gartner report 2013 Planning Guide: Identity and Privacy).
Identity, like compute, 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, or part of them, to onboard the cloud for IT optimization reasons.
Kim Cameron, Microsoft Chief Identity Architect, is convinced 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."
Azure Active Directory (Azure AD) is Microsoft's vehicle for providing Identity Management as a Service (IdMaaS) capabilities in a public cloud.
As a complement of the white paper Active Directory from the on-premises to the Cloud, which is part of the same series of documents available on the Microsoft Download Center, this paper provides you with a "guided tour" of Azure AD to:
This paper can be seen a starting point for anyone challenged with identity, provisioning, federation or cloud based authentication, interested in leveraging efficiencies of the cloud and automation to get efficiencies in identity and access management, and consequently in leveraging an IdMaaS solution. They will directly tackle these areas.
Note For additional information, see the Microsoft MSDN article Getting started with Azure AD.
This document is an attempt to present the most important features and capabilities of Azure AD as available – in general availability (GA) or in public preview – at the time of this writing.
Even more Azure AD functionalities will be integrated over the next year(s) for your identities in the cloud. Since its general availability in April 2013, Azure AD indeed keeps continuing to receive enhancements that make Azure AD even more useful for IT professionals and developers.
Note Please make sure you periodically check the Azure AD community forum as well as the MSDN Azure blog for notification of upcoming enhancement and changes that relate to Azure AD.
This document will thus evolve over the time on a regular basis to reflect such additions and enhancements. This document constitutes the third revision.
This document doesn't discuss the deployment and configuration of Windows Server AD (WSAD) on-premises.
This document is intended as an overview document for the Azure AD offerings, and as such, it doesn't provide 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.
To cover the aforementioned objectives, this document is organized by themes which are covered in the following sections:
This document is intended for IT professionals, system architects, and developers who are interested in understanding the various options for managing and using identities in their (hybrid) cloud environment based on the Azure AD offerings foundation and how to leverage their related capabilities.
AD, AD in Azure and Azure AD are indeed useful for slightly different scenarios. We recommend using Azure AD in addition to on-premises AD (and AD in Azure) in most cases as one doesn't replace the other.
As mentioned in the introduction, Azure Active Directory (AD) is Microsoft's vehicle for providing IdMaaS capabilities in a public cloud. Microsoft's approach to IdMaaS is deeply grounded in – and extends – the proven concepts of on-premises Active Directory (AD).
Active Directory (AD) is a Microsoft brand for identity related capabilities. In the on-premises world, Windows Server Active Directory (WSAD 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).
The foundational concept of on-premises AD is that the content of the directory is the property of the organization deploying it and access to and use of that content is completely under the organization's control. This is also the fundamental concept behind Azure AD.
Azure AD is NOT a monolithic directory of information belonging to Microsoft, but rather, at the time of writing, more than four million different directories belonging to and completely controlled by different organizations.
This architecture and commitment is called "multi-tenant" and great care has been provided to insulate tenants (organizations) from each other and from their service operator – Microsoft.
We have indeed re-engineered AD , to support massive scale, devices based on any operating system or architecture, modern business applications, modern protocols, high availability, and integrated disaster recovery.
Since its introduction, Azure AD "has handled 400 billion identity authentications in Azure AD". "We have 350 million Azure Active Directory users. […] We actually process 4 billion, with a B, authentications every week with Azure Active Directory". This is a real testament to the level of scale we can handle. "At a high level, Azure AD is a high availability, geo-redundant, multi-tenanted, multi-tiered cloud service that has delivered 99.99% uptime for over a year now. We run it across 28 datacenters around the world. Azure AD has stateless gateways, front end servers, application servers, and sync servers in all of those data centers. Azure AD also has a distributed data tier that is at the heart of our high availability strategy. Our data tier holds more than 500 million objects and is running across 13 data centers."
Since we first talked about it in November 2011, and with such above numbers in mind, Azure AD has shown itself to be a robust identity and access management service for Microsoft cloud services. No other cloud directory offers this level of enterprise reliability or proven scale. Quoting from the report KuppingerCole Leadership Compass Cloud User and Access Management: "Looking at the Market Leadership chart, we see Microsoft being the clear leader. This is based on the fact that their Azure Active Directory on one hand shows good direct acceptance and on the other builds the foundation for widely used Microsoft Office 365. Furthermore, Microsoft has an exceptionally strong partner ecosystem."
Furthermore, last year, Gartner in their Magic Quadrant (MQ) for Identity Management as a Service (IDaaS) [Gartner, June 2015] has placed Azure AD after its only first year of availability in the "Visionaries" MQ.
As of this writing, Gartner has just released their MQ for IDaaS for 2016 [Gartner June 2016] and Azure AD Premium has been placed in the "Leaders" quadrant, and positioned very strongly for our completeness of vision.
Important note The above graphic was published by Gartner, Inc. as part of the larger research document - a complimentary access is provided here- and should be evaluated in the context of the entire document. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
As Alex Simons, Director of Program Management, Microsoft Identity and Security Services Division, says, "we're thrilled with the result. It really validates our vision of providing a complete solution for hybrid identity and access for supporting employees, partners and customers all backed by world class security based on Microsoft's intelligent security graph. This result says a lot about our commitment in the identity and access management space but more importantly about our customers, implementation partners and ISV partners who have worked together with us. They have been awesome about sharing their time and energy every day, to make sure that the products and services we build meet their needs and are helping them position their companies to thrive in the emerging world of cloud and devices.
You might be surprised to know that Microsoft also is the only vendor in the Leader quadrant across Gartner's Magic Quadrants for IDaaS, Cloud Infrastructure as a Service (IaaS), Server Virtualization, Application Platform as a Service, Cloud Storage Services, and as a leader across the data platform and productivity services. This really shows you why customers are choosing Microsoft across the full spectrum of cloud computing – our services are well integrated and also among the best available in their individual categories."
Alex Simons adds: "our effort doesn't stop here. We have a lot of hard work ahead of us and we are planning to deliver more innovative capabilities to further improve our position in the "leaders" quadrant.".
This said, a number of people are (still) surprised to find out that every Office 365 customer already has an Azure AD directory. Azure AD is the directory behind Microsoft Online Services subscriptions like Office 365, Dynamics CRM Online, Intune, etc. and is used to store user identities and other tenant properties. Just like the on-premises AD stores the information for Exchange, SharePoint, Lync and your custom LOB applications, Azure AD for instance stores the information for Exchange Online, SharePoint Online, Lync Online and any custom applications build in the Microsoft's cloud (or in another cloud).
It is possible to extend the usage of these directory tenants to other LOB based applications you're developing and/or to thousands of cloud pre-integrated SaaS applications like ADP, Concur, Google Apps, Salesforce.com and others, regardless of the public cloud they are hosted on. The pre-integrated SaaS applications are preconfigured via an application gallery with all the parameters needed to at least provide a seamless sign-in experience with them, thanks to the Application Access Enhancements for Azure AD (see later in this document).
Azure AD is available in three different editions to choose from:
Note This is a free edition as being used by the above Microsoft Online Services subscriptions. If you've already subscribed to a Paid Office 365 subscription, you can benefit from an Azure $0 subscription that you can use to access the Azure management portal with your existing Office 365 subscription in order to directly manage the related Azure AD tenant with all the access management and security feature set and thus empower your Office 365 subscription. For example, the aforementioned Application Access Enhancements for Azure AD can be only managed today by accessing the directory through the Azure management portal. You can sign-up for this $0 subscription by following the link https://account.windowsazure.com/PremiumOffer/Index?offer=MS-AZR-0110P&whr=azure.com.
Note Independently of any Microsoft Online Services subscriptions, you can sign-up for your free Azure AD tenant and trial Azure account by following the link https://account.windowsazure.com/signup?offer=MS-AZR-0044P.
The first user you generate as part of the sign-up process based on the fields below will also be an administrator of the directory. This user will be declared in the default domain of the directory tenant <domain name>.onmicrosoft.com. You will sign in to Azure with this account.
Note Contrary to other Azure resources, your Azure AD directories are not child resources of an Azure subscription. So if you cancel or allow your Azure subscription to expire, you can still access your directory data using Windows PowerShell, the Azure AD Graph API (see later in this document), or other interfaces such as the Office 365 administration console.
An administrator with Azure AD Basic edition can activate an Azure AD Premium trial.
Note For additional information, see the blog post Azure Active Directory Basic is now GA!.
The edition in part of the Enterprise Mobility Suite (EMS) offering, a comprehensive and cost effective solution for enterprise mobility needs.
Note The EMS offering is not only available with an Enterprise Agreement (EA) but also through the Microsoft's Cloud Solution Provider (CSP) and Open programs. For additional information, see the blog post Azure AD and Enterprise Mobility Suite now available without an Enterprise Agreement.
Note For a description of each edition below and a comparison table, see the Microsoft MSDN article Azure Active Directory editions. For more information on usage model, see the Microsoft MSDN article Azure Active Directory Pricing. For information on the usage constraints and other service limits for the Azure AD service per edition, see the Microsoft MSDN article Azure AD service limits and restrictions.
To sign-up today for Azure Active Directory Premium features, proceed with the following steps:
Note For additional information about how to sign up and start using the Premium edition, see the Microsoft MSDN article Getting started with Azure AD Premium. You can also watch the Channel 9 demo videos Enabling Azure Active Directory Premium trial, How to Purchase Azure Active Directory Premium - New Customers, and How to Purchase Azure Active Directory Premium - Existing Customers.
Click ASSIGN.
You can alternatively set the view filter to group (all groups) in SHOW, and then select the groups that you want to assign. Confirm the selection by clicking the check mark icon to save the changes.
Note For additional information, see the blog post Simplified License Assignment with Azure AD and EMS. You can also watch the Channel 9 demo videos How to assign EMS/Azure AD Premium licenses to user accounts and Assign EMS/Azure AD Premium licenses with PowerShell.
The premium edition of azure AD provides a dashboard for the directory, which is the one place to manage all of your services. It also makes it easy for you to keep up with new features and events.
Note For additional information, see the blog post Azure AD Premium Dashboard is in preview!.
The rest of this section describes the main characteristics of Azure AD (regardless of the "flavor", i.e. the edition) that organizations and cloud-based applications can leverage, as well as the core functionalities that Azure AD provides for the users of these applications and for the developers of these applications to be successful.
In terms of key scenarios, Azure AD can:
A description for all of the above is provided in a dedicated section.
Let's consider the anatomy of Azure AD.
At the simplest level, Azure AD is a scalable directory infrastructure that provides for storage, data access, replication and synchronization, device registration, and security token services (STS).
Below is a conceptual diagram showing the public interfaces, and the management surface area:
The core directory service represents the heart of 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, Azure AD aims at supporting - within organization owned tenant(s) - 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.
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 core directory service should generally have the following characteristics:
Unsurprisingly, Azure AD follows the WSAD data model with suitable changes for cloud use. The core data model is as follows:
Note For additional information, see the Microsoft MSDN article Entity Reference.
The Azure AD directory schema defines the properties, object classes, and link classes; much of it is a subset of standard LDAP v3 (and WSAD) schemas.
It however differs from that of LDAP directories in the following ways:
The Azure AD directory schema is defined per specific version. It may evolve as it was the case for the WSAD directory schema over the time since its first introduction in the early 2000.
Generally speaking, applications that consume directory information – and that are thus instantiated as an Application object in the directory - tend to fall into the following three classes with respect to directory extensibility requirements:
Note For more information on Application object, see the Leverage Azure AD for modern business applications white paper.
The use of an application-specific local store for extensibility could be an option in this case. With the advent of the cloud, storage capabilities are widely available through services such as Azure storage and Azure SQL database. An application that falls into this model may usually maintain its own tables in a storage service. A typical model might be that rows in the table represent Azure AD directory entities about which the 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".
This said, Azure AD provides custom schema extensibility capability (currently in public preview) in Azure AD Graph API that allow augmenting existing entity with additional custom attributes without requiring an external data store. A common example may consist in storing a payroll number for the user.
Note Azure AD Graph API is a RESTful API that provides a directory programming surface for querying and updating the directory, and thus to sustain the identities lifecycle management as whole. For more information, see the Microsoft MSDN article Azure AD Graph API.
As of this writing, the aforementioned User, Group, TenantDetail, Device, Application and ServicePrincipal entities can be extended with "String" type or "Binary" type single-valued attributes. Azure AD Graph API provides for that purposes REST interfaces for an application to register, unregister, enumerate, read, write, and filter by extension properties. Extension properties are registered on the Application object that corresponds to the application within the directory. The application must be granted write access to register an extension property. 100 extension properties (across ALL types and ALL applications) can be written to any single object.
Multi-tenant applications that register extension properties in the directory are referenced from all the tenants consenting to that application. Once a customer tenant has consented to an application (even for read) the extension properties registered on that application are available in the consenting tenant for reading/writing by any application that has the appropriate access.
Note For more information, see the blog post Extend Azure Active Directory Schema using Graph API (preview) and the Microsoft MSDN article Azure AD Graph API Directory Schema Extensions.
As most people know, the forest in WSAD represents the administrative and security boundary. Likewise, each directory in Azure AD is as a fully independent resource.
In other words, each directory is a peer, fully-featured, and logically independent of other directories that you manage. There is no parent-child relationship between directories.
This independence between directories includes:
As a forest contains one or multiple domains, a directory contains one or multiple domains. (See later in this document). For that purpose, as you can declare enterprise administrator(s) for the forest, there are similarly directory wide administrators.
Administrative units (AUs) in Azure AD are like OUs in WSAD modernized for the cloud. They let you sub-divide your Azure AD directory, enabling the separation of administrative duties and policy creation across a large organization. They represent a new Azure AD container of resources that can be used for delegating administrative permissions over subsets of users and applying policies to a subset of users.
Administrative units (currently in public preview as of this writing) are a feature of the Azure AD Premium edition. For the moment, you can create and manage them through dedicated Windows PowerShell cmdlets (see next section).
Note For more information, see the blog post Wrapping up the year with a boat load of Azure AD news! and the Microsoft MSDN article Administrative units management in Azure AD - Public Preview.
Azure AD allows administrators to manage information in it through:
Note For more information, see the Microsoft MSDN article Manage Azure AD using Windows PowerShell.
As previously mentioned, Azure AD provides support for (federated) authentication, single sign-on, and authorization.
There are flavors of this support for browsers and for rich clients, and for identities hosted in the cloud (cloud identities) as well as federated identity providers (federated identities). These capabilities are provided by the Security Token Service (STS) in Azure AD. The STS in Azure AD is a multi-tenant STS.
The core security model consists of tenant's 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 WSAD 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 multiple service principal names for an 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.
Note For more information, see the Microsoft MSDN article Supported Token and Claim Types.
Tenant realms can setup federation with other realms, i.e. to an existing on-premises identity infrastructure such as a corporate Active Directory environment.
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 Active Directory (WSAD) domain controller (DC) and/or the VMs underneath aren't domain-joined at all.
Azure Virtual Machines and 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.
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 "Bring-Your-Own-Device" (BYOD) trend 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 between cloud applications that reside in the same of different clouds as well as claims issuance with the processing and transforming capability of security tokens in terms of type of trust, token format, semantics and (values of) claims for "impedance adaptation".
Azure AD opts to such protocols for integrating applications and furthermore systematically aims at being open standards based wherever possible.
Note For more information, see the Microsoft MSDN article Azure Active Directory Authentication Protocols.
Currently, this translates by the support for the following OASIS standards widely established and adopted:
All the above protocols use SAML security tokens.
Note For more information, see the Microsoft MSDN article Supported Token and Claim Types.
WS-Federation and WS-Trust protocols supports respectively Web (browser) based clients and rich smart clients.
SAML 2.0, as a token format and a protocol, is very popular in the public sector with government agencies as well as with enterprises and educational institutions. SAML 2.0 is 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.0 defines 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, Azure AD more specifically supports (for the modern applications) the SAML 2.0 web browser single sign-in profile, the SAML 2.0 web browser single sign-out profile, as well as and the Enhanced Client or Proxy (ECP) profile.
Note The SAML 2.0 ECP profile is an adaptation of the SAML 2.0 browser single sign-in profile with the parts that were designed around the limitations of a browser removed. In other words, in the SAML 2.0 ECP profile, the user agent is assumed to be something more than a browser (or perhaps a browser with a plugin for example).
Note These profiles supports various possible deployment models. The ones implemented here are the HTTP-Redirect and HTTP-POST bindings specified in the document Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. For more information, see the Microsoft MSDN article SAML Protocol Reference.
As previously outlined, modern applications live in an environment that includes a broad spectrum of mobile and native clients, server to server communication, and web APIs as a result of the API economy, in addition to traditional browser and web site interactions. And thus, even WS-Federation or SAML 2.0 aren't enough to address the scenarios introduced by modern business applications.
To address these new requirements, Azure AD unsurprisingly also provides support for the OAuth 2.0 protocol, which is gaining popularity in the Internet as an authorization protocol for accessing information. This is the primarily protocol for authorization and delegated authentication.
Using OAuth 2.0, 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.
Note For more information, see the Microsoft MSDN article OAuth 2.0 in Azure AD.
The OAuth 2.0 protocol uses JSON Web Token (JWT). JWT is a compact token format especially apt for REST-based development. JWT use is growing, and products supporting the format are increasingly common in the industry.
Note For more information, see the Microsoft MSDN article Supported Token and Claim Types.
Along with OAuth 2.0, Azure AD provides a model for representing applications as service principals in the directory (see later in this document section). An application can then make use of its own identity, i.e. the "app identity", or instead the user's identity, i.e. the "app + user identity" (or delegated identity).
Finally Azure AD provides the support for the OpenID Connect protocol. OpenID Connect defines an identity layer on top of OAuth 2.0 and represents the state of the art in modern authentication protocols. It's a suite of lightweight specifications that provide a framework for identity interactions via REST like APIs. It is based on OAuth 2.0, and JWT is also one of the basic components of it.
Note For more information, see the Microsoft MSDN article OpenID Connect 1.0.
Microsoft has been deeply involved in the standards work for both OAuth 2.0 and OpenID Connect. Microsoft takes the participation in the standards community seriously and have worked hard to ensure interoperability with other implementations.
Note The OpenID Foundation has recently launched a certification program for OpenID Connect implementations. For more information, see the article The OpenID Foundation Launches OpenID Connect Certification Program. Azure AD has successfully passed the certification and is certified as an OpenID Connect identity provider.
Having an OpenID Connect certification program provides confidence that certified implementations will "just work" together. This represents another important step on the road to widely-available secure interoperable digital identity for all the devices and applications that people use. Microsoft is proud to be a key contributor to the development of OpenID Connect and now of its certification program.
As previously introduced, Azure AD supports several of the most widely used authentication and authorization protocols via a STS.
In a recent past, this STS was implemented by a combination of two STS:
In this past service configuration, the login.microsoftonline.com sign-in service was (and still is today) in charge of handling the user authentication step, i.e. username/password - with an optional second-form of authentication (e.g. a mobile phone app, an automated phone call, or text message challenge) through the native support of Azure Multi-Factor Authentication in Azure AD -, and login.windows.net the policy and claims generation steps for modern application. Application authentication was thus handled directly by login.windows.net. login.windows.net acted as a federation provider, which trusted a single authority: the login.microsoftonline.com sign-in service.
As of today, all authentication requests can now be served directly by the login.microsoftonline.com STS end-to-end.
While being most of the time completely to an existing application - if the app makes certain assumptions about our underlying implementation it may require changes – this evolution provides several benefits:
Important note Applications that send requests to login.windows.net continue to be supported. The redirect to login.microsoftonline.com occurs earlier in the authentication flow than before, and maintains protocol consistency. This said, we do recommend to reflect the evolution in such applications as soon as possible, thus allowing users to get an improved sign in experience, and authentication flows to be free of extra complexity.
Note For more information, see the blog post Simplifying our Azure AD Authentication Flows.
login.microsoftonline.com is authoritative for organizations and security principals. Group membership information can be included in security tokens reducing friction when an application/service is performing authorization.
As an IdMaaS service, Azure AD enables you to create multiple directories that you can use for testing or other non-production usage, or for managing data synced from various on-premises identity directories, etc. The classic Azure management portal enables you to add directories and manage existing ones. You can then manage all your directories from the portal.
These directories are fully independent resources. In other words, as noticed before, each directory is a peer, fully-featured, and logically independent of other directories that you manage. There is no parent-child relationship between directories.
Note For more information, see the blog post Creating and Managing Multiple Azure Active Directories.
To add a directory, proceed with the following steps:
Note If the directory you're creating is to be used in production, choose a name for the directory which your users will recognize as the name of your organization. You can change the name later if you want.
Note While the default domain cannot be changed, later you can add a custom verified domain owned by your organization (e.g., "fabrikam.com") to enable better user experiences for sign on to that directory, or for synchronizing with the on-premises identity infrastructure.
Your user account is included in that new directory, and you're assigned to the global administrator role. This enables you to manage the directory you created without signing in as a different user of that directory. As an administrator of a directory, you can also add users from another directory of which you're a member. This is useful, for example, where there are users in your production directory who will need to collaborate on an application that is under development or testing in a non-production environment. A user can be a member of up to 20 directories.
Note For additional information, see the MSDN article Azure AD service limits and restrictions.
If you access the Azure management portal with a Microsoft account, you can configure your Microsoft account to manage an existing Azure AD that's used for Office 365 or another service, even if your Microsoft account already manages an Azure AD directory tenant.
To configure a Microsoft account to manage an existing directory, proceed with the following steps:
Note You can authenticate either with a Microsoft account or an organizational account.
Click continue to add your Microsoft account as a global administrator of the existing directory.
You can manage this directory tenant like other directories for which you're a global administrator.
Any directory that is no longer used can be deleted with the assurance that you won't accidentally delete a directory that controls access to important resources or is relied on by subscriptions.
To delete an existing directory, proceed with the following steps:
Note You can authenticate either with a Microsoft account or an organizational account. However, you have to be a global administrator of the directory you want to delete. Also, if you sign in with an organizational account, you cannot delete the home directory of your user account. For example, if you sign in as johndoe@corpfabrikam.onmicrosoft.com, you cannot delete the directory with the initial domain corpfabrikam.onmicrosoft.com.
Note To protect and prevent you from accidentally deleting an important directory, Azure AD requires that there is only one user in the directory, no applications in the directory, no subscriptions to Azure, Office 365, or other Microsoft Online services for organizations that rely on this directory, etc.
For additional information, see the MSDN article What is an Azure AD directory?.
Azure AD enables a customer to start using its IdMaaS features with no on-premises footprint. Accordingly, Azure AD provides for hosted (cloud) identities where customers can create users, groups and other principals for their organization. The cloud identities are directly mastered in an Azure AD directory tenant.
With cloud identities, users receive, for signing into Azure AD and any cloud-based application that is integrated into Azure AD, cloud credentials (that are separate from other desktop or corporate on-premises credentials if any).
This outlined, many enterprise customers will want to extend their on-premises identity infrastructure to seamlessly synchronize existing on-premises identities to the cloud and thus establish a hybrid corporate identity platform. Such an approach (also supported by Azure AD) is more sophisticated.
If your organization uses an on-premises identity infrastructure (based on AD or on other (LDAP-based) directories), Azure AD enables you to extend it to simplify your cloud-based administrative tasks and even provide your users with a more streamlined sign-in experience.
Azure AD supports the following three directory integration scenarios:
Note From a security standpoint, the password information that is replicated in Azure AD is the result of a one-way function (SHA-256) applied to the user's password hash stored in an encrypted form, which means that, even if this secret leaks, it cannot be used to access to any resource on your corporate internal network.
For additional information on the password (hash of hash) synchronization capability, see the following Microsoft TechNet articles Implement Password Synchronization and DirSync: Password Sync Frequently Asked Questions.
Such a capability provides a "same sign-on" experience, where users sign in to their corporate machine and Azure AD/Office 365 with the same credentials.
With the password sync capability, this integration scenario provides seamless sign-in user experience while requiring a minimal investment from an administrative perspective. With such a tradeoff, it constitutes the preferred option for most organizations that expect a seamless sign-in experience.
The user's identity is mastered on-premises in the identity infrastructure and synchronized to the Azure AD in the form of a federated identity.
In order to set up single sign-on, organizations need to deploy on-premises Active Directory Federation Services (AD FS) or other supported third-party security token services (STS) to federate between the on-premises and cloud directories. Once a supported STS has been set up, users can use their on-premises corporate credentials (user name and password, and/or any additional authentication factor) to access the services in the cloud and their existing on-premises resources.
Note For more information, see the guide Azure Active Directory Hybrid Identity Design Considerations.
Through directory synchronization, organizations can keep their existing on-premises identity infrastructure synchronized with their Azure AD directory tenant. As covered later in this document, secure tooling is provided for synchronization to automatically propagate on-premises initiated user adds, deletes, and changes to Azure AD directory tenant(s), streamlining the process of provisioning and managing identities and securing access to resources on-premises, in the cloud, or both, as well as write-back capabilities to handle hybrid integration scenarios.
Directory synchronization along with the related options - depending on the on-premises identity infrastructure - are further discussed later in this document for organizations that want to streamline the provisioning and the synchronization of identities.
Considering the above, Azure AD enables a seamless sign-in experience for identities that rely on password (hash of hash) synchronization ("same" sign-on) or a supported STS to federate between the on-premises and cloud directories (single sign-on).
For modern applications and SaaS subscriptions, you can deliver a seamless sign-in experience as well to eliminate the need for multiple usernames and passwords. Users can then sign into Azure AD, Microsoft cloud services or any other cloud-based application that is integrated into Azure AD using their own corporate on-premises credentials.
Users can gain access to Azure AD or any other application that is integrated into Azure AD by authenticating to their Azure AD user accounts, either through a prompt to provide valid credentials or through a federated single sign-on process. Once authenticated, user's identities refer to the user names associated with the Azure AD accounts.
The above type of identity (cloud vs. federated) affects the user experience, administrative requirements, deployment considerations, and capabilities using Azure AD.
The following is the simplified breakdown of the experience:
As mentioned above, users may have two identities, i.e. a cloud identity for Azure AD and other cloud-based applications, and potentially one for accessing on-premises applications. Consequently, in absence of password (hash of hash) synchronization, users are prompted for credentials even when logged into their on-premises infrastructure (AD or non-AD sources) when accessing Azure AD and other cloud-based applications.
As previously outlined, with password (hash of hash) synchronization, which is only available for on-premises AD mono or multi-forest environment, users can sign in to Azure AD and other cloud-based applications using the same user name and password as they use to log onto their corporate network for accessing on-premises applications.
Finally, integration with cloud-based multi-factor authentication solution can be enabled for users with the native support of the easy-to-use Azure Multi-Factor Authentication solution. (See later in this document.)
Important note On-premises multi-factor authentication solutions support is not available for clients other than web browsers or clients that uses passive federation, with the exception for Office 365 ProPlus/Office 2013 clients with the modern authentication (a.k.a. Active Directory Application Library (ADAL) based authentication stack) enabled. Modern authentication is available to any customer running the March 2015 or later update for Office 2013 but is disabled by default. For more information, see the blog post Office 2013 modern authentication public preview announced.
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.
Finally, integration with cloud-based multi-factor authentication solution can be enabled for administrators with the native support of the easy-to-use Azure Multi-Factor Authentication (MFA) solution.
The above scenarios directory synchronization with password synchronization is different from the directory synchronization with single sign-on in that it does not require the customer to deploy and maintain supported STS servers on-premises.
Password (hash of hash) synchronization is fully integrated with the tooling tool later discussed. This better keeps the deployment simple and removes the costs associated to the deployment and maintenance of fault-tolerant STS components.
As illustrated in terms of experience, the scenario Directory synchronization with single sign-on allows your users to seamlessly access their resources in the cloud without being prompted for their passwords multiple times (at least once when logging into their on-premises network, once when accessing cloud resources). When using password hash synchronization, users will still have to enter their password, although this password may be locally saved on the client.
Customers who select Azure AD as an IdMaaS for their applications and SaaS subscriptions typically want to reduce the complexity of their infrastructure and to minimize their operational costs. The directory synchronization scenario (if any) solution should be aligned to these goals and ideally require no or little on-premises hardware investments and no or little deployment effort.
Considering the above discussion, recommendations for each scenario, as well as a features and benefits matrix, are provided below.
Requirements | Cloud identities without directory sync | Directory sync (w/ password | Directory sync and single-sign on |
Identity Model | Cloud identities | Cloud identities | Federated identities |
Reduce hardware footprint and shorten deployment times | +++ No on-premises infrastructure required | + Single on-premises server (or VMs) required | -- Multiple on-premises servers (or VMs) required (1) |
Users must still be able to access their resources (modern applications and SaaS subscriptions), if the on-premises corporate network is unavailable | Yes | Yes | No (2) |
Single on-premises AD forest – Users can use the same set of credentials across premises | No | Yes | Yes |
Multiple on-premises AD forests – Users can use the same set of credentials across premises | No | Yes | Yes |
On-premises non-AD directories – Users can use the same set of credentials across premises | No | No. Password hash synchronization is not available in this scenario. | Yes |
User logon protection with Azure Multi-Factor Authentication | Yes (3) | Yes (3) | Yes (3) |
User logon protection with customer (virtual) smartcard or other multi-factor authentication solution or | No | No | Yes (3) (4) (5) |
User logon from outside the corporate network must be prevented | No | No | Yes (4) |
Users are subject to logon policies such as logon time restrictions | No | No | Yes (4) |
Organization requires access to logon attempts (security logs), for auditing purposes | Yes (6) | Yes (6) | Yes (4) |
Account lockouts in the on-premises directory must immediately prevent new sign-in to for Azure AD and the resources that rely on it | No | No (7) | Yes (8) |
(1) Deployment in a hybrid model with some roles hosted on virtual machines in Azure is supported. For additional information, see the following Microsoft TechNet and MSDN articles Deploy AD DS or AD FS and Office 365 with single sign-on and Azure Virtual Machines and Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines.
(2) Dependency on on-premises (or Azure-based) infrastructure availability.
(3) For Office 365 users, this requires the modern authentication (a.k.a. Active Directory Authentication Library (ADAL) based authentication stack) for Office 365 ProPlus/Office 2013 applications. Modern authentication is available to any customer running the March 2015 or later update for Office 2013 but is disabled by default. The Office 2013 March 2015 update is fully production ready and supported. Once enabled, app passwords are then no longer needed.
(4) Dependency on the on-premises STS capabilities.
(5) VPN workaround can be implemented for other rich-clients.
(6) As per Applications Access Enhancements for Azure AD/Azure AD Basic or Premium capabilities that provide pre-defined security reports associated with the signons by the organization's users.
(7) Disabled account status is replicated every 3 hours.
(8) Open sessions will not be terminated immediately. The access denial will only occur when the token will expire and when the application will try to get another token issued.
Important note The above table highlights many requirements that imply single sign-on to be fulfilled. In reality, today those requirements are actually required only by a small fraction of Azure AD/Microsoft services customers.
Note For more information on the benefits and features provided with each of these scenarios, see Microsoft TechNet article Determine which directory integration scenario to use.
The Azure management portal along with the other Microsoft services portals such as the Office 365 account portal help tenant administrators managing their organizations' identity and subscription data using a single instance of Azure AD. Let's see how it works.
Note For more information, see Microsoft TechNet article Administering your Azure AD tenant.
After signing up for Azure AD (or for a Microsoft service such as Office 365, Dynamics CRM Online, and others), the only domain associated with your subscription account and created with the directory tenant is the <organization name>.onmicrosoft.com domain chosen during registration, for example corpfabrikam.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 Internet domains to a directory rather than retaining the onmicrosoft.com domain, and then assign users to sign in with any of the validated domains.
You can register multiple Internet domain names for a directory, for example fabrikam.com, in addition to the initial default domain, for example corpfabrikam.onmicrosoft.com. A directory allows you to register an Internet domain only after you proves that your organization owns the DNS namespace in the public Internet DNS. As of this writing, you can host up to 600 registered Internet domains in your directory, each represented by a different DNS namespace.
A domain can then 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 as previously covered.
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.fabrikam.com and ftes.fabrikam.com, and only set up the federation for one of them.
A domain can be converted from cloud to federated to sustain federated identities in lieu of cloud identities, or from federated to cloud.
Note For more information, see the Microsoft TechNet articles Add your domain.
To register an Internet domain, proceed with the following steps:
To prove that you control the domain, you then use the above information to create a CNAME record in the authoritative DNS server for the newly added DNS Internet domain. Azure AD indeed uses a DNS record that you create at your registrar to confirm that you really own the domain. In our illustration, the information to add in your DNS domain registrar consists in a TXT record with the value "MS=ms30417789".
Note For more information on this process, including detailed step-by-step directions for several popular domain name registrars, see the Microsoft TechNet article Verify a domain at any domain name registrar.
As an illustration of the aforementioned Azure AD module cmdlets, let's see how to add and verify a custom Internet domain with Windows PowerShell.
Like for the above steps 4 to 6, the New-MsolDomain cmdlet enables to add a standard (cloud) Internet domain. After running this command, you have to prove that your organization owns the DNS namespace in the public Internet DNS.
For that purpose, and in order to verify the DNS domain name, you need to use the Get-MsolDomainVerificationDns cmdlet in order to get the DNS record information required to create for the new cloud domain.
Once the given TXT record is added at your DNS domain registrar, you finally prove your control of the DNS namespace by running the Confirm-MsolDomain cmdlet.
Likewise, you can use the New-MsolFederatedDomain cmdlet to create of custom federated (single sign-on) domain in your directory. Finally, the Set-MsolDomainAuthentication cmdlet enables to convert a standard domain into a single-sign on domain.
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 the directory integration scenario Directory synchronization with single sign-on earlier in this document.
Moreover, and as expected, when the user signs-in to Azure AD with his federated account, he's invited to authenticate on the on-premises identity infrastructure. If single sign-on is correctly set up, you will indeed notice that the user cannot even type a password in the login Web page of the sign-in service of Azure AD. Password will be indeed shaded. The user will be instead smoothly redirected to the declared on-premises identity provider.
If your organization uses an on-premises directory service, you can synchronize it with your Azure AD tenant to simplify your cloud-based administrative tasks and even provide your users with a more streamlined sign-in experience.
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 Line of Business (LOB) solutions.
Directory synchronization is the first integration capability offered by Azure AD with your on-premises. As an IdMaaS offering, 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.)
Azure AD indeed enables the support of on-premises Windows Server Active Directory (WSAD) mono and multi-forest environments as well as non-Active Directory directories environments. Thus, it has provided over the time multiple technical choices to both better accommodate the on-premises existing environments and to adequately sustain the subsequent identity provisioning and synchronization:
Note For additional information, see the Microsoft MSDN article Directory Integration Tools.
This section 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 tooling, when working with Azure AD.
The now generally available Azure Active Directory Connect (Azure AD Connect) provides a single and unified wizard that streamlines and automates the overall onboarding process for both directory synchronization with on-premises AD mono-forest and multi-forest environments (including password (hash of hash) synchronization) and single sign-on if you want to.
Note For additional information, see the blog post Azure AD Connect & Connect Health is now GA!, and the Microsoft TechNet article Azure Active Directory Connect.
Directory provisioning refers to the creation and management of directory entries. In the context of Azure AD, directory provisioning is different from directory synchronization, in that objects that are provisioned are mastered in the Azure AD and can be edited online. Directory provisioning can be performed through Azure AD management or programming interfaces such as the Azure management portal, the bulk upload using .csv files, the Azure AD Module for Windows PowerShell cmdlets or the Azure AD Graph API.
While some form of directory synchronization can be implemented using these interfaces, this remains different from 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 Azure AD Module or the Azure AD Graph API categories.
In order to stay with the aforementioned simplicity principle, Azure AD (and Office 365) initially came with a pre-packaged identity synchronization engine named the DirSync tool, based on the FIM product and customized for a single scenario allowing the synchronization with an Active Directory mono-forest environment: it was and can be used to replicate WSAD user accounts (and other Active Directory objects) in your Azure AD directory tenant, whether it is a standalone one (as enabled by the various Azure AD offerings) or the directory of, for instance, your Office 365 subscription.
Important note Neither the Active Directory (and Exchange) multi-forest environment synchronization - which is also a (very) common scenario for largest companies - nor the synchronization with other directories were and are covered by the DirSync tool.
Note For additional information, see the Microsoft MSDN article Azure Active Directory Synchronization Tool (DirSync).
Unlike manually created accounts, accounts created by the DirSync tool are fully populated with user account information from Active Directory. This enables service administrators keeping Azure AD objects updated with changes made in the on-premises WSAD.
Note For a list of attributes that are synchronized with the current DirSync tool, see the Microsoft TechNet article DirSync: List of Attributes that are Synced by the Windows Azure Active Directory Sync Tool.
Moreover, starting with version 1.0.6385.0012 of DirSync, password (hash of hash) synchronization can be provided.
Important note The Azure AD team regularly has updated the DirSync client with new features and functionality. Not all additions are applicable to all audiences. To keep track of the versions that have been released, and to understand whether you may need to update to the newest version or not, see the Microsoft TechNet Wiki article Azure Active Directory Sync tool - Version Release History.
Note Organization who are already running directory synchronization and single sign-on (aka federation) in a single AD forest may decide that password (hash of hash) synchronization is sufficient to meet their business requirements. A transition path is available for them. For more information on this process, see the Microsoft TechNet wiki article DirSync: How To Switch From Single Sign-On To Password Sync.
Directory synchronization is not something that is new for Azure AD. The DirSync tool is built on top of FIM. The configuration of directory synchronization has been simplified for the Azure AD environment.
Note For details pertaining to this topic, see the Microsoft TechNet articles Directory synchronization roadmap and Manage directory synchronization.
There is no manual configuration that you need to be concerned with, everything being configured via wizards.
Note For more information on how to proceed with the installation of DirSync, see the Microsoft TechNet Wiki articles HowTo: Install the Azure Active Directory Sync Tool (now with Pictures!) and Best Practices for Deploying and Managing the Azure Active Directory Sync Tool.
This said some customers may have in this context a requirement to scope what objects are synchronized from their on-premises Active Directory to their Azure AD directory tenant. Common requests in this area are typically:
Directory synchronization scoping is something supported through the DirSync tool at the following levels:
Important note Preventing the replication of certain attributes to Azure AD is not supported with the DirSync tool. All attributes must be part of the scope.
See the related instructions to completely setup the directory synchronization for your domain(s) within your Azure AD directory tenant.
As previously mentioned, the DirSync tool was intended for on-premises AD single-forest scenarios. However, many customers are operating with more than one on-premises Active Directory forest for a variety of reasons, such as:
Multi-forest topologies can be supported through the Azure AD Sync tool initially released in September 2014. This tool that was considered as the successor of DirSync is flexible, and can accommodate most Active Directory and Exchange multi-forest scenarios:
Note For additional information, see the Microsoft MSDN article Azure Active Directory Sync.
This is an awaited feature was that previously only available with the Azure AD connector and Microsoft Forefront Identity Manager (FIM) 2010 R2.
Beyond this key characteristic, Azure AD Connect includes a rich set of sync and write-back capabilities:
Note For more information, see the whitepaper Azure AD & Windows 10: better Together for Work and School.
Note For version release history on AAD Connect, see the article Azure AD Connect: Version Release History.
Scenario | Stay on existing DirSync tool | Upgrade to new DirSync tool | Migrate or deploy the Azure AD Connect tool |
Existing DirSync tool's customers | Remain on current deployment if:
| Upgrade to the latest DirSync tool if:
| Migrate to the Azure AD Connect tool for:
|
New customers | N/A | Office 365 customers will default here as of this writing | Azure AD Premium customers likely to default here |
Azure AD Connect is replacing both the DirSync tool and the Azure AD Sync tool (download), and allows in this context upgrading or migrating your existing DirSync or Azure AD Sync deployment quickly and easily with little or no impact.
Azure AD Sync is the sync engine of Azure AD Connect and Azure AD Connect is now THE one stop shop for connecting your on-premises directories to Azure AD, whether you are evaluating, piloting, or in production.
Note For information on the supported topologies, see the article Topologies for Azure AD Connect.
Generally speaking, and considering the above, the Azure AD Connect should be the preferred solution for directory synchronization.
Note For additional information, see the Microsoft article Integrating your on-premises identities with Azure Active Directory.
Setting up directory synchronization for domain(s) within your Azure AD directory tenant with Azure AD Connect requires to conduct a few steps as outlined under the section DIRECTORY INTEGRATION for the selected directory in the Azure management portal.
The first step consists in activating directory synchronization by clicking ACTIVATED and then SAVE at the bottom of the tray.
This should be considered a long-term commitment to coexistence scenarios between your on-premises WSAD and your Azure AD directory tenant in the cloud.
This first 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 Azure AD Connect (as well as the aforementioned DirSync tool, the Azure AD Sync tool, and the Azure AD Connector for FIM). This interface is not available to support custom synchronization solutions.
After directory synchronization has been activated, you will need to add at least one custom domain. This is the second step. 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.
After ensuring that both your on-premises and cloud environments are ready for directory synchronization as per step two – notably see the Microsoft TechNet article Prepare for directory synchronization -, you can then download Azure AD Connect installation package (AzureADConnect.msi) and install it. This is the third step.
Specify in the Azure AD Connect wizard all the setting parameters that relate to your own configuration.
Important note Users in different AD forests will require a different UPN suffix. In other words, it is not possible to provide a single UPN domain for all users, across all forests. For example, you may not assign corpfabrikam.com as a UPN suffix for all users. Users in Forest A will be assigned a UPN suffix of ForestA.com and users in Forest B will be assigned a UPN suffix of ForestB.com. Shared UPN namespaces across forest are not supported by design.
For more information, see the (old) Microsoft TechNet articles Considerations for Deploying Forest Trust and Additional Configuration for Functionality Across Forests (Multiple Forest Considerations in Windows 2000 and Windows Server 2003) (search for "Shared UPN").
Once the configuration is completed, you can the verify that the initial sync is complete and manage the directory sync over the time.
Note The Azure Active Directory Connect Health (Azure AD Connect Health) cloud based service in the new Azure Portal helps you monitor and gain insight into health, performance and login activity of your on-premises identity infrastructure. As such, it offers you the ability to view alerts, performance, usage patterns, configuration settings, enables you to maintain a reliable connection to Azure AD and much more.
While the currently available release in GA focusses on AD FS, a public preview of Connect Health for sync now allows you to monitor and gain insights into the sync service of Azure AD Connect. For more information, see the blog post Azure AD Connect Health for sync is now in Public Preview!.
Deployment integration with Azure AD Application proxy, additional sync and sign on options will be also added in the future. It represents a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure.
Azure AD Connect Health is a feature of the Azure AD Premium edition (see later in this document) and represents a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure. For more information, see the article Monitor your on-premises identity infrastructure in the cloud.
For multi-forest scenario, the Azure AD Connector is being deprecated in favor of the Azure AD Connect tool.
Generally speaking, and as outlined before, the Azure AD Connect tool use should be the preferred solution. The primary reasons are listed hereafter:
Important note Azure AD Premium incudes the usage rights for FIM server licenses and CALs. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
Using the Azure AD connector with FIM 2010 R2 remains available for existing customers. Organizations can thus continue to completely control partitioning of information between on-premises and the cloud, support AD multi-forest environments (as Azure AD Connect does) and support other directories and data sources other than AD – for example OpenLDAP or SAP (as Azure AD Connect will).
New deployments on the basis of this solution are however no longer recommended.
The connector is available on the Microsoft Download Center.
Important note The Azure AD connector does not provide password (hash of hash) sync support.
Important note The Azure AD Connector provides support for directory synchronization only. In other words, the 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 or the Azure AD Graph API.
It is recommended to deploy the Azure AD Connector on a dedicated FIM instance. While the deployment of the Azure AD on an existing FIM 2010 R2 server is possible (but not supported), it will also increase the complexity of the configuration and make troubleshooting and maintenance more difficult.
Note For more information, see the Microsoft TechNet article Azure Active Directory Connector for FIM 2010 R2 Technical Reference.
As you already know, the Azure AD 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 Azure AD 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 documentation describes these properties and shows which ones are write-able. It supports managing all directory objects including Users, Groups, Contacts (delete/update), user license assignment, and managing user's manager and direct report relationships.
Through these two interfaces, you can automate provisioning operations such as the creation, modification or deletion of objects in your 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 Azure AD directory tenant to the Exchange Online directory.
Note Exchange Online remote PowerShell is in no way tied to the Azure AD Module for Windows PowerShell. By connecting to the Microsoft Exchange Online services, you connect to the Microsoft Exchange Online datacenter's 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 Service and the blog post Using Exchange Management Shell to manage your Exchange Online and Exchange On Premises Environment.
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 Online.
Be aware that theses interfaces do not provide the same set of capabilities as the previously discussed directory synchronization tools provided by Microsoft. More specifically:
Consequently, the use of interfaces for object provisioning purposes should currently be limited to scenarios where:
As such, the Azure AD Module for Windows PowerShell (and potentially the Azure 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 single or multi-forest scenarios:
Scenario | Azure AD Connect | Windows PowerShell provisioning | Azure AD Graph API provisioning |
Cloud identities:
| Recommended | Available Performance limitations may apply | Available Performance limitations may apply |
Federated identities | Recommended | Available
| Available (as per version 2013-11-08 and above) |
Exchange Hybrid deployments ("rich coexistence") for Office 365 customers | Required | Not available Required attributes are not exposed | Not available Required attributes are not exposed |
Current version of the Azure AD Connect tool does not provide a support for non-AD directories (LDAP directory, SQL database, and others).
Unlike the Azure AD Connect tool, the Azure AD Connector does not require an Active Directory to synchronize from. (It uses the FIM Metaverse as a source). Consequently, almost any directory or combination of directories may be used as a synchronization source, provided that a FIM management agent (or connector) is available to support this directory or directories.
The Microsoft TechNet article Management Agents in FIM 2010 R2 provides a list of management agents that are available with FIM such as the Forefront Identity Manager Connector for Generic LDAP for LDAP directories.
Note The next version of FIM is currently Microsoft Identity Manager (MIM) 2016.
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 SourceForge.
As also discussed in the previous section, Azure AD Module for Windows PowerShell and the Azure AD Graph API may also be used to automate the provisioning and maintenance of Azure AD identities.
The Azure AD 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. In the latter situation, the Azure AD Graph API can be leveraged.
For instance, to create a federated user for Office 365, proceed with the following steps:
PS: C:\Windows\system32> Import-Module MSOnline
PS: C:\Windows\system32> Connect-MsolService
PS C:\Windows\system32> Get-MsolAccountSku
PS C:\Windows\system32> New-MsolUser -DisplayName user1 –UserPrincipalName user1@corpfabrikam.onmicrosoft.com -UsageLocation FR -BlockCredential $false –ImmutableId 81372
PS: C:\Windows\system32> Set-MsolUserLicense -UserPrincipalName user1@corpfabrikam.onmicrosoft.com -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 the Optimal IdM solution.
This said, keep in mind notably that:
The following table synthetizes the available options for on-premises non-AD directories scenarios:
Scenario | Azure AD Connector | Windows PowerShell provisioning | Azure AD Graph API provisioning |
Cloud identities
| Available | Available Performance limitations may apply | Available Performance limitations may apply |
Federated identities with a supported on-premises Security Token Services (STS) | Available Non-AD synchronization through FIM 2010 R2 provided that a FIM management agent is available to support the on-premises directory or directories. | Available | Available (as per version 2013-11-08 and above) |
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.
This section as its title indicates addresses the identity federation topic (aka single sign-on) from the Azure AD perspective, which is the second integration capability provided by Azure AD.
Setting up identity federation for domain(s) within your Azure AD directory tenant requires to conduct a few steps as outlined in the classic Azure management portal.
Identity federation in general is also a broad topic, with many facets, depths of understanding, protocols, standards, tokens, etc. As an illustration, Wikipedia 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."
As such, it requires preparation to be successful in this area and, more specifically in the context of Azure AD, to fulfill the requirements for this integration capability. This is the purpose of the step two in the above snapshot.
Moreover, as previously outlined, whilst single sign-on (aka 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 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 Azure AD environments. See the previous section to see how to synchronize your directory 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.
Azure AD publishes at login.microsoftonline.com level several endpoints that serve for establish a federation and do single sign-on with an on-premises identity infrastructure:
Azure AD publishes a federation metadata document for these addressable endpoints. For that purpose, Azure AD publishes two metadata endpoints to federate your directory with your on-premises supported STS:
https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml.
Note The general syntax and semantics of these metadata are defined in the OASIS Web Services Federation Language (WS-Federation) Version 1.2. It covers the configuration data (endpoint URLs, key material for verifying signatures, etc.) to establish trusts between WS-* entities.
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
Note The general syntax and semantics of metadata are defined in the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. It covers the configuration data (endpoint URLs, key material for verifying signatures, etc.) to establish trusts between SAML 2.0 entities.
As per the above metadata, 2 public endpoints are published by Azure AD for the interaction with organization's on-premises identity infrastructure:
The former endpoint is the one that renders the credential user interface for Azure AD and that triggers a home realm discovery (HRD) / where are you from (WAYF) process for federated identities as previously illustrated.
As of writing, Active Directory Federation Service (AD FS), as well as a list of third-party identity providers' implementation enable this integration capability.
Above federation standards, i.e. WS-* (WS-Federation and WS-Trust) 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 help in reducing the probability of such side-effects.
In this context, the Works with Office 365 – Identity program provides qualification requirements, technical integration documents for the above protocols as well as information on how to conduct interoperability testing via the automated testing tool Connectivity Analyzer, thus enabling a predictable and short qualification path.
The related program guide provides:
It also provides the Office 365 SAML 2.0 Federation Implementer's Guide v1.0 in terms of implementation using a SAML 2.0 compliant SP-Lite profile STS.
As seen in the previous section, directory synchronization options differ whether your on-premises identity infrastructure relies on WSAD or not.
Note Directory synchronization feature that can be part of the third party solution is not tested as part of the program.
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 Directory Sync through the Azure AD Connect tool (or the DirSync tool or the Azure AD Connector) | Non-AD directory source Directory sync or provisioning to be implemented using FIM + Azure AD Connector or custom solutions |
AD FS (WS-Federation, WS-Trust) | Available
| Not available
|
Shibboleth 2 (SAML 2.0) | Available
For Office 365 customers:
| Available
For Office 365 customers:
|
Other STS | Solutions along with their related scope listed on the Microsoft TechNet article Azure Active Directory federation compatibility list: third-party identity providers that can be used to implement single sign-on. Generic WS-* or SAML 2.0 support is provided through the aforementioned Works with Office 365 – Identity program. | Solutions along with their related scope listed on the Microsoft TechNet article Azure Active Directory federation compatibility list: third-party identity providers that can be used to implement single sign-on. Generic WS-* or SAML 2.0 support is provided through the aforementioned Works with Office 365 – Identity program. |
(1) Requires the modern authentication (a.k.a. Active Directory Authentication Library (ADAL) based authentication stack) for Office 365 ProPlus/Office 2013.
(2) Requires installation of the Shibboleth 2 Enhanced Client Proxy (ECP) extension.
The rest of this section further discusses the federation with AD FS and Shibboleth 2.
Once successfully configured, the federated domain(s) are managed via the cmdlets of the Azure AD Module for Windows PowerShell.
As of writing, the primary option in terms of enterprise identity providers for the single sign-on (aka federation) feature of Azure AD is Active Directory Federation Services (AD FS) that the organization deploys on-premises and then configures Azure AD to securely communicate with.
AD FS in Windows Server 2012 R2 is a component of the Windows Server platform and, as such, the right to use it is included in the associated license costs. Same is true for legacy versions of AD FS (AD FS 2.0 and AD FS in Windows Server 2012),
Important note As far as the legacy version AD FS 2.0 is concerned, the AD FS role available in Windows Server 2008 or in Windows Server 2008 R2 doesn't correspond to AD FS 2.0; this is the previous version 1.1 instead. The AD 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. For Windows Server 2012, the AD FS server role includes the same functionality and feature set that is available in AD FS 2.0.
Important note As of writing, and as far as legacy version AD FS 2.0 is concerned, the update rollup 3 for AD FS 2.0 is available. This update rollup 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 2790338 Description of Update Rollup 3 for Active Directory Federation Services (AD FS) 2.0.
The Microsoft TechNet article Checklist: Use AD FS to implement and manage single sign-on provides instructions for Azure AD administrators who want to provide their Active Directory users with single sign-on experience by using AD FS as their preferred STS. It covers AD FS on Windows Server 2012 R2 as well as AD FS on legacy versions of Windows Server.
The white paper Azure AD/Office 365 Single Sign-On (SSO) with AD FS in Windows Server 2012 R2 provides detailed information on planning and configuring the single sign-on feature for Azure AD/Office 365 with AD FS in Windows Server 2012 R2.
Likewise, as far as AD FS on legacy versions of Windows Server is concerned, the white paper Microsoft Office 365 Single Sign-On (SSO) with AD FS 2.0 covers the same topics from an AD FS 2.0 perspective.
These two papers indeed aim at providing a better understanding of the different single sign-on deployment options for Azure AD (and the services in Office 365) with AD FS, how to enable single sign-on using corporate AD credentials and AD FS to Azure, the services in Office 365, and the different configuration elements to be aware of for such deployment.
Note In AD FS in Windows Server 2012 R2, the role of a federation server proxy is handled by a new Remote Access role service called Web Application Proxy (WAP). To enable your AD FS for accessibility from outside of the corporate network (in other words, to configure extranet access), which is the purpose of deploying a federation server proxy in AD FS on legacy versions of Windows Server, you can deploy one or more Web Application Proxies for AD FS in Windows Server 2012 R2. For more information about the Web Application Proxy, see the Microsoft TechNet Web Application Proxy Overview.
As outlined before, in addition to AD FS, support for additional STS has been added, so that organizations may continue to use their existing on-premises identity infrastructure for single sign-on with Azure AD and the Microsoft services such as Office 365, Dynamics CRM Online, and other, 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 Azure AD.
Shibboleth 2 is one of these additional identity providers. Shibboleth 2 (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) in 2000. The project now hosted by the Shibboleth Consortium refers 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.
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 Azure AD supports the SAML 2.0 web browser single sign-in profile, the SAML 2.0 web browser single sign-out profile, as well as and the Enhanced Client or Proxy (ECP) profile.
Note The SAML 2.0 ECP profile is an adaptation of the SAML 2.0 browser single sign-in profile with the parts that were designed around the limitations of a browser removed. In other words, in the SAML 2.0 ECP profile, the user agent is assumed to be something more than a browser (or perhaps a browser with a plugin for example).
Note These profiles supports various possible deployment models. The ones implemented here are the HTTP-Redirect and HTTP-POST bindings specified in the document Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. For more information, see the Microsoft MSDN articles Single Sign-on (SAML Protocol) and Single Sign-out (SAML Protocol).
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) single sign-on (aka federation) with Microsoft and non-Microsoft federation solutions.
The white paper Azure AD/Office 365 Single Sign-on (SSO) with Shibboleth 2.0 provides information on planning and configuring the single sign-on feature for 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.
Note For information on the prerequisites as well as on the installation and the configuration of a Shibboleth IdP, we invite you to visit complementarily the documentation made available by the Shibboleth Community.
Many organizations rely upon Software-as-a-Service (SaaS) applications like Office 365, Box and Salesforce, and many others.
Imagine indeed a business requires a new application to enhance the relationships with customers, and the key points regarding this application are a limited budget and a short time frame to deliver it. This leads the IT considering a public cloud application, which brings interesting capabilities like scale economies, time-to-market and unlimited scalability.
Furthermore, with the ability to subscribe at any time a cloud application to quickly help answering some business imperatives, campaigns, etc., with the freedom of choice, the flexibility, the perceived non-dependency on IT such an open marketplace on the Internet provides to entities within an organization, many more SaaS applications are also potentially in use as IT estimates. This situation leads organizations towards a "Shadow IT" with all the concerns about unauthorized access to corporate data, possible sensible data leakage and other security risks inherent in the SaaS applications in use. Without exactly knowing how many cloud applications or which applications are being used, even getting started building a plan to deal with these risks seems daunting…
The Cloud App Discovery service of Azure AD constitutes a first step to help IT having an accurate visibility into which cloud application are in use within the organization. IT can then take steps to integrate the SaaS applications in use with Azure AD through the Application Access Enhancements for Azure AD (see next section).
This service is available in the new Azure portal at https://portal.azure.com/. The portal allows you to add the Cloud App Discovery tile to your Startboard.
Important note This service is only available when you enable the premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
Once added, this service allows your IT to:
Note For more information, see the blog posts Azure Cloud App Discovery is now GA and Azure Cloud App Discovery GA and our new Privileged Identity Management service, as well as the Microsoft TechNet wiki article Cloud App Discovery - Frequently Asked Questions.
To achieve the above, and thus in order to discover the cloud applications in use, and thus to collect application usage information, the Cloud App Discovery service uses an agent. This agent can be deployed on all (or some representative) machines in the organization that run Windows 7 and above.
The agent captures HTTP usage information, i.e. URLs, headers and metadata for HTTP/HTTPs accesses originating from the machine on which it runs. This allows the agent to capture requests to all cloud applications accessed over HTTP or HTTPs.
Note Every access to an application's web site typically includes multiple different requests to the site to retrieve different parts of the web-page. The browser will actually make over dozens of additional web requests for content like pictures, social plugins and other resources. See the snapshot below.
For known cloud applications in the database, the Cloud App Discovery service includes an optimization that only counts webpage loads once so that the Cloud App Discovery Service can ignore counting every access to various elements of the webpage. However, this is an area we're looking to continue to make improvements on.
The agent also captures the username of the user on the machine. The agent sends the collected traffic over a secure, encrypted channel to the Cloud App Discovery service. The data in the service is only visible to the administrators of the tenant. Each tenant admin can only see the data for their tenant, and no other tenant's.
To start using the Cloud App Discovery service and deploying the agent on the windows machines, proceed with the following steps:
Note A blade is one piece of the overall view. You can think of a blade as a window.
Note For a complete step-by-step walkthrough of the management experience in the new Azure portal, and the installation of the agent, see the Microsoft MSDN article Cloud App Discovery.
The Cloud App Discovery service can be further configure to route the data collected to an Azure Blob storage in order to perform analytics on the data in tools like Excel and Power BI.
Note For a complete walkthrough for the dashboard, see the blog post Cloud App Discovery: Now with Excel and Power BI Support.
The Application Access Enhancements for Azure AD simplifies managing access to thousands of pre-integrated cloud SaaS applications (and more in the coming months) and introduces security and access governance controls that enable IT to centrally manage users' access across them.
As part of these free enhancements for Azure AD, the Azure AD application gallery provides a wide variety of popular pre-integrated SaaS applications that your users can single sign-on to from Azure AD today. This includes Microsoft's cloud apps and services like Office 365, and Dynamics CRM Online and third party applications like Salesforce and Box that you may already be using and want to connect to Azure AD.
Several types of applications appear in the application gallery, covering the whole spectrum in terms of application integration capabilities:
Microsoft is working with key partners in the ecosystem to establish these connections, meaning you no longer have to continually update user records in multiple systems.
The application gallery indicates which of these features are supported in the application description, as well as provide a link to learn more about the application including any prerequisites.
As mentioned before, the Application Access Enhancements for Azure AD enable to add thousands of cloud pre-integrated SaaS applications like ADP, Concur, Google Apps, Salesforce.com and others, regardless of the public cloud they are hosted on. The pre-integrated SaaS applications are preconfigured via an application gallery with all the parameters needed to at least provide a seamless sign-in experience with them. Let's see how to add such a SaaS application.
With a few simple steps, you can select from the list of applications that are pre-integrated in the application gallery.
To add an application from the application gallery, proceed with the following steps:
As aforementioned, the related steps depend on the application capabilities and more especially whether it uses federation or password vaulting, and whether it supports automatic provisioning of users or not.
In this illustration, Configure single sign-on enables you to specify how you would like users to sign on to that app. The next steps depend on the selected options.
As illustrated here, and in accordance to the previously discussed integration options, Azure AD supports three different modes for single sign-on:
Note For additional information regarding Salesforce, you can watch the Channel 9 demo video Integrating Salesforce with Azure AD: How to enable Single Sign-On (1/2).
If supported by the application, Configure account provisioning allows you to configure the automatic user provisioning with the application from your Azure AD tenant.
Note For additional information, you can watch the Channel 9 demo video Integrating Salesforce with Azure AD: How to automate User Provisioning (2/2).
Note For more information, see the Microsoft MSDN article Application access capabilities for Azure Active Directory.
Detailed integration tutorials are available to show you how to configure Azure Active Directory single sign-on for third party SaaS applications. The tutorials for Salesforce, Salesforce Sandbox, Box, Google Apps, and Citrix GoToMeeting, Concur, Workday, Jive, DocuSign, Servicenow, and Dropbox for Business are simply a few of the more than hundred of tutorials available.
For those of you who are using Office 365, you will find that the Office 365 application access is automatically supported within the Azure management portal and no additional configuration is required.
Note For more information, see Microsoft TechNet article Best Practices for Managing the Application access enhancements for Azure Active Directory.
Once your application has been configured to use Azure AD, then it is almost ready to use. As a security control, Azure AD will not allow users to have an access into the application unless they have been granted access. Users may be granted access directly, or through a group that they are a member of. You can follow the directions outlined in section § Managing access to applications to quickly assign it to your employees.
For the moment, let's consider some additional features regarding your ability to further configure the SaaS application.
The SAML token attributes for SaaS application feature, also known as claims transformation language, allows you to manipulate existing claim assignments or add additional claim assignments for SAML 2.0 based authentication for a SaaS application in Azure AD.
Using SAML token attributes, you can:
SAML token attributes is available on pre-integrated SaaS applications listed in the application gallery, and that support federated single sign-on.
When using Azure AD to provide user provisioning to third-party SaaS applications, the classic Azure Management Portal controls the attribute values in form of a configuration called "attribute mapping".
There is a preconfigured set of attribute mappings between Azure AD user objects and each SaaS application's user objects, however, you can customize the default attribute mappings according to your business needs. This means that you can change or delete existing attribute mappings or create new attribute mappings. In other words, this feature (in public preview as of this writing) gives you the ability to customize which set of attributes from Azure AD will get synced into the considered SaaS application you are using Azure AD to manage.
Note For additional information, see the blog post Azure AD Custom Attribute Mapping for SaaS App User Provisioning and the Microsoft MDSN articles Customizing Attribute Mappings and Writing Expressions for Attribute Mappings in Azure Active Directory.
You will probably notice that some mappings are labeled as "calculated," which means that we are taking the information of one or more source attributes and then modifying them into the desired format for the target attribute. You will be able to edit and define your own calculated mappings in a future update.
The other type of mapping is labeled as "default." Rather than mapping an attribute from Azure AD, default mappings instead fill the target attribute with a constant value. You will also be able to edit default mappings in future releases of this feature.
Besides the ability to easily configure pre-integrated SaaS applications from the app gallery, you may desire the ability to onboard any applications you need in a self-service fashion. This can include custom applications that your organization has developed, third-party web applications that your organization has deployed to servers you control, or SaaS applications that you use but have not yet been on-boarded to the application gallery.
Since the end of last year, you are provided with such an ability to configure any custom application.
Note For more information, see the blog post Wrapping up the year with a boat load of Azure AD news!.
To integrate a custom application, proceed with the following steps.
As you can see, adding a custom application provides a very similar experience to the one available for pre-integrated SaaS applications.
Let's see how to configure single sign-on.
Configuring single sign-on for a custom application also provides a very similar experience to the one available for pre-integrated SaaS applications.
To start, proceed with the following steps.
Note For additional information, see the blog post "Bring your own app" with Azure AD Self-Service SAML configuration -> now in preview.
By using either of these options, you can also to enable other benefits of Azure Active Directory such as multi-factor authentication, and security and audit reporting (see later in this document).
To illustrate the process, let's configure for example a SAML-based authentication. Select Microsoft Azure AD Single Sign-On, and then click the arrow icon at the bottom right. You will be prompted to enter three different URLs for the application.
Note Which values are required will vary depending on your custom application. The sign-on and sign-out service URL both resolve to the same endpoint, which is the SAML 2.0 request-handling endpoint for your Azure AD tenant. For more information, see the white paper Leverage Azure AD for modern business applications. The Issuer URL is the value that appears as the "Issuer" inside the SAML token issued to the application.
Click Download certificate.
In addition to the above single sign-on capability, the Premium edition of Azure AD provides an automatic account provisioning capability in preview (see second option hereafter).
This capability is based on the support of the Cross-domain Identity Management (SCIM) 2.0 standard, i.e. an open API for managing identities and provisioning workloads.
Note For more information, see the blog posts Azure AD Premium now supports SCIM 2.0! and Azure AD: Helping you adding SCIM support to your applications.
It can be used in conjunction with the so-called "Bringing Your Own Application" (BYOA) capability discussed in this section to enable not only single sign-on (as per previous section) but also automatic user provisioning for a custom application. For that purpose, the considered custom application must provide or be fronted by a SCIM-based façade/web service. In other words:
- or -
Note To ease the development, Common Language Infrastructure (CLI) libraries are provided as a NuGet package (Microsoft.SystemForCrossDomainIdentityManagement) to build a SCIM endpoint and translate SCIM messages.
In addition, a series of sample code packages to implement a SCIM-based provisioning façade and demonstrate the automatic provisioning capability is available on GitHub. Theses sample code packages illustrate how to use the CLI libraries with "Bringing Your Own Application" (BYOA) for the provisioning scenarios outlined here.
Once configured, Azure AD will send requests to create, modify and delete assigned users and groups to the configured SCIM-based provisioning endpoint, which can then honor those requests, and translate them into operations upon the identity store used by the custom application.
To illustrate the configuration process from an Azure AD perspective, proceed with the following steps:
There is a preconfigured set of attribute mappings between Azure AD user objects and each custom application's user objects, however, you can customize the default attribute mappings according to your business needs.
As noticed before for pre-integrated SaaS applications, Azure AD will not allow users to have an access into the custom application unless they have been granted access. Users may be granted access directly, or through a group that they are a member of.
Note Around ten minutes may elapse before the provisioning process will begin to send requests to the specified SCIM-based provisioning endpoint URL for the custom application. A summary of connection attempts is provided in DASHBOARD, and both a report of provisioning activity and any provisioning errors can be downloaded from REPORTS.
Note For more information, see the article Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to applications.
With the ability of Azure AD to manage access to cloud based applications as covered in the previous sections, i.e. the ones the organization is developing and/or the ones the organization is subscribing to, the next question that inevitably comes in mind is "How can I manage access to the organization's on-premises web applications?"
The Azure AD Application Proxy allows to extend the discussed Azure AD's pre-integrated SaaS and custom application management capabilities to your on-premises traditional applications, giving you the ability to manage conditional access to (Windows and on-Windows) web based applications. You can then make these apps available in a secure manner to authenticated users through a cloud proxy hosted in Azure.
Important note This feature is only available when you enable the premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
The Azure AD Application Proxy is a reverse-proxy as a service that builds on the Web Application Proxy (WAP) capability built for and available as a server role in Windows Server 2012 R2.
Note For additional information, see the Microsoft TechNet article Web Application Proxy.
It enables selective publishing of application endpoints on HTTP(S) that are hosted in Azure, so any type of device and browser can connect to them.
This implies the installation of a light weight software agent (a.k.a. a connector) on-premises typically at the backend application tier: the Azure AD Application Proxy connector is deployed usually on the organization's corporate network next to resources.
The Azure AD Application Proxy connector calls out the proxy by issuing outgoing HTTP(S) requests to the cloud proxy service. Unlike a VPN connection, there is no direct inbound access to the corporate network. This greatly limits the attack surface area exposed.
Note The Azure AD Application Proxy Connector Troubleshooter allows you to easily troubleshoot network issues on the connector machine like closed outbound ports. For additional information, see the blog post Troubleshooting tool to validate connector networking prerequisites.
Users connect to the cloud proxy service that performs a set of validation checks. The cloud proxy service can for instance challenge for step-up multi-factor authentication. Once that is completed, the proxy attempts to rout the traffic to the resources via the connector. In other words, the cloud proxy service sends back responses which contain a payload of incoming requests from a user which are routed from connector to the on-premises target resource.
Multiple connectors can be deployed for redundancy, scale, multiple sites and different resources for scalability and advanced topology scenarios. For example, thanks to connector groups, if you have multiple branch offices in different regions, or if you want to ensure redundancy in case of failure.
Note For additional information, see the blog post Publishing apps on separate networks and locations using connector groups.
The benefit of this architecture is that there is no infrastructure for you to operate in the DMZ, and users can access your on-premises applications without gaining direct access to your network as illustrated hereafter.
Note For additional information, see the Microsoft TechNet article Using Application Proxy to publish applications for secure remote access.
To enable the Azure AD Application Proxy service, proceed with the following steps:
Note For more information, see the Microsoft MSDN article Enable Application Proxy services.
You will then need to install the Azure AD Application Proxy connector inside the organization's corporate network on at least one computer running Windows Server 2012 R2 and register it with your Azure AD tenant.
To deploy the Azure AD Application Proxy connector on an on-premises server, proceed with the following steps:
At this stage, you can publish selected on-premises applications so that they can be made accessible to your users outside your private network.
Any web app over the HTTP 1.1 protocol can work, for example SharePoint web site, Outlook Web App (OWA), Lync Web App, ASP.NET web site, IIS applications, Windows Server 2012 R2 Work Folders, or any other homegrown or third parties' applications.
Note For more information, see the Microsoft TechNet article Publish applications with Application Proxy.
To publish an on-premises web application, proceed with the following steps:
The proxy service assigns a unique external URL for you that can be used to access the application from outside your private network. The URL is automatically generated based on the name you provided in the previous step, the related directory, and the suffix msappproxy.net.
This enables to benefit from the additional security capabilities such as Distributed Denial of Service (DDoS) protection, auditing and anomaly detection, etc.
- or -
Interestingly, the Azure AD Application Proxy supports the use of a custom verified domain name for the published on-premises application so that users can feel "at home" when access it.
To use a custom verified domain name, proceed with the following steps:
Note For more information, see the blog post Azure AD Application Proxy now supports custom domain.
Like the pre-integrated SaaS and custom applications, Azure AD will not allow users to have an access into the application unless they have been granted access. Users may be granted access directly, or through a group that they are a member of. You can follow the directions outlined in section § Managing access to applications to quickly assign it to your employees.
Modern business applications you're developing can be easily integrated with your directory and granted access to that directory so that you can easily provide single sign-on capabilities (sign in and sign out), manage the user authorization, etc. without the additional cost, burden, and hassle of having to acquire and manage new user credentials. This comprises not only homegrown web applications, web APIs but also native applications.
Note A native application is an application that is installed on a device such as a phone or computer. The combined influence of growing presence of devices in business environments with the Consumerization of IT and the Bring Your Own Device (BYOD) trends, 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 native 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.
Note For more information, see the Microsoft MSDN article Integrating Applications in Azure Active Directory.
For the federated users, a seamless end-to-end single sign-on (federated) experience can be delivered for users logging on their Windows 10 Azure AD joined machines, Windows domain-joined machines and their Workplace joined devices on (exposed) on-premises applications and other applications integrated in your Azure AD directory. Such an experience requires to federate your directory with your on-premises STS, and may require to sync the devices objects between your Azure AD directory and your on-premises identity infrastructure depending on your configuration in place.
Furthermore, if you're a developer or a cloud ISV, you can allow for external users a web application (or a web API) that you've previously registered in your Azure AD directory and consequently make it available with one click for use by any other Azure AD customer. With one click, those customers can in turn add your web application (or web API) to their own directory tenant giving it a clearly called out set of privileges. They get the benefit of using Azure AD to administer access to your application with one click, you get the benefit of offering world class enterprise directory capabilities that can be easily connected to your customers existing on-premises directory infrastructure.
The aforementioned white paper Leverage Azure AD for modern business applications details the registration process in directory tenant(s) and how to (build and) configure such applications to provide sign up for multi-tenant applications, single sign-on for cloud and federated users, and more.
To simply illustrate the related operation, let's consider a (fictitious) single-tenant web application you're developing.
To add a single-tenant application, proceed with the following steps:
Note For more information, see the MSDN article Adding, Updating, and Removing an App .
Like the pre-integrated SaaS, custom, and published on-premises applications, Azure AD will not allow users to have an access into the application unless they have been granted access. Users may be granted access directly, or through a group that they are a member of. You can follow the directions outlined in next section § Managing access to applications to quickly assign it to your employees.
You can assign access privileges to your applications to the users in your Azure AD directory tenant assuring that every employee has access to the applications they need. Interestingly enough, when a user leaves your organization or changes jobs within the company, you can just as easily remove their access privileges assuring data security and minimizing IP loss.
A single, unified administrative experience for all of your applications is provided, whether it is a pre-integrated SaaS application, a custom application, a published on-premises web application (provided that pre-authentication has been chosen for publishing), or a modern business application you're developing. Let's see how this works.
To manage application access to users, proceed with the following steps:
Important note If you have enabled the Basic or the Premium editions of Azure AD, click USERS AND GROUPS instead. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
Users can be created directly on Azure AD or originated from the on-premises AD that is synced to Azure AD. (See section § Synchronizing your directory with Active Directory on-premises earlier in this document.)
Important note If you have enabled the Azure Active Directory Premium, next to SHOW, select All Users in the drop-down list.
Then click the check mark icon. You can then proceed as instructed is step 2.
Note With a pre-integrated SaaS application configured with password single sign-on, such as the Skype application hereafter, you can directly configure the user's credentials (username and password) for this application. For that purpose, select I want to enter Skype credentials on behalf the user while enabling access (or through the EDIT ACCOUNT button after the access has been enabled).
If you choose not to do this, the user will need (and be able) to enter their own credential through the Azure AD Access Panel. The users can only see in the Access Panel the applications the administrator has granted them access.
Note The above capability can be leveraged for shared organization's accounts to be used with some pre-integrated SaaS applications. In such a context, and more specifically for the pre-integrated Facebook, Twitter, and LinkedIn applications, you will have the ability to enable an automatic password rollover. For that purpose, select in addition I want to enable an automatic password rollover.
After clicking the check mark icon, you will be then provided with the ability to configure the password rollover.
A browser based end-user Azure AD Access Panel, My Apps mobile applications, or Azure AD single sign-on links make it easy for users to find and then launch with a single sign-on experience applications that are assigned to them (See section § Empowering users later in this document).
A group is a collection of users and groups that can be managed as a single unit. Users and groups that belong to a particular group are referred to as group members.
As with Active Directory on-premises, using groups in Azure AD can simplify administration by assigning a common set of permissions and rights to many accounts at once, rather than assigning permissions and rights to each account individually. Groups can be created directly on Azure AD or originated from the on-premises AD that is synced to Azure AD. (See section § Synchronizing your directory with Active Directory on-premises earlier in this document.)
Note For more information, see the article Managing access to resources with Azure Active Directory groups.
To use groups in lieu of users to control access to SaaS applications, proceed with the following steps:
Important note This feature is only available when you enable Azure Active Directory Premium. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
The Dynamic membership for groups feature represents the first step in the efforts to support Role Based Access Management (RBAC) in Azure AD.
Important note This feature is only available when you enable the premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
With this feature, you can now specify a rule on a security group that will automatically manage the membership of that group based on user's attribute values. Dynamic membership enables you to define a group using single attribute rules, such as "All users where Department equals Sales", or you can configure complex rules including logical operators to combine clauses, such as in "All users where Department equals Sales or Marketing and Job title contains Manager".
A typical scenario would then give this group access to some applications. (It can also serve to automatically assign to users Office 365 licenses.)
Note For additional information, see the blog post Attribute based Dynamic Group Membership for Azure AD Premium is now in Preview. You can also watch the Channel 9 demo video Azure AD: Introduction to Dynamic Memberships for Groups.
To configure a rule to manage memberships on a security group, proceed with the following steps:
Important note To enable the dynamic rules evaluation, you need to enable delegated groups Management feature (see DELEGATED GROUP MANAGEMENT ENABLED under group management in the directory CONFIGURE page).
When first configuring a rule for a group, all users in your Azure AD tenant are scanned to find which users satisfy the rule you provided, and all matching users are added as members to the group. Subsequent changes to user's attributes, such as when a user changes job titles or departments, or when a new user joins, will trigger a re-evaluation of the rule and the outcome of that evaluation will be reflected in the user's group memberships.
You can then use the dynamic group as per previous section.
As discussed in the Active Directory from the on-premises to the Cloud whitepaper, the rapid increase in the number of consumer devices and ubiquitous information access is changing the way that people perceive their technology. The constant use of information technology throughout the day, along with easy access of information from everywhere, is blurring traditional boundaries between work and home life. These shifting boundaries as a result of the consumerization of IT (CoIT) are accompanied by a belief that personal technology should extend into the workplace.
To accommodate the growing requirement of personal consumer devices to access the organization's applications, Windows Server 2012 R2 has introduced the AD Workplace Join capability on-premises. This capability allows users to join their devices with the organization's workplace and thus enables their devices to be provisioned with an identity. When a device is joined by Workplace Join, it becomes a known device, provides seamless second factor authentication to access to the organization's applications, and attributes of the device can be retrieved from AD to drive conditional access for the purpose of authorizing issuance of security tokens for these applications.
Workplace Join is made possible on-premises by Device Registration Service (DRS) that is included with AD FS in Windows Server 2012.
Note For additional information, see the Microsoft TechNet article Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.
The registered devices can then be used in the conditional access policies that are available in AD FS in Windows Server 2012 R2.
Note For more information, see the Microsoft TechNet article Manage Risk with Conditional Access Control as well as the Azure AD/Office 365 single sign-on (SSO) with AD FS in Windows Server 2012 R2 – Part 1 whitepaper.
Azure AD provides similar features and beyond. Let's consider them.
The Azure AD Device Registration (Azure AD DRS) enables Workplace Join and register devices in Azure AD in lieu of on-premises with DRS. Azure AD DRS enables employee's devices to be provisioned with an identity.
When a device is registered, Azure AD DRS provisions the device with an identity in the Azure AD tenant which is used to authenticate the device when the user signs in. The authenticated device, and the attributes of the device, can then be used to enforce conditional access policies for applications that are hosted in the cloud and on-premises.
Once a policy is set to require compliant devices to access Office 365, Azure AD authenticates the device and checks whether the device is complaint before allowing access to Office 365 services such as email and SharePoint.
Note The registered devices can also be used in the above AD FS similarly to what could previously be achieved through the deployment of DRS. This requires device objects write-back to AD from Azure AD as per synchronization between the two. (See section § Synchronizing your directory with Active Directory on-premises before in this document).
To enable Azure AD DRS, proceed with the following steps:
Note Enrollment with Microsoft Intune (or Mobile Device Management for Office 365) requires Workplace Join. If you have (already) configured either of these services, ALL will be already selected for USERS MAY REGISTER THEIR DEVICES WITH AZURE AD.
Furthermore, and by default, multi-factor authentication is not enabled for the service. However, requiring multi-factor authentication is recommended for joining devices to Azure AD. Click YES next to REQUIRE MULT-FACTOR AUTH TO JOIN DEVICES if users that are connecting to the workplace from the Internet must use a second method of authentication before they can workplace join their device. This said, you MUST prior configure a MFA solution and configure your user accounts for Multi-Factor Authentication (See section § Using Azure Multi-Factor Authentication later in this document).
Once Azure AD DRS is enabled, you will then need to configure the service discovery if you have custom vanity domain(s) associated with your Azure AD tenant.
You must indeed create a DNS CNAME record that points to the A record associated with your Azure AD DRS. The CNAME record must use the well-known prefix enterpriseregistration followed by the UPN suffix used by the user accounts at your organization. If your organization uses multiple UPN suffixes, multiple CNAME records must be created in DNS. For example, if you use two UPN suffixes at your organization named @corpfabikam.com and @region.corpfabikam.com, you will create the following DNS records.
Name | Type | Value | ||
enterpriseregistration.corpfabikam.com | CNAME | enterpriseregistration.windows.net | ||
enterpriseregistration.region.corpfabikam.com | CNAME | enterpriseregistration.windows.net |
After adding the above records in your domain registrar, users in your organization who sign in on their device with an email address that uses the above suffixes can register to your Azure AD tenant.
Note For more information, see the blog post Azure AD Device Registration is now Generally Available and the Microsoft MSDN articles Azure Active Directory Device Registration Overview and Setting up On-premises Conditional Access using Azure Active Directory Device Registration.
Azure AD and Windows 10 together provide an evolution of the traditional WSAD Domain Join. Indeed, on domain joined computers, the connected Windows services (backup and restore, roaming of settings, live tiles and notifications, Windows store, etc.) will work natively with work or school accounts. There will be no longer the requirement to use a personal Microsoft Account (MSA).
Windows 10 will use Azure AD as a relay to power these experiences, which means that organizations must have a hybrid Active Directory environment in-place and thus have connected their on-premises WSAD to Azure AD to make this happen. Both synchronization and federation models will be supported in terms of identity model.
Auto-registration of these devices in Azure AD and auto-enrolment in an Azure AD supported Mobile Device Management (MDM) solution (Microsoft Intune, Mobile Device Management for Office 365, or 3rd party solution) will be all supported.
This new feature of Windows 10 Pro and Windows 10 Enterprise editions is called Azure AD Join.
With this new feature, Windows also will enable a device to join an Azure AD tenant without needing the traditional WSAD domains on-premises if you want to. In this cases, Windows will directly authenticate to Azure AD. You can then enjoy a cloud-only environment and this only requires that your organization provisions an Azure AD tenant.
Note For more information, see the whitepaper Azure AD & windows 10: Better Together for Work or School.
To enable Azure AD Join in addition of the Azure DRS, proceed with the following steps:
When a Windows 10 device will join Azure AD, you are provided with the ability to configure additional administrators to later have administrative privileges on it.
Now that you now the various options to register a device, let's deal with the conditional access control.
Conditional Access is the ability to define different access rules for applications based on the business needs, user location and the device that is used. This feature is available for all the federated pre-integrated SaaS applications, your on-premises applications that use Azure AD Application proxy, your Line of business (LOB) applications that your organization has specifically developed for and registered in Azure AD, as well as multi-tenanted applications developed by other organizations. Conditional access rules are independent of the supported protocol used by the application if any (WS-Fed, SAML 2.0, OpenID Connect 1.0 or OAuth 2.0).
Important note This feature is only available when you enable the premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
To define conditional access rules for an application, proceed with the following steps:
Click Add Group and then specify the groups in the eponym dialog. Click the check mark once done.
Thanks to the first two options, you can require just username and password or multi-factor authentication (MFA) to login into an application depending if the user is on the corporate network or off the network. The access rule work with Azure MFA. They also work on-premises if you have deployed AD FS in Windows Server 2012 R2 and set up it with an MFA adapter. Azure AD will perform the conditional access check, and then redirect the MFA request to AD FS.
Note To sustain the above capability of the access rules, the default MFA behavior for federated Azure AD/Office 365 tenants has been set to occur in the cloud where in the past it was set to occur on-premises. Operations has backfilled to ensure customers that were using multi-factor authentication on-premises will continue to use their on-premises infrastructure. You can affect this behavior by downloading latest version of the Azure Active Directory Module for Windows PowerShell (64-bit version) from here and running the below commands.
To perform multi-factor authentication on-premises, you will have to run the following command:
Set-MsolDomainFederationSettings -DomainName <yourfederateddomain> -SupportsMFA $true
Where SupportsMFA as true means that Azure AD will redirected the user to AD FS for multi-factor authentication if multi-factor authentication is required and the MFA claim, is missing
To perform multi-factor authentication in the cloud for your federated domain, you will have to run the following command if you've previously set SupportsMFA to true:
Set-MsolDomainFederationSettings -DomainName <yourfederateddomain> -SupportsMFA $false
Where SupportsMFA as false means that Azure AD does multi-factor authentication natively (again assuming multi-factor authentication is required and MFA claim is missing). If flag is not set, it is assumed to be false. Users won't be double MFA'd. If multi-factor authentication was already done at AD FS as part of login, the MFA claim will be present and Azure AD won't ask for multi-factor authentication again.
Note For additional information, see the blog posts Azure AD Conditional Access and Azure AD Connect Health - Now in Preview, Azure AD Conditional Access preview updated: Now supports On-Premises and Custom LOB apps, and the Microsoft MSDN article Azure Conditional Access Preview for SaaS Apps.
The Applications Access Enhancements for Azure AD enable you to review security reports associated with the sign-ons by your organization's end-users.
With the free version of the Application Access Enhancements for Azure AD, you get access to a standard set of access reports giving you visibility into which users are using which applications, when they were using and where they are using them from. In addition, we'll alert you to un-usual usage patterns for instance when a user logs in from multiple locations at the same time.
The following anomaly reports are available for free in Azure for monitoring tenant-wide user sign-ins to Azure AD:
The Premium offering adds following machine learning-based anomaly reports:
Important note The reports below are only available when you enable the basic or the premium editions of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
Note For more information, see the blog post Azure Active Directory Premium reporting now detects leaked credentials.
The following usage, error, and activity reports are free for monitoring user provisioning to external SaaS applications:
In addition to the above reports, the following new activity log reports are now available for free to give you very detailed views of user activity:
Note For more information, see the Microsoft MSDN article View your access and usage reports.
To view or download a report, proceed with the following steps:
Note For more information, see the Microsoft TechNet article View your access and usage reports. you can watch the Channel 9 demo video Azure Active Directory Reports.
Note Activity and Events Reporting data is now also available (in preview) to developers through the Azure AD Graph API. For more details, see the guide Azure Active Directory Reporting Guide as well as the blog post Announcing the preview of Graph Reports and Events API and the Microsoft MSDN article Azure AD Reports and Events (Preview).
Beyond the above available reports for your Azure AD tenant, a first set of hybrid reports is now available in Azure AD. These reports give customers a unified visibility into both Azure AD in the cloud and MIM 2016 on-premises activity in the following two areas:
To start using the above hybrid reports, you need to download and install a connector (a.k.a. reporting agent) to hook up MIM with Azure AD reports. This connector uploads data from service requests in MIM to your Azure AD tenant's reports. With this connector, you do not need to install the traditional on-premises Identity Manager reporting component infrastructure.
To download the connector package, proceed with the following steps:
Et voilà! You can now start viewing the reporting data from REPORTS. As of this writing, you should toggle between the data sources (Azure AD or Identity Manager) using a drop-down list box.
Going forward, we plan to eliminate the drop-down box, and merge the data onto a single report.
Note If you want to turn off the uploading of reporting data from MIM, you can do this in the configuration file, located in your MIM installation folder, for example: C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config.
Note For more information, see the blog post Azure AD and Microsoft Identity Manager reporting – we've gone hybrid!.
Global administrators of the Azure AD tenant can optionally choose to enable the Azure Multi-Factor Authentication support in Azure AD to require employees to use a second-form of authentication when logging into the Cloud based and SaaS applications declared in the directory tenant (e.g. a mobile phone app, an automated phone call, or text message challenge) to enable even more secure identity access, and to protect the organization's identity data in the cloud.
Interestingly enough, the Multi-Factor Authentication service composes really nice with the SaaS support you can literally set up secure support for any pre-integrated SaaS application (complete with multi-factor authentication support) to your entire enterprise within minutes.
Azure Multi-Factor Authentication service is a paid offering available as a stand-alone service with per user and per authentication billing options, or bundled with Azure AD Premium and Enterprise Mobility Suite (EMS).
Note For additional information, see Multi-Factor Authentication Pricing Details.
To leverage this service with:
Note For more information, see Microsoft TechNet article Using Multi-Factor Authentication with Azure AD. You can also watch the Channel 9 demo video Getting started with Azure Multi-Factor Authentication.
The Privileged Identity Management (Azure AD PIM) feature improves your organization's cloud security posture by reducing risk from users who have access to highly-privileged roles, such as administrator roles in Azure AD and other services such as Office 365, Intune, and SaaS applications whose access is managed by Azure AD.
This service (currently in public preview as of this writing) is available in the new Azure portal at https://portal.azure.com/. The portal allows you to add the Privileged Identity Management tile to your Startboard.
Important note This service is only available when you enable the premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
Today, most IT professionals enjoy permanent and unmonitored permissions to high-value resources. While this could be convenient, it poses major security concerns and makes their accounts high-value targets for security attacks. In many of the recent high-profile security breaches that made the headlines in the newspapers, an attacker simply found a way to compromise a user account that was permanently assigned to privileged roles.
The attacker was then able to use that account to access resources across the organization's network, in many cases going undetected for months. These network attacks are referred as to Advanced Persistent Threats (APT): "a set of stealthy and continuous computer hacking processes, often orchestrated by human(s) targeting a specific entity. APT usually targets organizations and/or nations for business or political motives. APT processes require a high degree of covertness over a long period of time."
The Azure AD PIM service reduces this risk around access to these privileged roles by enabling you to:
For the public preview, the Azure AD PIM service currently manages only the built-in Azure AD privileged roles, and their access to directory resources: Global administrator, Billing administrator, Service administrator, User administrator, Password administrator.
In upcoming releases, a bunch of new capabilities is going to be added, such as:
To start using the Azure AD PIM, proceed with the following steps:
Note As the first global administrator who initiates access to this preview, you're automatically assigned to the security administrator role, which is a new role used to manage privileged identities. You can add other users to the security administrator role.
Note The basic model is that that a privileged role is assigned to candidate members, who in turn activate their membership in the role on-demand and for a limited pre-configured time. Since the security administrator role is a privileged role, and in order to begin managing privileged identities.
A list of roles assigned to you: the global administrator role with "permanent activation" and the new security administrator for which you need to "request activation". The security administrator manages the other privileged identities.
For each privileged role, you can see how many users are assigned to that role, how many of these assignments are currently active and how many are permanently active. The blade also shows a summary of the security alerts. For instance, if there are too many permanent assignments, it shows an alert as illustrated above for the global administrators.
Azure AD PIM provides a self-service experience for administrators.
The privileged identities managed by the service are regular users until they're activated into their assigned privileged role. Users must activate the privileged role to which they've been assigned. After activation, they can complete privileged operations until their access to the privileged role expires.
In today's preview, when a user submits an activation request, the request is logged in the system. The request is immediately auto-approved, and the role is activated for the time period that is pre-configured for the role (this time period for the role can be configured by the security administrator).
Capabilities will be added so that you can secure the activation for a role even further by using security gates such as Azure Multi-Factor Authentication (MFA), human approval, or validation of an incident ticket assigned to the requesting user.
Note For more information, see the blog post Azure Cloud App Discovery GA and our new Privileged Identity Management service. You can also watch the Channel 9 demo video Azure AD Privileged Identity Management.
In terms of end-users' experience that Azure AD provides single sign-on to thousands of application hosted in any cloud and on-premises, self-service capabilities that can boost productivity from a customizable user friendly environment accessible from every device. This is notably accomplished through the Azure AD Access Panel.
Note As an introduction, you can watch the Channel 9 demo video First day at work with Azure Active Directory.
The Azure AD Access Panel allows an end user with an organizational account in Azure AD to view and launch applications that have been assigned to them by their administrator of their tenant (plus any applications that they have consented to).
In other words, this is a single screen with assigned SaaS applications for every user, and where they can discover which applications they have, single sign-on to those applications, and in some cases manage their application credentials.
The Azure AD Access Panel is a web-based portal available at http://myapps.microsoft.com.
Note The Access Panel is separate from the Azure Management Portal and does not require users to have an Azure subscription.
To use the Azure AD Access Panel with your organizational account, proceed with the following steps:
The Azure AD Access Panel allows users to edit some of their profile settings, including the ability to:
And with Basic and Premium editions of Azure AD:
Self-service password reset for users allows end users in your organization to reset their passwords automatically without calling an administrator or helpdesk for support.
Important note This feature is only available when you enable the Basic or the Premium editions of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
This feature is comprised of the following components:
To activate the password reset policy for cloud users, proceed with the following steps:
Enabling security questions provides the ability for IT professionals to require users to provide answers to a specified amount of questions to register for the password reset feature. Once registered the user will need to answer the questions for verification in order to reset their password:
To add user contact via the user registration portal, proceed with the following steps:
After verifying a phone number, the user's profile will be updated with the number provided.
To perform a self-service password reset, proceed with the following steps:
Note For more information, see the Microsoft TechNet article Enable self-service password reset for users. You can also watch the Channel 9 demo video Azure Active Directory Premium Self-Service Password Reset w/write-back.
Self-service group management, a.k.a. delegated group management, enables users to create and manage security groups in Azure AD and offers users the possibility to request security group memberships, which can subsequently be approved or denied by the owner of the group. By using self-service group management features, the day-to-day control of group membership can be delegated to people who understand the business context for that membership.
Important note This feature is only available when you enable the Basic or the Premium editions of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
This capability can notably serve to delegate the access management of an application to a business owner. For that purpose, an IT professional can assign access for the application to a new group that the business owner has created. The business owner can then manage the group membership.
Note For more information, see the Microsoft TechNet article Self-service group management for users. You can also watch the Channel 9 demo video Delegated Group Management on Azure Active Directory Premium.
To activate the self-service group management for users, proceed with the following steps:
Once Self-service group management has been enabled for the directory, it is made available to users through the Azure AD Access Panel via the groups and approvals tabs.
To manage your groups in the Azure AD Access Panel, proceed with the following steps:
Note For more information, see the Microsoft TechNet article Manage your groups.
All the applications assigned to a user or (dynamic) groups they belong to appear as a tile on the Azure AD Access Panel.
When a user clicks on an application tile that has been configured for federation-based single sign-on for one of these applications, they are redirected to that application and automatically signed in. The user account information from Azure AD is being used in this context.
The first time a user clicks on an application that has been configured for password-based single sign-on, and if not already done for another similar application, they will be prompted to install an Azure AD Access Panel Extension plugin for Internet Explorer, Chrome or Firefox. This extension is needed to support the password-based single sign-on functionality.
They will have to follow the browser specific instructions. The setup of the Azure AD Access Panel Extension (Access Panel Extension.msi) plugin may require restarting of their web browser.
When they are returned to the Azure AD Access Panel and click on the application tile again, they will be prompted for a username and password for the application.
Note If you have assigned credentials for this user, they will not need to perform this step and instead will be redirected and signed to the application.
Once the username and password are entered, these credentials will be securely stored in Azure AD and linked to their account in Azure AD, and the Access Panel will automate signing the user in to the application using those credentials.
The next time a user clicks on the application tile, they will be automatically signed into the application without needing to enter the credentials again and without needing to install the Password single sign-on plugin again.
If a user's credentials have changed in the target third-party application, then the user must also update their credentials which are stored in Azure AD. To update credentials, a user must select the icon in the lower-right of the application tile, and select update credentials to re-enter the username and password for that application.
Many applications that support federation-based single sign-on with Azure AD already support the ability for users to sign in directly at the application without first loading the Azure AD Access Panel. (In the federation terminology, this is known as service provider initiated federation).
However, applications that are configured to use an alternate sign-in method, such as password-based single sign-on, required to be launched from the Azure AD Access Panel.
Direct single sign-on links to individual applications are available. Technically speaking, such links are specifically-crafted URLs that send a user through the Azure AD sign in process for a specific application without requiring the user to load the Azure AD Access Panel.
These specific direct single sign-on URLs are specified in SINGLE SIGN-ON URL under the DASHBOARD tab of any pre-integrated application in the ACTIVE DIRECTORY section of the classic Azure management portal as illustrated hereafter.
These links can be copied and pasted anywhere you want to provide a sign-in link to the considered application. Here's an example of such an URL for Twitter:
https://myapps.microsoft.com/signin/Twitter/230848d52c8745d4b05a60d29a40fced
These links use the same access control mechanisms as the Azure AD Access Panel, and only those users or groups who have been assigned to the application in the Azure management portal will be able to successfully authenticate. However, any user who is unauthorized will see a message explaining that they have not been granted access, and are given a link to load the Access Panel to view available applications for which they do have access.
Note For more information, see the blog post Customize Your App SSO Experience with Azure AD.
With an ever growing list of applications added to your Azure AD tenant, you may become over whelmed with requests from their employees to get access to a specific application.
Self-Service for Application Access allows users to request access to an application using a Get more applications tile in the Azure AD access panel. This capability is supported for all application that support federated or password-based single sign-on.
Enabling the feature allows you to:
Note For more information and instructions on how to enable the feature, see the blog post Employee Self-Service App Access for Azure AD now in preview!.
To enable users to request access to an application, proceed with the following steps:
Administrators can customize how the Azure AD Access Panel and the sign-in page will appear to users within an organization. More specifically, administrators can brand these pages to include their company's logo and customize other on-screen elements.
Important note This feature is only available when you enable the Basic or the Premium edition of Azure AD. For more information, see the Microsoft TechNet article Azure Active Directory Editions.
To customize the Azure AD Access Panel, proceed with the following steps:
Important note You have to assign a Basic or a Premium license to the administrator of the directory to see the above Customize Branding button.
Note For more information, see the Microsoft TechNet article Add company branding to your Sign In and Access Panel pages.
Similar to the above organization-specific URL for the Azure AD Access Panel, you can also customize the direct single sign-on links (see section § Accessing applications from direct single sign-on links) by adding one of the active or verified domain names configured for your directory after the myapps.microsoft.com domain. This ensures any organizational branding is loaded immediately on the sign-in page without the user needing to enter their user ID first:
https://myapps.microsoft.com/corpfabrikam.onmicrosoft.com/signin/Twitter/230848d52c8745d4b05a60d29a40f
When an authorized user clicks one of these application-specific links, they first see their organizational sign-in page (as shown above assuming they are not already signed in), and after sign-in, they are redirected to their application without stopping at the Azure AD Access Panel first. If the user is missing pre-requisites to access the application, such as the password-based single sign-on browser plugin, then the link will prompt the user to install the missing extension.
Since the major mobile platforms don't support the browser plugins as notably used by the Azure AD Access Panel (e.g. the password-based single sign-on browser plugins), a "My Apps" mobile application is also available to help users access their apps on their mobile devices.
The "My Apps" application is optimized for your mobile device and supports all of the features of the Azure AD Access Panel.
"My Apps" is available as of today for both the iOS and Android platforms:
To use "My Apps" with your organizational account, proceed with the following steps:
You can also change your organizational password, or edit your multi-factor authentication settings (if configured) from inside the "My Apps" app.
Note For more information, see the blog post Accessing Azure AD connected apps on Android phones, iPhones, and iPads.