What Is Azure Active Directory - PDF

Table of Contents
Overview
What is Azure Active Directory?
About Azure identity management
Understand Azure identity solutions
Choose a hybrid identity solution
Associate Azure subscriptions
FAQs
What's New
Get started
Get started with Azure AD
Sign up for Azure AD Premium
Add a custom domain name
Configure company branding
Add users to Azure AD
Assign licenses to users
Configure Self-service password reset
How to
Plan and design
Understand Azure AD architecture
Claims mapping in Azure Active Directory
Deploy a hybrid identity solution
Manage users
Add new users to Azure AD
Manage user profiles
Share accounts
Assign users to admin roles
Restore a deleted user
Add guest users from another directory (B2B)
Manage groups and members
Manage groups
Manage group members
Manage group owners
Manage group membership
Assign licenses using groups
Set up Office 365 groups expiration
View all groups
Add group access to SaaS apps
Restore a deleted Office 365 group
Manage group settings
Create advanced rules
Set up self-service groups
Troubleshoot
Manage reports
Sign-ins activity
Audit activity
Users at risk
Risky sign-ins
Risk events
FAQ
Tasks
Reference
Troubleshoot
Programmatic Access
Manage passwords
Passwords overview
User documents
SSPR How it works
SSPR Deployment guide
SSPR and Windows 10
SSPR Policies
SSPR Customization
SSPR Data requirements
SSPR Reporting
IT Admins: Reset passwords
License SSPR
Password writeback
Troubleshoot
FAQ
Manage devices
Introduction
Using the Azure portal
Plan Azure AD Join
FAQs
Tasks
Troubleshoot
Manage apps
Overview
Getting started
SaaS app integration tutorials
Cloud App Discovery
Access apps remotely with App Proxy
Manage enterprise apps
Configure Sign-In Auto-Acceleration using HRD Policy
Manage access to apps
Troubleshoot
Develop apps
Document library
Manage your directory
Azure AD Connect
Custom domain names
Administer your directory
Multiple directories
Self-service signup
Take over an unmanaged directory
Enterprise State Roaming
Integrate on-premises identities using Azure AD Connect
Manage access to Azure
Manage access overview
Resource access in Azure
Role-Based Access Control (RBAC)
Privileged Identity Management (PIM) for RBAC
Conditional access for Azure management
Managed Service Identity
Delegate access to resources
Administrator roles
Administrative units
Configure token lifetimes
Manage emergency access administrative accounts
Access reviews
Access reviews overview
Complete an access review
Create an access review
How to perform an access review
How to review your access
Guest access with access reviews
Managing user access with reviews
Managing programs and controls
Secure your identities
Conditional access
Windows Hello
Certificate-based Authentication
Azure AD Identity Protection
Privileged Identity Management
Integrate other services with Azure AD
Enable LinkedIn integration
Deploy AD DS on Azure VMs
Windows Server Active Directory on Azure VMs
Replica domain controller in an Azure virtual network
New forest on an Azure virtual network
Deploy AD FS in Azure
High availability
Change signature hash algorithm
Troubleshoot
Troubleshoot Active Directory item is missing or not available
Deploy Azure AD Proof of Concept (PoC)
PoC Playbook: Introduction
PoC Playbook: Ingredients
PoC Playbook: Implementation
PoC Playbook: Building Blocks
Reference
Code samples
Azure PowerShell cmdlets
Java API Reference
.NET API
Service limits and restrictions
Related
Multi-Factor Authentication
Azure AD Connect
Azure AD Connect Health
Azure AD for developers
Azure AD Privileged Identity Management
Resources
Azure feedback forum
Azure Roadmap
MSDN forum
Pricing
Pricing calculator
Service updates
Stack Overflow
Videos
12/11/2017 • 5 min to read • Edit Online
Azure Active Directory (Azure AD) is Microsoft’s multi-tenant, cloud based directory and identity management
service. Azure AD combines core directory services, advanced identity governance, and application access
management. Azure AD also offers a rich, standards-based platform that enables developers to deliver access
control to their applications, based on centralized policy and rules.
For IT Admins, Azure AD provides an affordable, easy to use solution to give employees and business partners
single sign-on (SSO) access to thousands of cloud SaaS Applications like Office365, Salesforce.com, DropBox, and
Concur.
For application developers, Azure AD lets you focus on building your application by making it fast and simple to
integrate with a world class identity management solution used by millions of organizations around the world.
Azure AD also includes a full suite of identity management capabilities including multi-factor authentication,
device registration, self-service password management, self-service group management, privileged account
management, role based access control, application usage monitoring, rich auditing and security monitoring and
alerting. These capabilities can help secure cloud based applications, streamline IT processes, cut costs and help
ensure that corporate compliance goals are met.
Additionally, with just four clicks, Azure AD can be integrated with an existing Windows Server Active Directory,
giving organizations the ability to leverage their existing on-premises identity investments to manage access to
cloud based SaaS applications.
If you are an Office 365, Azure or Dynamics CRM Online customer, you might not realize that you are already
using Azure AD. Every Office 365, Azure and Dynamics CRM tenant is actually already an Azure AD tenant.
Whenever you want you can start using that tenant to manage access to thousands of other cloud applications
Azure AD integrates with!
How reliable is Azure AD?

The multi-tenant, geo-distributed, high availability design of Azure AD means that you can rely on it for your most
critical business needs. Running out of 28 data centers around the world with automated failover, you’ll have the
comfort of knowing that Azure AD is highly reliable and that even if a data center goes down, copies of your
directory data are live in at least two more regionally dispersed data centers and available for instant access.
For more details, see Service Level Agreements.
Choose an edition
All Microsoft Online business services rely on Azure Active Directory (Azure AD) for sign-in and other identity
needs. If you subscribe to any of Microsoft Online business services (for example, Office 365 or Microsoft Azure),
you get Azure AD with access to all of the Free features. With the Azure Active Directory Free edition, you can
manage users and groups, synchronize with on-premises directories, get single sign-on across Azure, Office 365,
and thousands of popular SaaS applications like Salesforce, Workday, Concur, DocuSign, Google Apps, Box,
ServiceNow, Dropbox, and more.
To enhance your Azure Active Directory, you can add paid capabilities using the Azure Active Directory Basic,
Premium P1, and Premium P2 editions. Azure Active Directory paid editions are built on top of your existing free
directory, providing enterprise class capabilities spanning self-service, enhanced monitoring, security reporting,
Multi-Factor Authentication (MFA), and secure access for your mobile workforce.
NOTE
For the pricing options of these editions, see Azure Active Directory Pricing. Azure Active Directory Premium P1, Premium
P2, and Azure Active Directory Basic are not currently supported in China. Please contact us at the Azure Active Directory
Forum for more information.
Azure Active Directory Basic - Designed for task workers with cloud-first needs, this edition provides cloud
centric application access and self-service identity management solutions. With the Basic edition of Azure
Active Directory, you get productivity enhancing and cost reducing features like group-based access
management, self-service password reset for cloud applications, and Azure Active Directory Application Proxy
(to publish on-premises web applications using Azure Active Directory), all backed by an enterprise-level SLA
of 99.9 percent uptime.
Azure Active Directory Premium P1 - Designed to empower organizations with more demanding identity
and access management needs, Azure Active Directory Premium edition adds feature-rich enterprise-level
identity management capabilities and enables hybrid users to seamlessly access on-premises and cloud
capabilities. This edition includes everything you need for information worker and identity administrators in
hybrid environments across application access, self-service identity and access management (IAM), identity
protection and security in the cloud. It supports advanced administration and delegation resources like
dynamic groups and self-service group management. It includes Microsoft Identity Manager (an on-premises
identity and access management suite) and provides cloud write-back capabilities enabling solutions like self-
service password reset for your on-premises users.
Azure Active Directory Premium P2 - Designed with advanced protection for all your users and
administrators, this new offering includes all the capabilities in Azure AD Premium P1 as well as our new
Identity Protection and Privileged Identity Management. Azure Active Directory Identity Protection leverages
billions of signals to provide risk-based conditional access to your applications and critical company data. We
also help you manage and protect privileged accounts with Azure Active Directory Privileged Identity
Management so you can discover, restrict and monitor administrators and their access to resources and
provide just-in-time access when needed.
NOTE
A number of Azure Active Directory capabilities are available through "pay as you go" editions:
Active Directory B2C is the identity and access management solution for your consumer-facing applications. For more
details, see Azure Active Directory B2C
Azure Multi-Factor Authentication can be used through per user or per authentication providers. For more details, see
What is Azure Multi-Factor Authentication?
How can I get started?
If you are an IT admin:
Try it out! - you can sign up for a free 30 day trial today and deploy your first cloud solution in under 5
minutes using this link
Read Getting started with Azure AD for tips and tricks on getting an Azure AD tenant up and running fast
If you are a developer:
Check out our Developers Guide to Azure Active Directory
Start a trial – sign up for a free 30 day trial today and start integrating your apps with Azure AD
Next steps
Learn more about the fundamentals of Azure identity and access management
Fundamentals of Azure identity management
As more and more company digital resources live outside the corporate network, in the cloud and on devices, a
great cloud-based identity and access management solution is becoming a necessity. Cloud-based identities are
now the best way to maintain control over, and visibility into, how and when users access corporate applications
and data.
Microsoft has been securing cloud-based identities for over a decade and now, with Azure Active Directory (AD),
these same protection systems are available to you. With Azure AD, enterprise administrators can easily ensure
user and administrator accountability with better security and governance than ever before.
Azure AD Premium is a cloud-based identity and access management solution with advanced protection
capabilities that enables one secure identity for all apps, identity protection (enhanced by the Microsoft intelligence
security graph), and Privileged Identity Management. Not just another monitoring or reporting tool, Azure AD
Premium can protect your user’s identities in real time and enable you to create risk-based, adaptive access policies
to protect your organization’s data.
Watch this short video for a quick overview of Azure AD identity management and protection:
Microsoft not only provides an identity that takes you everywhere, but also a set of tools to automate, help secure,
and manage IT within your organization. Even after the advent of cloud computing, there is still demand to manage
and control IT tasks like helpdesk calls to reset user passwords, user group management, and application requests.
Complicating things further, employees are now bringing their personal devices to work and using readily available
SaaS applications. This makes maintaining control over their applications across corporate datacenters and public
cloud platforms a significant challenge.
NOTE
To learn if specific features are supported by your license type, check the Azure Active Directory Pricing information page.
Connect on-premises Active Directory with Azure AD and Office 365

Organizations that have made large investments in on-premises Active Directory can extend those investments to
the cloud by integrating their on-premises directories with Azure AD into hybrid identity management. Doing so
makes your users more productive by providing a common identity for accessing resources regardless of location.
Users and organizations can then use single sign on (SSO) to access both on-premises resources and cloud services
such as Office 365.
Azure AD Connect is the only tool you need to get the integration done. Azure AD Connect provides capabilities to
support your identity synchronization needs and replaces older versions of identity integration tools such as
DirSync and Azure AD Sync. With Azure AD Connect, identity management and synchronization between on-
premises and Azure AD is enabled through:
Synchronization - This component is responsible for creating users, groups, and other objects. It is also
responsible for making sure identity information for your on-premises users and groups is matching the cloud.
Password write-back can also be enabled to keep on-premises directories in sync when a user updates their
password in Azure AD.
AD FS - Federation is an optional capability provided by Azure AD Connect that can be used to configure a
hybrid environment using an on-premises AD FS infrastructure. Federation can be used by organizations to
address complex deployments, such as single sign on, enforcement of AD sign-in policy, and smart card or third
party MFA.
Health Monitoring - Azure AD Connect Health can provide robust monitoring and provide a central location in
the Azure portal to view this activity.
Increase productivity and reduce helpdesk costs with self-service and

single sign-on experiences
Employees are more productive when they have a single username and password to remember and a consistent
experience from every device. They also save time when they can perform self-service tasks like resetting a
forgotten password or requesting access to an application without waiting for assistance from the helpdesk.
Azure AD extends on-premises Active Directory into the cloud, enabling users to use their primary organizational
account for both their domain-joined devices, company resources, and all of the web and SaaS applications they
need to use to get their jobs done. In addition to not having to remember multiple sets of usernames and
passwords, users' application access can also be automatically provisioned (or de-provisioned) based on their
organization group memberships and their status as an employee. And you can control that access for gallery apps
or for your own on-premises apps that you’ve developed and published through the Azure AD Application Proxy.
Manage and control access to corporate resources

Microsoft identity and access management solutions help IT protect access to applications and resources across the
corporate datacenter and into the cloud, enabling additional levels of validation such as multi-factor authentication
and conditional access policies. Monitoring suspicious activity through advanced security reporting, auditing and
alerting helps mitigate potential security issues.
Conditional access policies in Azure AD Premium give you, the enterprise admin, the ability to create policy-based
access rules for any Azure AD-connected application (SaaS apps, custom apps running in the cloud or on-premises
web applications). Azure AD evaluates these policies in real time, and enforces them whenever a user attempts to
access an application. Azure identity protection policies enable you to automatically take action if suspicious activity
is discovered. These actions can include blocking access to users at high risk, enforcing multi-factor authentication,
and resetting user passwords if it looks like credentials have been compromised.
Azure Active Directory Privileged Identity Management

Privileged Identity Management, included with the Azure Active Directory Premium P2 offering, allows you to
discover, restrict, and monitor administrative accounts and their access to resources in your Azure Active Directory
and other Microsoft online services. It also helps you administer on-demand administrative access for the exact
period of time you need.
Privileged Identity Management can enforce on-demand administrator rights so that administrators can request
multi-factor authenticated, temporary elevation of their privileges for pre-configured periods of time before their
accounts return to a normal user state.
Benefits of Azure Identity

With Azure identity management, you can:
Create and manage a single identity for each user across your entire enterprise, keeping users, groups, and
devices in sync with Azure Active Directory Connect.
Provide single sign-on access to your applications including thousands of pre-integrated SaaS apps or
provide secure remote access to on-premises SaaS applications using the Azure AD Application Proxy.
Enable application access security by enforcing rules-based Multi-Factor Authentication for both on-
premises and cloud applications.
Improve user productivity with self-service password reset, and group and application access requests using
the MyApps portal.
Take advantage of the high-availability and reliability of a worldwide, enterprise-grade, cloud-based identity
and access management solution.
Next steps
Learn more about Azure identity solutions
Understand Azure identity solutions
Microsoft Azure Active Directory (Azure AD) is an identity and access management cloud solution that provides
directory services, identity governance, and application access management. Azure AD quickly enables single sign
on (SSO) to 1,000’s of pre-integrated commercial and custom apps in the Azure AD application gallery. Many of
these apps you probably already use such as Office 365, Salesforce.com, Box, ServiceNow, and Workday.
A single Azure AD directory is automatically associated with an Azure subscription when it is created. As the identity
service in Azure, Azure AD then provides all identity management and access control functions for cloud-based
resources. These resources can include users, apps, and groups for an individual tenant (organization) as shown in
the following diagram:
Microsoft Azure offers several ways to leverage identity as a service (IDaaS) with varying levels of complexity to
meet your individual organization’s needs. The rest of this article helps you understand basic Azure identity
terminology and concepts as well as recommendations for you to make the best choice from the available options.
Terms to know
Before you can decide on an Azure identity solution for your organization, you need a basic understanding of the
terms commonly used when talking about Azure identity services.
TERM TO KNOW DESCRIPTION
Azure subscription Subscriptions are used to pay for Azure cloud services and are
usually linked to a credit card. You can have several
subscriptions, but it can be difficult to share resources
between subscriptions.
Azure tenant An Azure AD tenant is representative of a single organization.

It is a dedicated, trusted instance of Azure AD that is
automatically created when an organization signs up for a
Microsoft cloud service subscription such as Azure, Intune, or
Office 365. Tenants can gain access to services in either a
dedicated environment (single tenant) or in a shared
environment with other organizations (multitenant).
TERM TO KNOW DESCRIPTION
Azure AD directory Each Azure tenant has a dedicated, trusted Azure AD directory
that contains the tenant’s users, groups, and applications. It is
used to perform identity and access management functions
for tenant resources. Because a unique Azure AD directory is
automatically provisioned to represent your organization
when you sign up for a Microsoft cloud service like Azure,
Microsoft Intune, or Office 365, you’ll sometimes see the
terms tenant, Azure AD, and Azure AD directory used
interchangeably.
Custom domain When you first sign up for a Microsoft cloud service
subscription, your tenant (organization) uses an
.onmicrosoft.com domain name. However, most organizations
have one or more domain names that are used to do business
and that end users use to access company resources. You can
add your custom domain name to Azure AD so that the
domain name is familiar to your users, such as
alice@contoso.com instead of
alice@contoso.onmicrosoft.com.
Azure AD account These are identities that are created by using Azure AD or
another Microsoft cloud service such as Office 365. They are
stored in Azure AD and accessible to any of the organization’s
cloud service subscriptions.
Azure subscription administrator The account administrator is the person who signed up for or
bought the Azure subscription. They can use the Account
Center to perform various management tasks like create
subscriptions, cancel subscriptions, change the billing for a
subscription, or change the Service Administrator.
Azure AD Global administrator Azure AD Global administrators have full access to all Azure
AD administrative features. The person who signs up for a
Microsoft cloud service subscription automatically becomes a
global administrator by default. You can have more than one
global administrator, but only global administrators can assign
any of the other administrator roles to users.
Microsoft account Microsoft accounts (created by you for personal use) provide
access to consumer-oriented Microsoft products and cloud
services, like Outlook (Hotmail), OneDrive, Xbox LIVE, or Office
365. These identities are created and stored in the Microsoft
consumer identity account system run by Microsoft.
Work or school accounts Work or school accounts (issued by an admin for

business/academic use) provide access to enterprise business-
level Microsoft cloud services, such as Azure, Intune, or Office
365.
Concepts to understand
Now that you know the basic Azure identity terms, you should learn more about these Azure identity concepts that
help you make an informed Azure identity service decision.
CONCEPT TO UNDERSTAND DESCRIPTION
How Azure subscriptions are associated with Azure Active Every Azure subscription has a trust relationship with an Azure
Directory AD directory to authenticate users, services, and devices.
Multiple subscriptions can trust the same Azure AD directory,
but a subscription will only trust a single Azure AD directory.
This trust relationship is unlike the relationship that a
subscription has with other Azure resources (websites,
databases, and so on), which are more like child resources of a
subscription. If a subscription expires, then access to resources
associated with the subscription other than Azure AD also
stops. However, the Azure AD directory remains in Azure, so
that you can associate another subscription with that directory
and continue to manage tenant resources.
How Azure AD licensing works When you purchase or activate Enterprise Mobility Suite,
Azure AD Premium, or Azure AD Basic, your directory is
updated with the subscription, including its validity period and
prepaid licenses. Once the subscription is active, the service
can be managed by Azure AD global administrators and used
by licensed users. Your subscription information, including the
number of assigned or available licenses, is available in the
Azure portal from the Azure Active Directory > Licenses
blade. This is also the best place to manage your license
assignments.
Role-Based Access Control in the Azure portal Azure Role-Based Access Control (RBAC) helps provide fine-
grained access management for Azure resources. Too many
permissions can expose and account to attackers. Too few
permissions means that employees can’t get their work done
efficiently. Using RBAC, you can give employees the exact
permissions they need based on three basic roles that apply to
all resource groups: owner, contributor, reader. You can also
create up to 2,000 of your own custom RBAC roles to meet
your specific needs.
Hybrid identity Hybrid identity is achieved by integrating your on-premises

Windows Server Active Directory (AD DS) with Azure AD using
Azure AD Connect. This allows you to provide a common
identity for your users for Office 365, Azure, and on-premises
apps or SaaS applications integrated with Azure AD. With
hybrid identity, you effectively extend your on-premises
environment to the cloud for identity and access.
The difference between Windows Server AD DS and Azure AD

Both Azure Active Directory (Azure AD) and on-premises Active Directory (Active Directory Domain Services or AD
DS) are systems that store directory data and manage communication between users and resources, including user
logon processes, authentication, and directory searches.
If you are already familiar with on-premises Windows Server Active Directory Domain Services (AD DS), first
introduced with Windows 2000 Server, then you probably understand the basic concept of an identity service.
However, it’s also important to understand that Azure AD is not just a domain controller in the cloud. It is an
entirely new way of providing identity as a service (IDaaS) in Azure that requires an entirely new way of thinking to
fully embrace cloud-based capabilities and protect your organization from modern threats.
AD DS is a server role on Windows Server, which means that it can be deployed on physical or virtual machines. It
has a hierarchical structure based on X.500. It uses DNS for locating objects, can be interacted with using LDAP, and
it primarily uses Kerberos for authentication. Active Directory enables organizational units (OUs) and Group Policy
Objects (GPOs) in addition to joining machines to the domain, and trusts are created between domains.
IT has protected their security perimeter for years using AD DS, but modern, perimeter-less enterprises supporting
identity needs for employees, customers, and partners require a new control plane. Azure AD is that identity control
plane. Security has moved beyond the corporate firewall to the cloud where Azure AD protects company resources
and access by providing one common identity for users (either on-premises or in the cloud). This gives your users
the flexibility to securely access the apps they need to get their work done from almost any device. Seamless risk-
based data protection controls, backed by machine-learning capabilities and in-depth reporting, are also provided
that IT needs to keep company data secure.
Azure AD is a multi-customer public directory service, which means that within Azure AD you can create a tenant
for your cloud servers and applications such as Office 365. Users and groups are created in a flat structure without
OUs or GPOs. Authentication is performed through protocols such as SAML, WS-Federation, and OAuth. It's
possible to query Azure AD, but instead of using LDAP you must use a REST API called AD Graph API. These all
work over HTTP and HTTPS.
Extend Office 365 management and security capabilities
Already using Office 365? You can accelerate your digital transformation by extending built-in Office 365
capabilities with Azure AD to secure all your resources, enabling secure productivity for your entire workforce.
When you use Azure AD, in addition to Office 365 capabilities, you can secure your entire application portfolio with
one identity that enables single sign-on for all apps. You can expand your conditional access capabilities based not
just on device state, but user, location, application, and risk as well. Multi-factor authentication (MFA) capabilities
provide even more protection when you need it. You’ll gain additional oversight of user privileges and provide on-
demand, just-in-time administrative access. Your users will be more productive, and create fewer helpdesk tickets,
thanks to the self-service capabilities Azure AD provides like resetting forgotten passwords, application access
requests, and creating and managing groups.
TIP
Want to learn more about using Azure AD identity management with Office 365? Get the e-book.
Microsoft Azure identity solutions

Microsoft Azure offers several ways to manage your users’ identities whether they are maintained fully on-
premises, only in the cloud, or even somewhere in between. These options include: do-it-yourself (DIY) AD DS in
Azure, Azure Active Directory (Azure AD), Hybrid Identity, and Azure AD Domain Services.
Do -it-yourself (DIY ) AD DS
For companies that need only a small footprint in the cloud, do-it-yourself (DIY) AD DS in Azure can be used. This
option supports many Windows Server AD DS scenarios that are well-suited for deployment as virtual machines
(VMs) on Azure. For example, you can create an Azure VM as a domain controller running in a faraway datacenter
that is connected to the remote network. From there, the VM would be able to support authentication requests
from remote users and improve authentication performance. This option is also well-suited as a relatively low-cost
substitute to otherwise costly disaster recovery sites by hosting a small number of domain controllers and a single
virtual network on Azure. Finally, you might need to deploy an application on Azure, such as SharePoint, that
requires Windows Server AD DS, but has no dependency on the on-premises network or the corporate Windows
Server Active Directory. In this case, you could deploy an isolated forest on Azure to meet the SharePoint server
farm’s requirements. It’s also supported to deploy network applications that do require connectivity to the on-
premises network and the on-premises Active Directory.
Azure Active Directory (Azure AD)
Azure AD standalone is a fully cloud-based Identity and access management as a Service (IDaaS) solution. Azure
AD gives you a robust set of capabilities to manage users and groups. It helps secure access to on-premises and
cloud applications, including Microsoft web services like Office 365, and many non-Microsoft software as a service
(SaaS) applications. Azure AD comes in three editions: Free, Basic, and Premium. Azure AD boosts organizational
effectiveness and extends security beyond the perimeter firewall to a new control plane protected by Azure
machine learning and other advanced security features.
Hybrid identity
Rather than choose between on-premises or cloud-based identity solutions, many forward-thinking CIOs and
businesses, that have begun anticipating their company’s long-term direction, are extending their on-premises
directories to the cloud through hybrid identity solutions. With hybrid identity, you get a truly global identity and
access management solution that provides secure and productive access to the applications users need to do their
jobs.
TIP
To learn more about how CIOs have made Azure Active Directory a central part of their IT strategies, download the CIO’s
Guide to Azure Active Directory.
Azure AD Domain Services

Azure AD Domain Services provides a cloud-based option to use AD DS for lightweight Azure VM configuration
control and a way to meet on-premises identity requirements for network application development and testing.
Azure AD Domain Services is not meant to lift and shift your on-premises AD DS infrastructure to Azure VMs
managed by Azure AD Domain Services. Instead, the Azure VMs in managed domains should be used to support
the development, testing, and movement of on-premises applications that require AD DS authentication methods
to the cloud.
Common scenarios and recommendations

Here are some common identity and access scenarios with recommendations as to which Azure identity option
might be most appropriate for each.
IDENTITY SCENARIO RECOMMENDATION
My organization has made large investments in on-premises The most widely used Azure identity solution is hybrid identity.
Windows Server Active Directory, but we want to extend If you’ve already made investments in on-premises AD DS,
identity to the cloud. you can easily extend identity to the cloud using Azure AD
Connect.
My business was born in the cloud and we have no Azure Active Directory is the best choice for cloud-only
investments in on-premises identity solutions. businesses with no on-premises investments.
I need lightweight Azure VM configuration and control to Azure AD Domain Services is a good choice if you need to use
meet on-premises identity requirements for app development AD DS for lightweight Azure VM configuration control or are
and testing. looking to develop or migrate legacy, directory-aware on-
premises applications to the cloud.
I need to support a few virtual machines in Azure, but my Use DIY AD DS to use Azure VMs when you need to support
company is still heavily invested in on-premises Active a few virtual machines and have large AD DS investments on-
Directory (AD DS). premises.
Where can I learn more?

We have a ton of great resources online to help you learn all about Azure AD. Here’s a list of great articles to get
you started:
Enabling your directory for hybrid management with Azure AD Connect
Additional security for an ever connected world
Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory
Getting started with Azure AD Reporting
Manage your passwords from anywhere
What is application access and single sign-on with Azure Active Directory?
Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory
How to provide secure remote access to on-premises applications
Managing access to resources with Azure Active Directory groups
What is Microsoft Azure Active Directory licensing?
How can I discover unsanctioned cloud apps that are used within my organization
Next steps
Now that you understand Azure identity concepts and the options available to you, you can use the following
resources to get started implementing the option you’ve chosen:
Learn more about Azure hybrid identity solutions
Learn more in an Azure Proof of Concept environment
Deploy Azure AD in production
Microsoft hybrid identity solutions
Microsoft Azure Active Directory (Azure AD) hybrid identity solutions enable you to synchronize on-premises
directory objects with Azure AD while still managing your users on-premises. The first decision to make when
planning to synchronize your on-premises Windows Server Active Directory with Azure AD is whether you want to
use synchronized identity or federated identity. Synchronized identities, and optionally password hashes, enable
your users to use the same password to access both on-premises and cloud-based organizational resources. For
more advanced scenario requirements, such as single-sign-on (SSO) or on-premises MFA, you need to deploy
Active Directory Federation Services (AD FS) to federate identities.
There are several options available for configuring hybrid identity. This article provides information to help you
choose the best one for your organization based on ease of deployment and your specific identity and access
management needs. As you consider which identity model best fits your organization’s needs, you also need to
think about time, existing infrastructure, complexity, and cost. These factors are different for every organization, and
might change over time. However, if your requirements do change, you also have the flexibility to switch to a
different identity model.
TIP
These solutions are all delivered by Azure AD Connect.
Synchronized identity
Synchronized identity is the simplest way to synchronize on-premises directory objects (users and groups) with
Azure AD.
While synchronized identity is the easiest and quickest method, your users still need to maintain a separate
password for cloud-based resources. To avoid this, you can also (optionally) synchronize a hash of user passwords
to your Azure AD directory. Synchronizing password hashes enables users to log in to cloud-based organizational
resources with the same user name and password that they use on-premises. Azure AD Connect periodically checks
your on-premises directory for changes and keeps your Azure AD directory synchronized. When a user attribute or
password is changed on-premises Active Directory, it is automatically updated in Azure AD.
For most organizations who only need to enable their users to sign in to Office 365, SaaS applications, and other
Azure AD-based resources, the default password synchronization option is recommended. If that doesn’t work for
you, you'll need to decide between pass-through authentication and AD FS.
TIP
User passwords are stored in on-premises Windows Server Active Directory in the form of a hash value that represents the
actual user password. A hash value is a result of a one-way mathematical function (the hashing algorithm). There is no
method to revert the result of a one-way function to the plain text version of a password. You cannot use a password hash
to sign in to your on-premises network. When you opt to synchronize passwords, Azure AD Connect extracts password
hashes from the on-premises Active Directory and applies extra security processing to the password hash before it is
synchronized to Azure AD. Password synchronization can also be used together with password write-back to enable self-
service password reset in Azure AD. In addition, you can enable single sign-on (SSO) for users on domain-joined computers
that are connected to the corporate network. With single sign-on, enabled users only need to enter a username to securely
access cloud resources.
Pass-through authentication
Azure AD pass-through authentication provides a simple password validation solution for Azure AD-based services
using your on-premises Active Directory. If security and compliance policies for your organization do not permit
sending users' passwords, even in a hashed form, and you only need to support desktop SSO for domain joined
devices, it is recommended that you evaluate using pass-through authentication. Pass-through authentication does
not require any deployment in the DMZ, which simplifies the deployment infrastructure when compared with AD
FS. When users sign in using Azure AD, this authentication method validates users' passwords directly against your
on-premises Active Directory.
With pass-through authentication, there's no need for a complex network infrastructure, and you don't need to
store on-premises passwords in the cloud. Combined with single sign-on, pass-through authentication provides a
truly integrated experience when signing in to Azure AD or other cloud services.
Pass-through authentication is configured with Azure AD Connect, which uses a simple on-premises agent that
listens for password validation requests. The agent can be easily deployed to multiple machines to provide high
availability and load balancing. Since all communications are outbound only, there is no requirement for the
connector to be installed in a DMZ. The server computer requirements for the connector are as follows:
Windows Server 2012 R2 or higher
Joined to a domain in the forest through which users are validated
Pass-through authentication is not currently supported when using Windows 10 devices joined to Azure AD.
However, you can use password hash synchronization as an automatic fallback to support Windows 10 and the
legacy clients mentioned previously. During the preview, password hash synchronization is enabled by default
when pass-through authentication is selected as the sign-in option in Azure AD Connect.
Federated identity (AD FS)

For more control over how users access Office 365 and other cloud services, you can set up directory
synchronization with single sign-on (SSO) using Active Directory Federation Services (AD FS). Federating your
user's sign-ins with AD FS delegates authentication to an on-premises server that validates user credentials. In this
model, on-premises Active Directory credentials are never passed to Azure AD.
Also called identity federation, this sign-in method ensures that all user authentication is controlled on-premises
and allows administrators to implement more rigorous levels of access control. Identity federation with AD FS is the
most complicated option and requires deploying additional servers in your on-premises environment. Identity
federation also commits you to providing 24x7 support for your Active Directory and AD FS infrastructure. This
high level of support is necessary because if your on-premises Internet access, domain controller, or AD FS servers
are unavailable, users can't sign in to cloud services.
TIP
If you decide to use Federation with Active Directory Federation Services (AD FS), you can optionally set up password
synchronization as a backup in case your AD FS infrastructure fails.
Common scenarios and recommendations

Here are some common hybrid identity and access management scenarios with recommendations as to which
hybrid identity option (or options) might be appropriate for each.
I NEED TO: PWS AND SSO 1 PTA AND SSO 2 AD FS 3
Sync new user, contact, and

group accounts created in
my on-premises Active
Directory to the cloud
automatically.
Set up my tenant for Office

365 hybrid scenarios
Enable my users to sign in

and access cloud services
using their on-premises
password
Implement single sign-on

using corporate credentials
Ensure no password hashes

are stored in the cloud
Enable on-premises multi-

factor authentication
solutions
Support smartcard
authentication for my users4
Display password expiry

notifications in the Office
Portal and on the Windows
10 desktop
1 Password synchronization with single sign-on.
2 Pass-through authentication and single sign-on.
3 Federated single sign-on with AD FS.
4 AD FS can be integrated with your enterprise PKI to allow sign-in using certificates. These certificates can be
soft-certificates deployed via trusted provisioning channels such as MDM or GPO or smartcard certificates
(including PIV/CAC cards) or Hello for Business (cert-trust). For more information about smartcard
authentication support, see this blog.
Next steps
Learn more in an Azure Proof of Concept environment
Install Azure AD Connect
Monitor hybrid identity synchronization
How to associate or add an Azure subscription to
Azure Active Directory
This article covers information about the relationship between an Azure subscription and Azure Active Directory
(Azure AD), and how to add an existing subscription to your Azure AD directory. Your Azure subscription has a
trust relationship with Azure AD, which means that it trusts the directory to authenticate users, services, and
devices. Multiple subscriptions can trust the same directory, but each subscription trusts only one directory.
The trust relationship that a subscription has with a directory is unlike the relationship that it has with other
resources in Azure (websites, databases, and so on). If a subscription expires, access to the other resources
associated with the subscription also stops. But an Azure AD directory remains in Azure, and you can associate a
different subscription with that directory and manage the directory using the new subscription.
All users have a single home directory that authenticates them, but they can also be guests in other directories. In
Azure AD, you can see the directories of which your user account is a member or guest.
Before you begin

You must sign in with account that has RBAC Owner access to the subscription.
You must sign in with an account that exists in both the current directory with which the subscription is
associated and in the directory you want to add it to. To learn more about getting access to another directory,
see How do Azure Active Directory admins add B2B collaboration users?
To associate an existing subscription to your Azure AD directory

1. Sign in and select a subscription from the Subscriptions page in Azure portal.
2. Click Change directory.
3. Review the warnings. All Role-Based Access Control (RBAC) users with assigned access and all subscription
admins lose access when the subscription directory changes.
4. Select a directory.
5. Click Change.
6. Success! Use the directory switcher to go to the new directory. It might take up to 10 minutes for everything
to show up properly.
Changing the subscription directory is a service-level operation. It doesn't affect subscription billing ownership,
and the Account Admin can still change Service Admin using the Account Center. If you want to delete the original
directory, you must transfer the subscription billing ownership to a new Account Admin. To learn more about
transferring billing ownership, see Transfer ownership of an Azure subscription to another account.
Next steps
To learn more about creating a new Azure AD directory for free, see How to get an Azure Active Directory
tenant
To learn more about transferring billing ownership of an Azure subscription, see Transfer ownership of an
Azure subscription to another account
To learn more about how resource access is controlled in Microsoft Azure, see Understanding resource access
in Azure
For more information on how to assign roles in Azure AD, see Assigning administrator roles in Azure Active
Directory
Azure Active Directory FAQ
Azure Active Directory (Azure AD) is a comprehensive identity as a service (IDaaS) solution that spans all aspects of
identity, access management, and security.
For more information, see What is Azure Active Directory?.
Access Azure and Azure Active Directory

Q: Why do I get “No subscriptions found” when I try to access Azure AD in the Azure portal?
A: To access the Azure portal, each user needs permissions with an Azure subscription. If you have a paid Office
365 or Azure AD subscription, go to http://aka.ms/accessAAD for a one-time activation step. Otherwise, you will
need to activate a free Azure account or a paid subscription.
For more information, see:
How Azure subscriptions are associated with Azure Active Directory
Manage the directory for your Office 365 subscription in Azure
Q: What’s the relationship between Azure AD, Office 365, and Azure?
A: Azure AD provides you with common identity and access capabilities to all web services. Whether you are using
Office 365, Microsoft Azure, Intune, or others, you're already using Azure AD to help turn on sign-on and access
management for all these services.
All users who are set up to use web services are defined as user accounts in one or more Azure AD instances. You
can set up these accounts for free Azure AD capabilities like cloud application access.
Azure AD paid services like Enterprise Mobility + Security complement other web services like Office 365 and
Microsoft Azure with comprehensive enterprise-scale management and security solutions.
Q: What are the differences between Subscription Administrator and Directory Administrator?
A: By default, you are assigned the Subscription Administrator role when you sign up for Azure. A subscription
admin can use either a Microsoft account or a work or school account from the directory that the Azure
subscription is associated with. This role is authorized to manage services in the Azure portal.
If others need to sign in and access services by using the same subscription, you can add them as co-admins. This
role has the same access privileges as the service admin, but can’t change the association of subscriptions to Azure
directories. For additional information on subscription admins, see How to add or change Azure administrator roles
and How Azure subscriptions are associated with Azure Active Directory.
Azure AD has a different set of admin roles to manage the directory and identity-related features. These admins will
have access to various features in the Azure portal or the Azure portal. The admin's role determines what they can
do, like create or edit users, assign administrative roles to others, reset user passwords, manage user licenses, or
manage domains. For additional information on Azure AD directory admins and their roles, see Assigning
administrator roles in Azure Active Directory.
Additionally, Azure AD paid services like Enterprise Mobility + Security complement other web services, such as
Office 365 and Microsoft Azure, with comprehensive enterprise-scale management and security solutions.
Q: Is there a report that shows when my Azure AD user licenses will expire?
A: No. This is not currently available.
Get started with Hybrid Azure AD

Q: How do I leave a tenant when I am added as a collaborator?
A: When you are added to another organization's tenant as a collaborator, you can use the "tenant switcher" in the
upper right to switch between tenants. Currently, there is no way to leave the inviting organization, and Microsoft is
working on providing this functionality. Until this feature is available, you can ask the inviting organization to
remove you from their tenant.
Q: How can I connect my on-premises directory to Azure AD?

A: You can connect your on-premises directory to Azure AD by using Azure AD Connect.
For more information, see Integrating your on-premises identities with Azure Active Directory.
Q: How do I set up SSO between my on-premises directory and my cloud applications?

A: You only need to set up single sign-on (SSO) between your on-premises directory and Azure AD. As long as you
access your cloud applications through Azure AD, the service automatically drives your users to correctly
authenticate with their on-premises credentials.
Implementing SSO from on-premises can be easily achieved with federation solutions such as Active Directory
Federation Services (AD FS), or by configuring password hash sync. You can easily deploy both options by using
the Azure AD Connect configuration wizard.
For more information, see Integrating your on-premises identities with Azure Active Directory.
Q: Does Azure AD provide a self-service portal for users in my organization?

A: Yes, Azure AD provides you with the Azure AD Access Panel for user self-service and application access. If you
are an Office 365 customer, you can find many of the same capabilities in the Office 365 portal.
For more information, see Introduction to the Access Panel.
Q: Does Azure AD help me manage my on-premises infrastructure?

A: Yes. The Azure AD Premium edition provides you with Azure AD Connect Health. Azure AD Connect Health helps
you monitor and gain insight into your on-premises identity infrastructure and the synchronization services.
For more information, see Monitor your on-premises identity infrastructure and synchronization services in the
cloud.
Password management
Q: Can I use Azure AD password write-back without password sync? (In this scenario, is it possible to use
Azure AD self-service password reset (SSPR) with password write-back and not store passwords in the
cloud?)
A: You do not need to synchronize your Active Directory passwords to Azure AD to enable write-back. In a
federated environment, Azure AD single sign-on (SSO) relies on the on-premises directory to authenticate the user.
This scenario does not require the on-premises password to be tracked in Azure AD.
Q: How long does it take for a password to be written back to Active Directory on-premises?
A: Password write-back operates in real time.
For more information, see Getting started with password management.
Q: Can I use password write-back with passwords that are managed by an admin?
A: Yes, if you have password write-back enabled, the password operations performed by an admin are written back
to your on-premises environment.
For more answers to password-related questions, see Password management frequently asked questions.
Q: What can I do if I can't remember my existing Office 365/Azure AD password while trying to change
my password?
A: For this type of situation, there are a couple of options. Use self-service password reset (SSPR) if it's available.
Whether SSPR works depends on how it's configured. For more information, see How does the password reset
portal work.
For Office 365 users, your admin can reset the password by using the steps outlined in Reset user passwords.
For Azure AD accounts, admins can reset passwords by using one of the following:
Reset accounts in the Azure portal
Using PowerShell
Security
Q: Are accounts locked after a specific number of failed attempts or is there a more sophisticated
strategy used?
We use a more sophisticated strategy to lock accounts. This is based on the IP of the request and the passwords
entered. The duration of the lockout also increases based on the likelihood that it is an attack.
Q: Certain (common) passwords get rejected with the messages ‘this password has been used to many
times’, does this refer to passwords used in the current active directory?
This refers to passwords that are globally common, such as any variants of “Password” and “123456”.
Q: Will a sign-in request from dubious sources (botnets, tor endpoint) be blocked in a B2C tenant or does
this require a Basic or Premium edition tenant?
We do have a gateway that filters requests and provides some protection from botnets, and is applied for all B2C
tenants.
Application access
Q: Where can I find a list of applications that are pre-integrated with Azure AD and their capabilities?
A: Azure AD has more than 2,600 pre-integrated applications from Microsoft, application service providers, and
partners. All pre-integrated applications support single sign-on (SSO). SSO lets you use your organizational
credentials to access your apps. Some of the applications also support automated provisioning and de-
provisioning.
For a complete list of the pre-integrated applications, see the Active Directory Marketplace.
Q: What if the application I need is not in the Azure AD marketplace?

A: With Azure AD Premium, you can add and configure any application that you want. Depending on your
application’s capabilities and your preferences, you can configure SSO and automated provisioning.
Configuring single sign-on to applications that are not in the Azure Active Directory application gallery
Using SCIM to enable automatic provisioning of users and groups from Azure Active Directory to applications
Q: How do users sign in to applications by using Azure AD?

A: Azure AD provides several ways for users to view and access their applications, such as:
The Azure AD access panel
The Office 365 application launcher
Direct sign-in to federated apps
Deep links to federated, password-based, or existing apps
For more information, see Deploying Azure AD integrated applications to users.
Q: What are the different ways Azure AD enables authentication and single sign-on to applications?
A: Azure AD supports many standardized protocols for authentication and authorization, such as SAML 2.0, OpenID
Connect, OAuth 2.0, and WS-Federation. Azure AD also supports password vaulting and automated sign-in
capabilities for apps that only support forms-based authentication.
Authentication Scenarios for Azure AD
Active Directory authentication protocols
How does single sign-on with Azure Active Directory work?
Q: Can I add applications I’m running on-premises?

A: Azure AD Application Proxy provides you with easy and secure access to on-premises web applications that you
choose. You can access these applications in the same way that you access your software as a service (SaaS) apps in
Azure AD. There is no need for a VPN or to change your network infrastructure.
For more information, see How to provide secure remote access to on-premises applications.
Q: How do I require multi-factor authentication for users who access a particular application?
A: With Azure AD conditional access, you can assign a unique access policy for each application. In your policy, you
can require multi-factor authentication always, or when users are not connected to the local network.
For more information, see Securing access to Office 365 and other apps connected to Azure Active Directory.
Q: What is automated user provisioning for SaaS apps?

A: Use Azure AD to automate the creation, maintenance, and removal of user identities in many popular cloud SaaS
apps.
For more information, see Automate user provisioning and deprovisioning to SaaS applications with Azure Active
Directory.
Q: Can I set up a secure LDAP connection with Azure AD?

A: No. Azure AD does not support the LDAP protocol.
What's new in Azure Active Directory?
Stay up-to-date with what's new in Azure Active Directory by subscribing to our feed.
We are improving Azure Active Directory on an ongoing basis. To enable you to stay up to date with the most
recent developments, this topic provides you with information about:
The latest releases
Known issues
Bug fixes
Deprecated functionality
Plans for changes
Please revisit this page regularly as we are updating it on a monthly basis.
December 2017
Terms of use in the access panel for end users
Type: New feature
Service Category: Terms of Use
Product Capability: Governance/Compliance
End users now have the ability to go to access panel and view the terms of use that they have previously accepted.
Users can review and see the terms of use that they have accepted. This can be done using the following procedure:
1. Navigate and sign-in to the MyApps portal.
2. In upper right corner, click your name and select Profile from the drop-down.
3. On your Profile, click Review terms of use.
4. From there you can review the terms of use you have accepted.
For more information, see Azure Active Directory Terms of Use feature (Preview)
New Azure AD sign-in experience

Type: New feature
Service Category: Azure AD
Product Capability: User Authentication
As part of the journey to converge the Azure AD and Microsoft account identity systems, we have redesigned the UI
on both systems so that they have a consistent look and feel. In addition, we have paginated the Azure AD sign-in
page so that we collect the user name first, followed by the credential on a second screen.
For more information, see The new Azure AD Signin Experience is now in Public Preview
Fewer login prompts: A new “Keep me signed in” experience for Azure AD login
Type: New feature
We have replaced the Keep me signed in checkbox on the Azure AD login page with a new prompt that shows up
after the user successfully authenticates.
If a user responds Yes to this prompt, the service gives them a persistent refresh token. This is the same behavior
as when the user checks the Keep me signed in checkbox in the old experience. For federated tenants, this prompt
will show after the user successfully authenticates with the federated service.
For more information, see Fewer login prompts: The new “Keep me signed in” experience for Azure AD is in
preview
Add configuration to require the TOU to be expanded prior to accepting.

Type: New feature
Product Capability: Governance
We have now added an option for admins to require their end users to expand the terms of use prior to accepting
the terms.
Select either on or off for Require users to expand the terms of use. If this is set to on, end users will be required to
view the terms of use prior to accepting them.
For more information, see Azure Active Directory Terms of Use feature (Preview)
Scoped activation for eligible role assignments

Type: New feature
Service Category: Privileged Identity Management
Product Capability: Privileged Identity Management
Scoped activation allows you to activate eligible Azure resource role assignments with less autonomy than the
original assignment defaults. For example, you are assigned Owner of a subscription in your tenant. With scoped
activation, you can activate Owner for up to five resources contained within the subscription (think Resource
Groups, Virtual Machines, etc...). Scoping your activation may reduce the possibility of executing unwanted changes
to critical Azure resources.
For more information, see What is Azure AD Privileged Identity Management?.
New federated apps in Azure AD app gallery

Type: New feature
Service Category: Enterprise Apps
Product Capability: 3rd Party Integration
In December 2017 we have added following new apps in our App gallery with Federation support:
NAME INTEGRATION TYPE DESCRIPTION
EFI Digital StoreFront SAML 2.0 Web 2 Print application
Vodeclic SAML 2.0 Use Azure AD to manage user access

and enable single sign-on with Vodeclic.
Requires an existing Vodeclic account.
Accredible SAML 2.0 Create, manage and deliver certificates,

badges and blockchain credentials
FactSet SAML 2.0 Single Sign-on to FactSet's FDSWeb

application
MobileIron Azure AD Integration SAML 2.0 MobileIron mission is to enable modern

enterprises to secure and manage
information as it moves to mobile and
to the cloud, while preserving end-user
privacy and trust.
IMAGE WORKS SAML 2.0 Use Azure AD to manage user access,

provision user accounts, and enable
single sign-on with IMAGE WORKS.
Requires an existing IMAGE WORKS
subscription.
SAML SSO for Bitbucket by resolution SAML 2.0 SSO Bitbucket delegates authentication
GmbH to Azure AD, users already logged-in to
Azure AD can access Bitbucket directly.
Users can be created and updated on-
the-fly with data from SAML attributes.
SAML SSO for Bamboo by resolution SAML 2.0 SSO Bamboo delegates authentication
GmbH to Azure AD, users already logged-in to
Azure AD can access Bamboo directly.
Communifire SAML 2.0 Communifire is your modern, fully

featured social intranet software that
supports your employees and your
business.
MOBI SAML 2.0 Centralize, comprehend, and control

your entire device ecosystem.
Reflektive SAML 2.0 Reflektive is a modern platform for

Performance Management, Real-Time
Feedback, and Goal Setting. We
empower employees to drive their own
development, so you can be more
strategic.
CybSafe OpenID Connect & OAuth CybSafe is a GCHQ-certified cyber

awareness platform. It uses advanced
technology and data analytics to
demonstrably reduce the human aspect
of cyber security and data protection
risk.
WebHR OpenID Connect & OAuth Everyone's Favorite All-in-One Social HR

Software. Trusted by over 20,000
companies in 197 countries
Zenegy Azure AD Integration OpenID Connect & OAuth With this App you can use your
company’s Azure Active Directory
credentials to log into Zenegy.
Adobe Experience Manager SAML 2.0 Adobe Experience Manager (AEM), is a

comprehensive content management
platform solution for building websites,
mobile apps and forms - making it easy
to manage your marketing content and
assets.
Approval workflows for Azure AD directory roles

Type: Changed feature
Service Category: Privileged Identity Management
Approval workflow for Azure AD directory roles is generally available.
With approval workflow, privileged role administrators can require eligible role members request role activation
before they can use the privileged role. Multiple users and groups may be delegated approval responsibilities
Eligible role members receive notifications when the approval is complete and their role is active
Pass-through Authentication - Skype for Business support

Service Category: Authentications (Logins)
Pass-through Authentication now supports user sign-ins to Skype for Business client applications that support
modern authentication, including Online & Hybrid topologies.
For more information, see Skype for Business topologies supported with Modern Authentication.
Updates to Azure Active Directory Privileged Identity Management (PIM ) for Azure RBAC (preview)
Service Category: PIM
With our Public Preview Refresh of Azure Active Directory Privileged Identity Management (PIM) for Azure RBAC,
you can now:
Use Just Enough Administration Require approval to activate resource roles Schedule a future activation of a role
that requires approval for both AAD and Azure RBAC Roles
For more information, see PIM for Azure resources (Preview)
November 2017
Retiring ACS
Type: Plan for change
Service Category: ACS
Product Capability: Access Control Service
Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) will be retired in
late 2018. Further information, including a detailed schedule & high-level migration guidance, will be provided in
the next few weeks. In the meantime, leave comments on this page with any questions regarding ACS, and a
member of our team will help to answer.
Restrict browser access to the Intune managed browser
Service Category: Conditional Access
Product Capability: Identity Security & Protection
With this behavior, you will be able to restrict browser access to Office 365 and other Azure AD-connected cloud
apps using the Intune Managed Browser as an approved app.
This change allows you to configure the following condition for application-based conditional access:
Client apps: Browser
What is the effect of the change?
Today, access is blocked when using this condition. When the preview of this behavior is available, all access will
require the use of the managed browser application.
Look for this capability and more in the upcoming blogs and release notes.
For more information, see Conditional access in Azure Active Directory.
New approved client apps for Azure AD app-based conditional access

The following apps are planned to be added to the list of approved client apps:
Microsoft Kaizala
Microsoft StaffHub
Approved client app requirement
Azure Active Directory app-based conditional access
Terms of use support for multiple languages

Type: New feature
Product Capability: Governance/Compliance
Administrators can now create new terms of use (TOU) that contains multiple PDF documents. You can tag these
PDF documents with a corresponding language. Users that fall in scope are shown the PDF with the matching
language based on their preferences. If there is no match, the default language is shown.
Realtime password writeback client status

Type: New feature
Service Category: SSPR
You can now review the status of your on-premises password writeback client. This option is available in the On-
premises integration section of the Password reset page.
If there are issues with your connection to your on-premises writeback client, you will see an error message that
provides you with:
Information on why you can't connect to your on-premises writeback client
A link to documentation that assists you in resolving the issue.
For more information, see On-premises integration.
Azure AD app-based conditional access

Type: New feature
You can now restrict access to Office 365 and other Azure AD-connected cloud apps to approved client apps that
support Intune App Protection policies using Azure AD app-based conditional access. Intune app protection policies
are used to configure and protect company data on these client applications.
By combining app-based with device-based conditional access policies, you have the flexibility to protect data for
personal and company devices.
The following conditions and controls are now available for use with app-based conditional access:
Supported platform condition
iOS
Android
Client apps condition
Mobile apps and desktop clients
Access control
Require approved client app
For more information, see Azure Active Directory app-based conditional access.
Managing Azure AD devices in the Azure portal

Type: New feature
Service Category: Device Registration and Management
You can now find all your devices connected to Azure AD and the device-related activities in one place. There is a
new administration experience to manage all your device identities and settings in the Azure portal. In this release
you can:
View all your devices that are available for conditional access in Azure AD
View properties, including your Hybrid Azure AD joined devices
Find BitLocker keys for your Azure AD-joined devices, manage your device with Intune and more.
Manage Azure AD device-related settings
For more information, see Managing devices using the Azure portal.
Support for macOS as device platform for Azure AD conditional access

Type: New feature
You can now include (or exclude) macOS as device platform condition in your Azure AD conditional access policy.
With the addition of macOS to the supported device platforms, you can:
Enroll and manage macOS devices using Intune - Similar to other platforms like iOS and Android, a
company portal application is available for macOS to do unified enrollments. The new company portal app
for macOS enables you to enroll a device with Intune and register it with Azure AD.
Ensure macOS devices adhere to your organization’s compliance policies defined in Intune - In the
Intune on Azure portal, you can now set up compliance policies for macOS devices.  
Restrict access to applications in Azure AD to only compliant macOS devices - Conditional access policy
authoring has macOS as a separate device platform option. This option enables you to author macOS specific
conditional access policies for the targeted application set in Azure.
Create a device compliance policy for macOS devices with Intune
Conditional access in Azure Active Directory
NPS Extension for Azure MFA

Type: New feature
Service Category: MFA
The Network Policy Server (NPS) extension for Azure MFA adds cloud-based MFA capabilities to your
authentication infrastructure using your existing servers. With the NPS extension, you can add phone call, text
message, or phone app verification to your existing authentication flow without having to install, configure, and
maintain new servers.
This extension was created for organizations that want to protect VPN connections without deploying the Azure
MFA Server. The NPS extension acts as an adapter between RADIUS and cloud-based Azure MFA to provide a
second factor of authentication for federated or synced users.
For more information, see Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication
Restore or permanently remove deleted users

Type: New feature
Service Category: User Management
Product Capability: Directory
In the Azure AD admin center, you can now:
Permanently delete a user
To try it out:
1. In the Azure AD admin center, select All users in the Manage section.
2. From the Show list, select Recently deleted users.
3. Select one or more recently deleted users, and then either restore them, or permanently delete them.
New approved client apps for Azure AD app-based conditional access

The following apps have been added to the list of approved client apps:
Microsoft Planner
Microsoft Azure Information Protection
Ability to 'OR' between controls in a conditional access policy

The ability to 'OR' (Require one of the selected controls) conditional access controls has been released. This feature
enables you to create policies with an OR between access controls. For example, you can use this feature to create a
policy that requires a user to sign in using multi-factor authentication OR to be on a compliant device.
For more information, see Controls in Azure Active Directory conditional access.
Aggregation of realtime risk events

Service Category: Identity Protection
To improve your administration experience, in Azure AD Identity Protection, all realtime risk events that were
originated from the same IP address on a given day are now aggregated for each risk event type. This change limits
the volume of risk events shown without any change in the user security.
The underlying realtime detection works each time the user logs in. If you have a sign-in risk security policy setup
to MFA or block access, it is still triggered during each risky sign-in.
October 2017
Deprecating Azure AD reports
Service Category: Reporting
Product Capability: Identity Lifecycle Management
The Azure portal provides you with:
A new Azure Active Directory administration console
New APIs for activity and security reports
Due to these new capabilities, the report APIs under the /reports endpoint will be retired on December 10, 2017.
Automatic sign-in field detection

Type: Fixed
Service Category: My Apps
Product Capability: SSO
Azure Active Directory supports automatic sign-in field detection for applications that render an HTML username
and password field. These steps are documented in How to automatically capture sign-in fields for an application.
You can find this capability by adding a Non-Gallery application on the Enterprise Applications page in the Azure
portal. Additionally, you can configure the Single Sign-on mode on this new application to Password-based
Single Sign-on, entering a web URL, and then saving the page.
Due to a service issue, this functionality was temporarily disabled for a period of time. The issue has been resolved
and the automatic sign-in field detection is available again.
New MFA features

Type: New feature
Service Category: MFA
Multi-Factor authentication (MFA) is an essential part of protecting your organization. To make credentials more
adaptive and the experience more seamless, the following features have been added:
Integration of multi-factor challenge results directly into the Azure AD sign-in report, including
programmatic access to MFA results
Deeper integration of the MFA configuration into the Azure AD configuration experience in the Azure portal
With this public preview, MFA management and reporting are an integrated part of the core Azure AD
configuration experience. Aggregating both features enables you to manage the MFA management portal
functionality within the Azure AD experience.
For more information, see Reference for multi-factor authentication reporting in the Azure portal
Introducing terms of use

Type: New feature
Azure AD terms of use provide you with a simple method to present information to end users. This ensures that
users see relevant disclaimers for legal or compliance requirements.
You can use Azure AD terms of use in the following scenarios:
General terms of use for all users in your organization.
Specific terms of use based on a user's attributes (ex. doctors vs nurses or domestic vs international
employees, done by dynamic groups).
Specific terms of use for accessing high business impact apps, like Salesforce.
For more information, see Azure Active Directory Terms of Use.
Enhancements to privileged identity management

Type: New feature
Service Category: PIM
With Azure Active Directory Privileged Identity Management (PIM), you can now manage, control, and monitor
access to Azure Resources (Preview) within your organization to:
Subscriptions
Resource groups
Virtual machines.
All resources within the Azure portal that leverage the Azure Role Based Access Control (RBAC) functionality can
take advantage of all the security and lifecycle management capabilities Azure AD PIM has to offer.
For more information, see PIM for Azure resources.
Introducing access reviews

Type: New feature
Service Category: Access Reviews
Access reviews (preview) enable organizations to efficiently manage group memberships and access to enterprise
applications:
You can recertify guest user access using access reviews of their access to applications and memberships of
groups. The insights provided by the access reviews enable reviewers to efficiently decide whether guests
should have continued access.
You can recertify employees access to applications and group memberships with access reviews.
You can collect the access review controls into programs relevant for your organization to track reviews for
compliance or risk-sensitive applications.
For more information, see Azure AD access reviews.
Hiding third-party applications from My Apps and the Office 365 launcher
Type: New feature
Service Category: My Apps
Product Capability: SSO
You can now better manage apps that show up on your user portals through a new hide app property. Hiding
apps helps with cases where app tiles are showing up for backend services or duplicate tiles and end up cluttering
user's app launchers. The toggle is located on the properties section of the third-party app and is labeled Visible to
user? You can also hide an app programmatically through PowerShell.
For more information, see Hide a third-party application from user's experience in Azure Active Directory.
What's available?
As part of the transition to the new admin console, 2 new APIs for retrieving Azure AD Activity Logs are available.
The new set of APIs provides richer filtering and sorting functionality in addition to providing richer audit and sign-
in activities. The data previously available through the security reports can now be accessed through the Identity
Protection risk events API in Microsoft Graph.
September 2017
Hotfix for Microsoft Identity Manager
Service Category: Microsoft Identity Manager
Product Capability: Identity Lifecycle Management
A hotfix rollup package (build 4.4.1642.0) is available as of September 25, 2017, for Microsoft Identity Manager
(MIM) 2016 2016 Service Pack 1 (SP1). This roll-up package:
Resolves issues and adds improvements
Is a cumulative update that replaces all MIM 2016 SP1 updates up to build 4.4.1459.0 for Microsoft Identity
Manager 2016.
Requires you to have Microsoft Identity Manager 2016 build 4.4.1302.0.
For more information, see Hotfix rollup package (build 4.4.1642.0) is available for Microsoft Identity Manager 2016
SP1.
Get started with Azure AD
Modern identity management requires scaleable, consistent reliablity to ensure the availablity of applications and
services to only authenticated users. To adequately support the identity management needs of users, IT needs a
way to provide access to approved, public software as a service (SaaS) apps, a way to host internal line of business
apps, and even ways to enhance on-premises app development and usage. All of these requirements point to the
need of a cloud-based identity management solution.
Azure Active Directory (Azure AD) is Microsoft’s multi-tenant, cloud based directory and identity management
service. Azure AD combines core directory services, advanced identity governance, and application access
management. The multi-tenant, geo-distributed, high availability design of Azure AD means that you can rely on it
for your most critical business needs.
Azure AD includes a full suite of identity management capabilities including the ability to synchronize on-premises
resource information, customizable company branding, simple license management, and even self-service
password management. These easy-to-deploy capabilities can help you get started using Azure AD to secure cloud-
based applications, streamline IT processes, cut costs, and help ensure that corporate compliance goals are met.
The rest of this article tells you how to get started with Azure AD.
Sign up for Azure Active Directory Premium

To get started with Azure Active Directory (Azure AD) Premium, you can purchase licenses and associate them with
your Azure subscription. If you create a new Azure subscription, you will also need to activate your licensing plan
and Azure AD service access.
To sign up for Active Directory Premium, you have several options:
Use your Azure or Office 365 subscription
Use an Enterprise Mobility + Security licensing plan
Use a Microsoft Volume Licensing plan
Verification step
After activating the subscription, ensure that you can log in to the service.
Add a custom domain name

Every Azure AD directory comes with an initial domain name in the form of domainname.onmicrosoft.com. The
initial domain name cannot be changed or deleted, but you can also add your corporate domain name to Azure AD.
For example, your organization probably has other domain names used to do business and users who sign in using
your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in the
directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of 'alice@.onmicrosoft.com'. The
process is simple:
1. Add the custom domain name to your directory
2. Add a DNS entry for the domain name at the domain name registrar
3. Verify the custom domain name in Azure AD
Verification step
After adding a custom domain, ensure that it has the Verified status displayed on the Custom domain names
blade of the Azure AD portal.
Add company branding to your sign-in page

To avoid confusion, many companies want to apply a consistent look and feel across all the websites and services
they manage. Azure Active Directory (Azure AD) provides this capability by allowing you to customize the
appearance of the sign-in page with your company logo and custom color schemes. The sign-in page is the page
that appears when you sign in to Office 365 or other web-based applications that are using Azure AD as their
identity provider. You interact with this page to enter your credentials.
Verification step
Log in to the Azure portal and ensure that your customized sign-in page and any additional language
customizations have been configured correctly.
Add new users

You can add new users to your organization's Azure AD one at a time using the Azure portal or by synchronizing
your on-premises Windows Server AD resource data. You can add cloud-based users directly from the Azure AD
portal or synchronize on-premises user information.
To enable on-premises identity synchronization to Azure AD, you need to install and configure Azure AD Connect
on a server in your organization. This application handles synchronizing users and groups from your existing
identity source to your Azure AD tenant.
Verification step
After creating or synchronizing new users, make sure they are visible in Azure AD.
Assign licenses
Although obtaining a subscription is all you need to configure paid capabilities, you must still assign user licenses
for Azure AD Premium paid features. Any user who should have access to, or who is managed through, an Azure
AD paid feature must be assigned a license. License assignment is a mapping between a user and a purchased
service, such as Azure AD Premium, Basic, or Enterprise Mobility + Security.
You can use group-based license assignment to set up rules such as in the following examples:
All users in your directory automatically get a license
Everyone with the appropriate job title gets a license
You can delegate the decision to other managers in the organization (by using self-service groups)
Verification step
Review assigned and available licenses under Azure Active Directory > Licenses > All products.
Configure self-service password reset
Self-service password reset (SSPR) offers a simple means for IT administrators to enable users to reset or unlock
their passwords or accounts. The system includes detailed reporting to track when users use the system along with
notifications to alert you to misuse or abuse.
Verification step
Review enabled SSPR properties under Azure Active Directory > Password reset to ensure the proper user and
group assignments have been made.
Next steps
Azure Active Directory service page
Azure Active Directory pricing information page
Quickstart: Sign up for Azure Active Directory
Premium
To get started with Azure Active Directory (Azure AD) Premium, you can purchase licenses and associate them
with your Azure subscription. If you create a new Azure subscription, you also need to activate your licensing plan
and Azure AD service access as described in the following sections.
Sign up for Active Directory Premium

To sign up for Active Directory Premium, you have several options:
Use your Azure or Office 365 subscription
Use an Enterprise Mobility + Security licensing plan
Use a Microsoft Volume Licensing plan
Azure or Office 365
As an Azure or Office 365 subscriber, you can buy Azure Active Directory Premium online.
For detailed steps, see How to Purchase Azure Active Directory Premium - Existing Customers or How to Purchase
Azure Active Directory Premium - New Customers.
Enterprise Mobility + Security
Enterprise Mobility + Security (EMS) is a cost effective way for organizations to use the following services
together under one licensing plan: Azure Active Directory Premium, Azure Information Protection, and Microsoft
Intune. You can learn more about EMS at the Enterprise Mobility + Security web site and more about the EMS
license types available for purchase on the Enterprise Mobility + Security Pricing Options page.
You can get started with Azure AD via EMS licenses using one of the following licensing options:
Try out EMS with a free Enterprise Mobility + Security E5 trial subscription
Purchase Enterprise Mobility + Security E5 licenses
Purchase Enterprise Mobility + Security E3 licenses
Microsoft volume licensing
Azure Active Directory Premium is available through a Microsoft Enterprise Agreement (250 or more licenses) or
the Open Volume License (5–250 licenses) program.
You can learn more about volume licensing purchase options on the How to purchase through Volume Licensing
page.
NOTE
Azure Active Directory Premium and Basic editions are available for customers in China using the worldwide instance of
Azure Active Directory. Azure Active Directory Premium and Basic editions are not currently supported in the Microsoft
Azure service operated by 21Vianet in China. For more information, contact us at the Azure Active Directory Forum.
If you have previously purchased and activated Azure AD licenses for the same Azure subscription that you used
in the preceding steps, then the licenses are automatically activated in the same directory. If not, continue with the
steps described in the rest of this article.
Activate your license plan
Is this your first Azure AD license plan you've purchase from Microsoft? If so, a confirmation email is generated
and sent to you when your purchase has been completed. You need this email to activate your first license plan.
To activate your license plan, perform one of the following steps:
1. To start the activation, click either Sign In or Sign Up.
If you have an existing tenant, click Sign In to sign in with your existing administrator account. Sign
in with global administrator credentials for the tenant where the licenses must be activated.
If you want to create a new Azure AD tenant to use with your licensing plan, click Sign Up to open
the Create Account Profile dialog.
When you are done, the following dialog shows up as confirmation for the activation of the license plan for your
tenant:
Activate your Azure Active Directory access

If you are adding new Azure AD Premium licenses to an existing subscription, your Azure AD access should
already be activated. Otherwise, you need to activate Azure AD access after you receive the Welcome email.
When the licenses you purchased have been provisioned in your directory, a Welcome email is sent to you. The
email confirms that you can start managing your Azure Active Directory Premium or Enterprise Mobility +
Security licenses and features.
TIP
You cannot access Azure AD for your new tenant until you activate Azure AD directory access using the welcome email sent
automatically when the license provisioning process has completed.
To activate your Azure AD access, perform the following steps:

1. In your Welcome email, click Sign In.
2. After signing in successfully, you also need to complete a second factor authentication using a mobile
device:
The activation should only take a few minutes and then you will have access to manage your Azure AD.
Next steps
In this quickstart, you’ve learned how to sign up for Azure AD Premium and activate your Azure Active Directory
access.
If you already have an Azure subscription, you can use the following link to start a trial or purchase Azure AD
Premium licenses from the Azure portal.
Activate Azure AD Premium licenses
Quickstart: Add a custom domain name to Azure
Active Directory
initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as
well. For example, your organization probably has other domain names used to do business and users who sign in
using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user names in
the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of 'alice@domain
name.onmicrosoft.com'. The process is simple:
Add the custom domain name to your directory

1. Sign in to the Azure portal with an account that's a global admin for the directory.
2. On the left, select Custom domain names.
3. Select Add custom domain.
4. On Custom domain names, enter the name of your custom domain in the box, such as 'contoso.com', and then
select Add Domain. Be sure to include the .com, .net, or other top-level extension.
5. On domainname (that is, your new domain name is the title), gather the DNS entry information to use later
to verify the custom domain name in Azure AD.
TIP
If you plan to federate your on-premises Windows Server AD with Azure AD, then you need to select the I plan to configure
this domain for single sign-on with my local Active Directory checkbox when you run the Azure AD Connect tool to
synchronize your directories. You also need to register the same domain name you select for federating with your on-
premises directory in the Azure AD Domain step in the wizard. You can see what that step in the wizard looks like in these
instructions. If you do not have the Azure AD Connect tool, you can download it here.
Add a DNS entry for the domain name at the domain name registrar
The next step to use your custom domain name with Azure AD is to update the DNS zone file for the domain. Azure
AD can then verify that your organization owns the custom domain name. You can use Azure DNS for your
Azure/Office 365/external DNS records within Azure, or add the DNS entry at a different DNS registrar.
1. Sign in to the domain name registrar for the domain. If you don't have access to update the DNS entry, ask the
person or team who has this access to complete step 2 and to let you know when it is completed.
2. Update the DNS zone file for the domain by adding the DNS entry provided to you by Azure AD. The DNS entry
doesn't change any behaviors such as mail routing or web hosting.
Verify the custom domain name in Azure AD

Once you have added the DNS entry, you are ready to verify the domain name with Azure AD. A domain name can
be verified only after the DNS records have propagated. This propagation often takes only seconds, but it can
sometimes take an hour or more. If verification doesn’t work the first time, try again later.
1. Sign in to Azure AD with an account that's a global admin for the tenant.
2. Select Custom domain names.
3. Select the unverified domain name that you want to verify.
4. Check your entries and select Verify to complete the verification.
Now you can assign user names that include your custom domain name. You can create cloud-based user accounts,
or update previously synchronized on-premises user account information, using your custom domain name. You
can also change synchronized user account domain suffix information using Microsoft PowerShell or the Graph API.
TIP
You can add up to a maximum of 900 managed domain names. If you are configuring all of your domains for federation on-
premises with Active Directory, you can add up to a maximum of 450 domain names in each directory. For more information,
see Federated and managed domain names.
Troubleshooting
If you can't verify a custom domain name, try the following troubleshooting steps:
1. Wait an hour. DNS records must propagate before Azure AD can verify the domain. This process can take an
hour or more.
2. Ensure the DNS record was entered, and that it is correct. Complete this step at the website for the
domain name registrar for the domain. Azure AD can't verify the domain name if
The DNS entry is not present in the DNS zone file
It is not an exact match with the DNS entry that Azure AD provided you.
If you do not have access to update DNS records for the domain at the domain name registrar, share the
DNS entry with the person or team at your organization who has this access, and ask them to add the DNS
entry.
3. Delete the domain name from another directory in Azure AD. A domain name can be verified in only a
single directory. If a domain name is currently verified in a different directory, it can't be verified in your new
directory until it is deleted on the other one. To learn about deleting domain names, read Manage custom
domain names.
Repeat the steps in this article to add each of your domain names.
Learn more
Conceptual overview of custom domain names in Azure AD
Manage custom domain names
Next steps
In this quickstart, you’ve learned how to add a custom domain to Azure AD.
You can use the following link to add a new custom domain in Azure AD from the Azure portal.
Add a custom domain
Quickstart: Add company branding to your sign-in
page in Azure AD
To avoid confusion, many companies want to apply a consistent look and feel across all the websites and services
they manage. Azure Active Directory (Azure AD) provides this capability by allowing you to customize the
appearance of the sign-in page with your company logo and custom color schemes. The sign-in page is the page
that appears when you sign in to Office 365 or other web-based applications that are using Azure AD as your
identity provider. You interact with this page to enter your credentials.
NOTE
Company branding is available only if you upgraded to the Premium or Basic edition of Azure AD, or have an Office
365 license. To learn if a feature is supported by your license type, check the Azure Active Directory pricing
information page.
Azure Active Directory Premium and Basic editions are available for customers in China using the worldwide instance
of Azure Active Directory. Azure Active Directory Premium and Basic editions are not currently supported in the
Microsoft Azure service operated by 21Vianet in China. For more information, contact us at the Azure Active
Directory Forum.
Customizing the sign-in page

Company branding customizations appear on the Azure AD sign-in page when users access a tenant-specific URL
such as https://outlook.com/contoso.com.
When users visit a generic URL such as www.office.com, the sign-in page does not contain company branding
customizations because the system doesn’t know who the user is. Company branding will show after users enter
their user ID or select a user tile.
NOTE
Your domain name must appear as “Active" in the Domains portion of the Azure portal in which you have configured
branding. For more information, see Add a custom domain name.
Sign-in page branding doesn’t carry over to the sign-in page for personal Microsoft accounts. If your employees or
business guests sign in with a personal Microsoft account, their sign-in page does not reflect the branding of your
organization.
Banner logo
DESCRIPTION CONSTRAINTS RECOMMENDATIONS
The banner logo is displayed on the Transparent JPG or PNG Use your organization’s logo here.
sign-in and the Access panel pages. Max height: 36 px Use a transparent image. Don’t assume
On the sign-in page, this shows once Max width: 245 px that the background will be white.
the user’s organization is determined, Do not add padding around your logo
usually after the username is entered. in the image or your logo will look
disproportionately small.
Username hint
This customizes the hint text in the Unicode text up to 64 characters We recommend that you do not set
username field. Plain text only this if you expect guest users outside
your organization to sign in to your
app.
Sign-in page text

This appears at the bottom of the sign- Unicode text up to 256 characters
in form and can be used to Plain text only (no links or HTML tags)
communicate additional information
such as the phone number to your help
desk, or a legal statement.
Sign-in page image

This appears in the background of the JPG or PNG

sign-in page, is anchored to the center Image dimensions: 1920x1080 px Use images where there isn't a strong
of the viewable space, and will scale and File size: < 300 KB subject focus. The opaque sign-in form
crop to fill the browser window. appears over the center of this image
On narrow screens such as mobile and can cover any part of the image
phones, this image is not shown. depending on the size of the browser
A black mask with 0.55 opacity will be window.
applied over this image by our code Keep the file size as small as possible to
when the page is loaded. ensure quick load times.
Background Color
This color is used in place of the RGB color in hexadecimal (example: We suggest using the primary color of
background image on low-bandwidth #FFFFFF the banner logo or your organization
connections. color.
Show option to remain signed in

Azure AD sign in gives the user the This does not affect session lifetime.
option to remain signed in when they Some features of SharePoint Online and
close and re-open their browser. Use Office 2010 depend on users being able
this to hide that option. to choose to remain signed in. If you
Set this to “No” to hide this option from set this to be hidden, your users may
your users. see additional and unexpected prompts
to sign-in.
NOTE
All elements are optional. For example, if you specify a banner logo with no background image, the sign-in page will show
your logo and the background image for the destination site (for example, Office 365).
Add company branding to your directory
2. Select More services, enter Users and groups in the text box, and then select Enter.
3. On the Users and groups blade, select Company branding.

4. On the Users and groups - Company branding blade, select the Edit command.
5. Modify the elements you want to customize. All elements are optional.
6. Click Save.
It can take up to an hour for any changes you made to the sign-in page branding to appear.
Add language-specific company branding to your directory

1. Sign in to the Azure AD admin center with an account that's a global admin for the directory.
2. Select Users and groups in the text box, and then select Enter.
3. On the Users and groups blade, select Company branding.
4. On the Users and groups - Company branding blade, select the Add language command.
5. Modify the elements you want to customize. All elements are optional.
6. Click Save.
It can take up to an hour for any changes you made to the sign-in page branding to appear.
Next steps
In this quickstart, you’ve learned how to add company branding to your Azure AD directory.
You can use the following link to configure your company branding in Azure AD from the Azure portal.
Configure company branding
Quickstart: Add new users to Azure Active Directory
This article explains how to delete or add users in your organization into your orgnization's Azure Active Directory
(Azure AD) tenant using the Azure portal or by synchronizing your on-premises Windows Server AD user account
data.
Add cloud-based users

1. Sign in to the Azure Active Directory admin center with an account that's a global admin for the directory.
2. Select Azure Active Directory and then Users and groups.
3. On Users and groups, select All users, and then select New user.
4. Enter details for the user, such as Name and User name. The domain name portion of the user name must
either be the initial default domain name "[domain name].onmicrosoft.com" or a verified, non-federated custom
domain name such as "contoso.com."
5. Copy or otherwise note the generated user password so that you can provide it to the user after this process is
complete.
6. Optionally, you can open and fill out the information in Profile, Groups, or Directory role for the user. For
more information about user and administrator roles, see Assigning administrator roles in Azure AD.
7. On User, select Create.
8. Securely distribute the generated password to the new user so that the user can sign in.
TIP
You can also synchronize user account data from on-premises Windows Server AD. Microsoft’s identity solutions span on-
premises and cloud-based capabilities, creating a single user identity for authentication and authorization to all resources,
regardless of location. We call this Hybrid Identity. Azure AD Connect can be used to integrate your on-premises directories
with Azure Active Directory for hybrid identity scenarios. This allows you to provide a common identity for your users for
Office 365, Azure, and SaaS applications integrated with Azure AD.
Delete users from Azure AD
2. Select Users and groups.
3. On the Users and groups blade, select the user to delete from the list.
4. On the blade for the selected user, select Overview, and then in the command bar, select Delete.
Learn more
Add guest users from another directory
Assign a user to a role in your Azure AD
Next steps
In this quickstart, you’ve learned how to add new users to Azure AD Premium.
You can use the following link to create a new user in Azure AD from the Azure portal.
Quickstart: License users in Azure Active Directory
License-based Azure AD services work by activating an Azure Active Directory (Azure AD) subscription in your
Azure tenant. After the subscription is active, service capabilities are managed by Azure AD administrators and
used by licensed users. When you purchase Enterprise Mobility + Security, Azure AD Premium, or Azure AD Basic,
your tenant is updated with the subscription, including its validity period and prepaid licenses. Your subscription
information, including the number of assigned or available licenses, is available through the Azure portal under
Azure Active Directory by opening the Licenses tile. The Licenses blade is also the best place to manage your
license assignments.
Although obtaining a subscription is all you need to configure paid capabilities, you must still assign user licenses
for paid Azure AD paid features. Any user who should have access to, or who is managed through, an Azure AD
paid feature must be assigned a license. License assignment is a mapping between a user and a purchased service,
such as Azure AD Premium, Basic, or Enterprise Mobility + Security.
You can use group-based license assignment to set up rules such as the following:
All users in your directory automatically get a license
Everyone with the appropriate job title gets a license
You can delegate the decision to other managers in the organization (by using self-service groups)
TIP
For a detailed discussion of license assignment to groups, including advanced scenarios and Office 365 licensing scenarios,
see Assign licenses to users by group membership in Azure Active Directory.
Assign licenses to users and groups

Using an active subscription, you should first assign a license to yourself and refresh your browser to ensure that
you see all of the expected features included with your subscription. The next step is to assign licenses to the users
who need access to paid Azure AD features. An easy way to assign licenses is to assign licenses to groups of users
rather than to individuals. When you assign licenses to a group, all group members are assigned a license. If users
are added or removed from the group, the appropriate license is automatically assigned or removed.
NOTE
Some Microsoft services are not available in all locations. Before a license can be assigned to a user, the administrator must
specify the Usage location property for the user. You can set this property under User > Profile > Settings in the Azure
portal. When using group license assignment, any user whose usage location is not specified inherits the location of the
directory.
To assign a license, under Azure Active Directory > Licenses > All Products, select one or more products, and
then select Assign on the command bar.
You can use the Users and groups blade to choose multiple users or groups or to disable service plans in the
product. Use the search box on top to search for user and group names.
When you assign licenses to a group, it can take some time before all users inherit the license depending on the
size of the group. You can check the processing status on the Group blade, under the Licenses tile.
Assignment errors can occur during Azure AD license assignment but are relatively rare when managing Azure AD
and Enterprise Mobility + Security products. Potential assignment errors are limited to:
Assignment conflict: When a user was previously assigned a license that is incompatible with the current license.
In this case, assigning the new license requires removing the current one.
Exceeded available licenses: When the number of users in assigned groups exceeds the available licenses, a
user's assignment status reflects a failure to assign due to missing licenses.
Azure AD B2B collaboration licensing
B2B collaboration allows you to invite guest users into your Azure AD tenant to provide access to Azure AD
services and any Azure resources you make available.
There is no charge for inviting B2B users and assigning them to an application in Azure AD. Up to 10 apps per
guest user and 3 basic reports are also free for B2B collaboration users. If your guest user has any appropriate
licenses assigned in the partner's Azure AD tenant, they'll be licensed in yours as well.
It's not required, but if you want to provide access to paid Azure AD features, those B2B guest users must be
licensed with appropriate Azure AD licenses. An inviting tenant with an Azure AD paid license can assign B2B
collaboration user rights to an additional five guest users invited to the tenant. For scenarios and information, see
B2B collaboration licensing guidance.
View assigned licenses

A summary view of assigned and available licenses is displayed under Azure Active Directory > Licenses > All
products.
A detailed list of assigned users and groups is available when selecting a specific product. The Licensed Users list
shows all users currently consuming a license and whether the license was assigned directly to the user or if it is
inherited from a group.
Similarly, the Licensed Groups list shows all groups to which licenses have been assigned. Select a user or group
to open the Licenses blade, which shows all licenses assigned to that object.
Remove a license
To remove a license, go to the user or group, and open the Licenses tile. Select the license, and click Remove.
Licenses inherited by the user from a group cannot be removed directly. Instead, remove the user from the group
from which they are inheriting the license.
Next steps
In this quickstart, you’ve learned how to assign licenses to users and groups in Azure AD directory.
You can use the following link to configure subscription license assignments in Azure AD from the Azure portal.
Assign Azure AD licenses
Azure AD self-service password reset rapid
deployment
IMPORTANT
Are you here because you're having problems signing in? If so, see Help, I forgot my Azure AD password.
Self-service password reset (SSPR) offers a simple means for IT administrators to empower users to reset or
unlock their passwords or accounts. The system includes detailed reporting that tracks when users access the
system, along with notifications to alert you to misuse or abuse.
This guide assumes you already have a working trial or licensed Azure Active Directory (Azure AD) tenant. If you
need help setting up Azure AD, see Getting started with Azure AD.
Enable SSPR for your Azure AD tenant

1. From your existing Azure AD tenant, select Password reset.
2. From the Properties page, under the option Self Service Password Reset Enabled, choose one of the
following:
None: No one can use the SSPR functionality.
Selected: Only members of a specific Azure AD group that you choose can use the SSPR functionality.
We recommend that you define a group of users and use this setting when you deploy this
functionality for a proof of concept.
All: All users with accounts in your Azure AD tenant can use the SSPR functionality. We recommend
that you use this setting when you're ready to deploy this functionality to your entire tenant after you
have completed a proof of concept.
IMPORTANT
Azure Administrator accounts will always have the ability to reset their passwords no matter what this option is set
to.
3. From the Authentication methods page, choose the following:

Number of methods required to reset: We support a minimum of one or a maximum of two.
Methods available to users: We need at least one, but it never hurts to have an extra choice
available.
Email: Sends an email with a code to the user's configured authentication email address.
Mobile phone: Gives the user the choice to receive a call or text with a code to their configured
mobile phone number.
Office phone: Calls the user with a code to their configured office phone number.
Security questions: Requires you to choose:
Number of questions required to register: The minimum for successful registration. A
user can choose to answer more questions to create a pool of questions to pull from. This
option can be set to three to five questions and must be greater than or equal to the
number of questions required to reset their password. The user can add custom questions
if they select the Custom button when they select their security questions.
Number of questions required to reset: Can be set from three to five questions to be
answered correctly before you allow a user's password to be reset or unlocked.
4. Recommended: Under Customization, you can change the Contact your administrator link to point to
a page or email address you define. We recommend that you set this link to something like an email
address or website that your users already use for support questions.
5. Optional: The Registration page provides administrators with the option to:
Require users to register when they sign in.
Set the number of days before users are asked to reconfirm their authentication information.
6. Optional: The Notifications page provides administrators with the option to:
Notify users on password resets.
Notify all admins when other admins reset their password.
At this point, you have configured SSPR for your Azure AD tenant. Your users can now use the instructions found
in the articles Register for self-service password reset and Reset or change your password to update their
password without administrator intervention. You can stop here if you're cloud-only. Or you can continue to the
next section to configure the synchronization of passwords to an on-premises Active Directory domain.
TIP
Test SSPR with a user rather than an administrator, because Microsoft enforces strong authentication requirements for
Azure administrator accounts. For more information regarding the administrator password policy, see our password policy
article.
Configure synchronization to an existing identity source

To enable on-premises identity synchronization to Azure AD, you need to install and configure Azure AD Connect
on a server in your organization. This application handles the synchronization of users and groups from your
existing identity source to your Azure AD tenant. For more information, see:
Upgrade from DirSync or Azure AD Sync to Azure AD Connect
Get started with Azure AD Connect by using express settings
Configure password writeback to write passwords from Azure AD back to your on-premises directory
On-premises policy change
If you synchronize users from an on-premises Active Directory domain and want to allow users to reset their
passwords immediately, make the following change to your on-premises password policy:
1. Browse to Computer Configuration > Policies > Windows Settings > Security Settings > Account
Policies > Password Policy.
2. Set the Minimum password age to 0 days.
This security setting determines the period of time, in days, that a password must be used before the user can
change it. If you set the minimum usage setting to 0 days, users can use SSPR if their passwords are changed by
their support teams.
Disable self-service password reset

It's easy to disable self-service password reset. Open your Azure AD tenant and go to Password Reset >
Properties, and then select None under Self Service Password Reset Enabled.
Learn more
The following articles provide additional information regarding password reset through Azure AD:
How do I complete a successful rollout of SSPR?
Reset or change your password
Register for self-service password reset
Do you have a licensing question?
What data is used by SSPR and what data should you populate for your users?
What authentication methods are available to users?
What are the policy options with SSPR?
What is password writeback and why do I care about it?
How do I report on activity in SSPR?
What are all of the options in SSPR and what do they mean?
I think something is broken. How do I troubleshoot SSPR?
I have a question that was not covered somewhere else
Next steps
In this quickstart, you’ve learned how to configure self-service password reset for your users. To complete these
steps, continue to the Azure portal:
Enable self-service password reset
Understand Azure Active Directory architecture
Azure Active Directory (Azure AD) enables you to securely manage access to Azure services and resources for your
users. Included with Azure AD is a full suite of identity management capabilities. For information about Azure AD
features, see What is Azure Active Directory?
With Azure AD, you can create and manage users and groups, and enable permissions to allow and deny access to
enterprise resources. For information about identity management, see The fundamentals of Azure identity
management.
Azure AD architecture
Azure AD's geographically distributed architecture combines extensive monitoring, automated rerouting, failover,
and recovery capabilities enable us to deliver enterprise-level availability and performance to our customers.
The following architecture elements are covered in this article:
Service architecture design
Scalability
Continuous availability
Data centers
Service architecture design
The most common way to build a scalable, highly-available, data-rich system is through independent building
blocks or scale units for the Azure AD data tier, scale units are called partitions.
The data tier has several front-end services that provide read-write capability. The diagram below shows how the
components of a single-directory partition are distributed throughout geographically-distributed data centers.
The components of Azure AD architecture include a primary replica and secondary replicas.
Primary replica
The primary replica receives all writes for the partition it belongs to. Any write operation is immediately replicated
to a secondary replica in a different datacenter before returning success to the caller, thus ensuring geo-redundant
durability of writes.
Secondary replicas
All directory reads are serviced from secondary replicas, which are at data centers that are physically located across
different geographies. There are many secondary replicas, as data is replicated asynchronously. Directory reads,
such as authentication requests, are serviced from data centers that are close to our customers. The secondary
replicas are responsible for read scalability.
Scalability
Scalability is the ability of a service to expand to meet increasing performance demands. Write scalability is
achieved by partitioning the data. Read scalability is achieved by replicating data from one partition to multiple
secondary replicas distributed throughout the world.
Requests from directory applications are generally routed to the datacenter that they are physically closest to.
Writes are transparently redirected to the primary replica to provide read-write consistency. Secondary replicas
significantly extend the scale of partitions because the directories are typically serving reads most of the time.
Directory applications connect to the nearest datacenters. This improves performance, and therefore scaling out is
possible. Since a directory partition can have many secondary replicas, secondary replicas can be placed closer to
the directory clients. Only internal directory service components that are write-intensive target the active primary
replica directly.
Continuous availability
Availability (or uptime) defines the ability of a system to perform uninterrupted. The key to Azure AD’s high-
availability is that our services can quickly shift traffic across multiple geographically-distributed data centers. Each
data center is independent, which enables de-correlated failure modes.
Azure AD’s partition design is simplified compared to the enterprise AD design, which is critical for scaling up the
system. We adopted a single-master design that includes a carefully orchestrated and deterministic primary replica
failover process.
Fault tolerance
A system is more available if it is tolerant to hardware, network, and software failures. For each partition on the
directory, a highly available master replica exists: The primary replica. Only writes to the partition are performed at
this replica. This replica is being continuously and closely monitored, and writes can be immediately shifted to
another replica (which becomes the new primary) if a failure is detected. During failover, there could be a loss of
write availability typically of 1-2 minutes. Read availability is not affected during this time.
Read operations (which outnumber writes by many orders of magnitude) only go to secondary replicas. Since
secondary replicas are idempotent, loss of any one replica in a given partition is easily compensated by directing
the reads to another replica, usually in the same datacenter.
Data durability
A write is durably committed to at least two data centers prior to it being acknowledged. This happens by first
committing the write on the primary, and then immediately replicating the write to at least one other data center.
This ensures that a potential catastrophic loss of the data center hosting the primary does not result in data loss.
Azure AD maintains a zero Recovery Time Objective (RTO) for token issuance and directory reads and in the order
of minutes (~5 minutes) RTO for directory writes. We also maintain zero Recovery Point Objective (RPO) and will
not lose data on failovers.
Data centers
Azure AD’s replicas are stored in datacenters located throughout the world. For more information, see Azure
datacenters.
Azure AD operates across data centers with the following characteristics:
Authentication, Graph and other AD services reside behind the Gateway service. The Gateway manages load
balancing of these services. It will failover automatically if any unhealthy servers are detected using transactional
health probes. Based on these health probes, the Gateway dynamically routes traffic to healthy data centers.
For reads, the directory has secondary replicas and corresponding front-end services in an active-active
configuration operating in multiple data centers. In case of a failure of an entire data center, traffic will be
automatically routed to a different datacenter.
For writes, the directory will failover primary (master) replica across data centers via planned (new primary is
synchronized to old primary) or emergency failover procedures. Data durability is achieved by replicating any
commit to at least two data centers.
Data consistency
The directory model is one of eventual consistency. One typical problem with distributed asynchronously
replicating systems is that the data returned from a “particular” replica may not be up to date.
Azure AD provides read-write consistency for applications targeting a secondary replica by routing its writes to the
primary replica, and synchronously pulling the writes back to the secondary replica.
Application writes using the Graph API of Azure AD are abstracted from maintaining affinity to a directory replica
for read-write consistency. The Azure AD Graph service maintains a logical session, which has affinity to a
secondary replica used for reads; affinity is captured in a “replica token” that the graph service caches using a
distributed cache. This token is then used for subsequent operations in the same logical session.
NOTE
Writes are immediately replicated to the secondary replica to which the logical session's reads were issued.
Backup protection
The directory implements soft deletes, instead of hard deletes, for users and tenants for easy recovery in case of
accidental deletes by a customer. If your tenant administrator accidently deletes users, they can easily undo and
restore the deleted users.
Azure AD implements daily backups of all data, and therefore can authoritatively restore data in case of any logical
deletions or corruptions. Our data tier employs error correcting codes, so that it can check for errors and
automatically correct particular types of disk errors.
Metrics and monitors
Running a high availability service requires world-class metrics and monitoring capabilities. Azure AD continually
analyzes and reports key service health metrics and success criteria for each of its services. We continuously
develop and tune metrics, monitoring and alerting for each scenario, within each Azure AD service and across all
services.
If any Azure AD service is not working as expected, we immediately take action to restore functionality as quickly as
possible. The most important metric Azure AD tracks is how quickly we can detect and mitigate a customer or live
site issue. We invest heavily in monitoring and alerts to minimize time to detect (TTD Target: <5 minutes) and
operational readiness to minimize time to mitigate (TTM Target: <30 minutes).
Secure operations
We employ operational controls such as multi-factor authentication (MFA) for any operation, as well as auditing of
all operations. In addition, we use a just-in-time elevation system to grant necessary temporary access for any
operational task-on-demand on an ongoing basis. For more information, see The Trusted Cloud.
Next steps
Azure Active Directory developer's guide
Claims mapping in Azure Active Directory (public
preview)
NOTE
This feature replaces and supersedes the claims customization offered through the portal today. If you customize claims using
the portal in addition to the Graph/PowerShell method detailed in this document on the same application, tokens issued for
that application will ignore the configuration in the portal. Configurations made through the methods detailed in this
document will not be reflected in the portal.
This feature is used by tenant admins to customize the claims emitted in tokens for a specific application in their
tenant. You can use claims mapping policies to:
Select which claims are included in tokens.
Create claim types that do not already exist.
Choose or change the source of data emitted in specific claims.
NOTE
This capability currently is in public preview. Be prepared to revert or remove any changes. The feature is available in any
Azure Active Directory (Azure AD) subscription during public preview. However, when the feature becomes generally available,
some aspects of the feature might require an Azure Active Directory premium subscription.
Claims mapping policy type

In Azure AD, a Policy object represents a set of rules enforced on individual applications, or on all applications in
an organization. Each type of policy has a unique structure, with a set of properties that are then applied to objects
to which they are assigned.
A claims mapping policy is a type of Policy object that modifies the claims emitted in tokens issued for specific
applications.
Claim sets
There are certain sets of claims that define how and when they are used in tokens.
Core claim set
Claims in the core claim set are present in every token, regardless of policy. These claims are also considered
restricted, and cannot be modified.
Basic claim set
The basic claim set includes the claims that are emitted by default for tokens (in addition to the core claim set).
These claims can be omitted or modified by using the claims mapping policies.
Restricted claim set
Restricted claims cannot be modified by using policy. The data source cannot be changed, and no transformation is
applied when generating these claims.
Table 1: JSON Web Token (JW T) restricted claim set
CLAIM TYPE (NAME)
_claim_names
_claim_sources
access_token
account_type
acr
actor
actortoken
aio
altsecid
amr
app_chain
app_displayname
app_res
appctx
appctxsender
appid
appidacr
assertion
at_hash
aud
auth_data
auth_time
authorization_code
azp
azpacr
CLAIM TYPE (NAME)
c_hash
ca_enf
cc
cert_token_use
client_id
cloud_graph_host_name
cloud_instance_name
cnf
code
controls
credential_keys
csr
csr_type
deviceid
dns_names
domain_dns_name
domain_netbios_name
e_exp
email
endpoint
enfpolids
exp
expires_on
grant_type
graph
CLAIM TYPE (NAME)
group_sids
groups
hasgroups
hash_alg
home_oid
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration
http://schemas.microsoft.com/ws/2008/06/identity/claims/expired
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
iat
identityprovider
idp
in_corp
instance
ipaddr
isbrowserhostedapp
iss
jwk
key_id
key_type
mam_compliance_url
mam_enrollment_url
CLAIM TYPE (NAME)
mam_terms_of_use_url
mdm_compliance_url
mdm_enrollment_url
mdm_terms_of_use_url
nameid
nbf
netbios_name
nonce
oid
on_prem_id
onprem_sam_account_name
onprem_sid
openid2_id
password
platf
polids
pop_jwk
preferred_username
previous_refresh_token
primary_sid
puid
pwd_exp
pwd_url
redirect_uri
refresh_token
CLAIM TYPE (NAME)
refreshtoken
request_nonce
resource
role
roles
scope
scp
sid
signature
signin_state
src1
src2
sub
tbid
tenant_display_name
tenant_region_scope
thumbnail_photo
tid
tokenAutologonEnabled
trustedfordelegation
unique_name
upn
user_setting_sync_url
username
uti
CLAIM TYPE (NAME)
ver
verified_primary_email
verified_secondary_email
wids
win_ver
Table 2: Security Assertion Markup Language (SAML) restricted claim set
CLAIM TYPE (URI)
http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration
http://schemas.microsoft.com/ws/2008/06/identity/claims/expired
http://schemas.microsoft.com/identity/claims/accesstoken
http://schemas.microsoft.com/identity/claims/openid2_id
http://schemas.microsoft.com/identity/claims/identityprovider
http://schemas.microsoft.com/identity/claims/objectidentifier
http://schemas.microsoft.com/identity/claims/puid
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier[MR1]
http://schemas.microsoft.com/identity/claims/tenantid
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
http://schemas.microsoft.com/claims/groups.link
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
http://schemas.microsoft.com/ws/2008/06/identity/claims/wids
http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
CLAIM TYPE (URI)
http://schemas.microsoft.com/2014/03/psso
http://schemas.microsoft.com/claims/authnmethodsreferences
http://schemas.xmlsoap.org/ws/2009/09/identity/claims/actor
http://schemas.microsoft.com/ws/2008/06/identity/claims/samlissuername
http://schemas.microsoft.com/ws/2008/06/identity/claims/confirmationkey
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/authorizationdecision
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/authentication
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/sid
http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarygroupsid
http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarysid
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/denyonlysid
http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlywindowsdevicegroup
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdeviceclaim
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsdevicegroup
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsfqbnversion
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowssubauthority
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsuserclaim
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/x500distinguishedname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn
http://schemas.microsoft.com/ws/2008/06/identity/claims/ispersistent
CLAIM TYPE (URI)
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
http://schemas.microsoft.com/identity/claims/scope
Claims mapping policy properties

Use the properties of a claims mapping policy to control which claims are emitted, and where the data is sourced
from. If no policy is set, the system issues tokens containing the core claim set, the basic claim set, and any optional
claims that the application has chosen to receive.
Include basic claim set
String: IncludeBasicClaimSet
Data type: Boolean (True or False)
Summary: This property determines whether the basic claim set is included in tokens affected by this policy.
If set to True, all claims in the basic claim set are emitted in tokens affected by the policy.
If set to False, claims in the basic claim set are not in the tokens, unless they are individually added in the claims
schema property of the same policy.
NOTE
Claims in the core claim set are present in every token, regardless of what this property is set to.
Claims schema
String: ClaimsSchema
Data type: JSON blob with one or more claim schema entries
Summary: This property defines which claims are present in the tokens affected by the policy, in addition to the
basic claim set and the core claim set. For each claim schema entry defined in this property, certain information is
required. You must specify where the data is coming from (Value or Source/ID pair), and which claim the data is
emitted as (Claim Type).
Claim schema entry elements
Value: The Value element defines a static value as the data to be emitted in the claim.
Source/ID pair: The Source and ID elements define where the data in the claim is sourced from.
The Source element must be set to one of the following:
"user": The data in the claim is a property on the User object.
"application": The data in the claim is a property on the application (client) service principal.
"resource": The data in the claim is a property on the resource service principal.
"audience": The data in the claim is a property on the service principal that is the audience of the token (either
the client or resource service principal).
“company”: The data in the claim is a property on the resource tenant’s Company object.
"transformation": The data in the claim is from claims transformation (see the "Claims transformation" section
later in this article).
If the source is transformation, the TransformationID element must be included in this claim definition as well.
The ID element identifies which property on the source provides the value for the claim. The following table lists the
values of ID valid for each value of Source.
Table 3: Valid ID values per source
SOURCE ID DESCRIPTION
User surname Family Name
User givenname Given Name
User displayname Display Name
User objectid ObjectID
User mail Email Address
User userprincipalname User Principal Name
User department Department
User onpremisessamaccountname On Premises Sam Account Name
User netbiosname NetBios Name
User dnsdomainname Dns Domain Name
User onpremisesecurityidentifier on-premises Security Identifier
User companyname Organization Name
User streetaddress Street Address
User postalcode Postal Code
User preferredlanguange Preferred Language
User onpremisesuserprincipalname on-premises UPN
User mailnickname Mail Nickname
User extensionattribute1 Extension Attribute 1

User othermail Other Mail
User country Country
User city City
User state State
User jobtitle Job Title
User employeeid Employee ID
User facsimiletelephonenumber Facsimile Telephone Number
application, resource, audience displayname Display Name
application, resource, audience objected ObjectID
application, resource, audience tags Service Principal Tag
Company tenantcountry Tenant’s country
TransformationID: The TransformationID element must be provided only if the Source element is set to
“transformation”.
This element must match the ID element of the transformation entry in the ClaimsTransformation property
that defines how the data for this claim is generated.
Claim Type: The JwtClaimType and SamlClaimType elements define which claim this claim schema entry refers
to.
The JwtClaimType must contain the name of the claim to be emitted in JWTs.
The SamlClaimType must contain the URI of the claim to be emitted in SAML tokens.
NOTE
Names and URIs of claims in the restricted claim set cannot be used for the claim type elements. For more information, see
the "Exceptions and restrictions" section later in this article.
Claims transformation
String: ClaimsTransformation
Data type: JSON blob, with one or more transformation entries
Summary: Use this property to apply common transformations to source data, to generate the output data for
claims specified in the Claims Schema.
ID: Use the ID element to reference this transformation entry in the TransformationID Claims Schema entry. This
value must be unique for each transformation entry within this policy.
TransformationMethod: The TransformationMethod element identifies which operation is performed to generate
the data for the claim.
Based on the method chosen, a set of inputs and outputs is expected. These are defined by using the InputClaims,
InputParameters and OutputClaims elements.
Table 4: Transformation methods and expected inputs and outputs
TRANSFORMATIONMETHOD EXPECTED INPUT EXPECTED OUTPUT DESCRIPTION
Join string1, string2, separator outputClaim Joins input strings by using a

separator in between. For
example:
string1:"foo@bar.com" ,
string2:"sandbox" ,
separator:"." results in
outputClaim:"foo@bar.com.s
andbox"
ExtractMailPrefix mail outputClaim Extracts the local part of an

email address. For example:
mail:"foo@bar.com" results
in outputClaim:"foo". If no @
sign is present, then the
orignal input string is
returned as is.
InputClaims: Use an InputClaims element to pass the data from a claim schema entry to a transformation. It has
two attributes: ClaimTypeReferenceId and TransformationClaimType.
ClaimTypeReferenceId is joined with ID element of the claim schema entry to find the appropriate input claim.
TransformationClaimType is used to give a unique name to this input. This name must match one of the
expected inputs for the transformation method.
InputParameters: Use an InputParameters element to pass a constant value to a transformation. It has two
attributes: Value and ID.
Value is the actual constant value to be passed.
ID is used to give a unique name to this input. This name must match one of the expected inputs for the
transformation method.
OutputClaims: Use an OutputClaims element to hold the data generated by a transformation, and tie it to a claim
schema entry. It has two attributes: ClaimTypeReferenceId and TransformationClaimType.
ClaimTypeReferenceId is joined with the ID of the claim schema entry to find the appropriate output claim.
TransformationClaimType is used to give a unique name to this output. This name must match one of the
expected outputs for the transformation method.
Exceptions and restrictions
SAML NameID and UPN: The attributes from which you source the NameID and UPN values, and the claims
transformations that are permitted, are limited.
Table 5: Attributes allowed as a data source for SAML NameID
User mail Email Address
User userprincipalname User Principal Name
User onpremisessamaccountname On Premises Sam Account Name
User employeeid Employee ID
Table 6: Transformation methods allowed for SAML NameID

TRANSFORMATIONMETHOD RESTRICTIONS
ExtractMailPrefix None
Join The suffix being joined must be a verified domain of the

resource tenant.
Custom signing key

A custom signing key must be assigned to the service principal object for a claims mapping policy to take effect. All
tokens issued that have been impacted by the policy are signed with this key. Applications must be configured to
accept tokens signed with this key. This ensures acknowledgment that tokens have been modified by the creator of
the claims mapping policy. This protects applications from claims mapping policies created by malicious actors.
Cross-tenant scenarios
Claims mapping policies do not apply to guest users. If a guest user attempts to access an application with a claims
mapping policy assigned to its service principal, the default token is issued (the policy has no effect).
Claims mapping policy assignment

Claims mapping policies can only be assigned to service principal objects.
Example claims mapping policies
In Azure AD, many scenarios are possible when you can customize claims emitted in tokens for specific service
principals. In this section, we walk through a few common scenarios that can help you grasp how to use the claims
mapping policy type.
Prerequisites
In the following examples, you create, update, link, and delete policies for service principals. If you are new to Azure
AD, we recommend that you learn about how to get an Azure AD tenant before you proceed with these examples.
To get started, do the following steps:
1. Download the latest Azure AD PowerShell Module public preview release.
2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you
start a new session.
Connect-AzureAD -Confirm
3. To see all policies that have been created in your organization, run the following command. We recommend
that you run this command after most operations in the following scenarios, to check that your policies are
being created as expected.
Get-AzureADPolicy
Example: Create and assign a policy to omit the basic claims from tokens issued to a service principal.
In this example, you create a policy that removes the basic claim set from tokens issued to linked service
principals.
4. Create a claims mapping policy. This policy, linked to specific service principals, removes the basic claim set
from tokens.
a. To create the policy, run this command:
New-AzureADPolicy -Definition @('{"ClaimsMappingPolicy":
{"Version":1,"IncludeBasicClaimSet":"false"}}') -DisplayName "OmitBasicClaims” -Type
"ClaimsMappingPolicy"
b. To see your new policy, and to get the policy ObjectId, run the following command:
Get-AzureADPolicy
5. Assign the policy to your service principal. You also need to get the ObjectId of your service principal.
a. To see all your organization's service principals, you can query Microsoft Graph. Or, in Azure AD Graph
Explorer, sign in to your Azure AD account.
b. When you have the ObjectId of your service principal, run the following command:
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId

of the Policy>
Example: Create and assign a policy to include the EmployeeID and TenantCountry as claims in tokens issued to a
service principal.
In this example, you create a policy that adds the EmployeeID and TenantCountry to tokens issued to
linked service principals. The EmployeeID is emitted as the name claim type in both SAML tokens and
JWTs. The TenantCountry is emitted as the country claim type in both SAML tokens and JWTs. In this
example, we continue to include the basic claims set in the tokens.
6. Create a claims mapping policy. This policy, linked to specific service principals, adds the EmployeeID and
TenantCountry claims to tokens.

{"Version":1,"IncludeBasicClaimSet":"true", "ClaimsSchema":
[{"Source":"user","ID":"employeeid","SamlClaimType":"http://schemas.xmlsoap.org/ws/2005/05/identi
ty/claims/name","JwtClaimType":"name"},{"Source":"company","ID":" tenantcountry
","SamlClaimType":" http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
","JwtClaimType":"country"}]}}') -DisplayName "ExtraClaimsExample” -Type "ClaimsMappingPolicy"
Get-AzureADPolicy

of the Policy>
Example: Create and assign a policy that uses a claims transformation in tokens issued to a service principal.
In this example, you create a policy that emits a custom claim “JoinedData” to JWTs issued to linked
service principals. This claim contains a value created by joining the data stored in the
extensionattribute1 attribute on the user object with “.sandbox”. In this example, we exclude the basic
claims set in the tokens.
8. Create a claims mapping policy. This policy, linked to specific service principals, adds the EmployeeID and
TenantCountry claims to tokens.

{"Version":1,"IncludeBasicClaimSet":"true", "ClaimsSchema":
[{"Source":"user","ID":"extensionattribute1"},
{"Source":"transformation","ID":"DataJoin","TransformationId":"JoinTheData","JwtClaimType":"Joine
dData"}],"ClaimsTransformations":
[{"ID":"JoinTheData","TransformationMethod":"Join","InputClaims":
[{"ClaimTypeReferenceId":"extensionattribute1","TransformationClaimType":"string1"}],
"InputParameters": [{"ID":"string2","Value":"sandbox"},
{"ID":"separator","Value":"."}],"OutputClaims":
[{"ClaimTypeReferenceId":"DataJoin","TransformationClaimType":"outputClaim"}]}]}}') -DisplayName
"TransformClaimsExample" -Type "ClaimsMappingPolicy"
Get-AzureADPolicy

of the Policy>
Azure Active Directory Hybrid Identity Design
Considerations
Consumer-based devices are proliferating the corporate world, and cloud-based software-as-a-service (SaaS)
applications are easy to adopt. As a result, maintaining control of users’ application access across internal
datacenters and cloud platforms is challenging.
Microsoft’s identity solutions span on-premises and cloud-based capabilities, creating a single user identity for
authentication and authorization to all resources, regardless of location. We call this Hybrid Identity. There are
different design and configuration options for hybrid identity using Microsoft solutions, and in some case it might
be difficult to determine which combination will best meet the needs of your organization.
This Hybrid Identity Design Considerations Guide will help you to understand how to design a hybrid identity
solution that best fits the business and technology needs for your organization. This guide details a series of steps
and tasks that you can follow to help you design a hybrid identity solution that meets your organization’s unique
requirements. Throughout the steps and tasks, the guide will present the relevant technologies and feature
options available to organizations to meet functional and service quality (such as availability, scalability,
performance, manageability, and security) level requirements.
Specifically, the hybrid identity design considerations guide goals are to answer the following questions:
What questions do I need to ask and answer to drive a hybrid identity-specific design for a technology or
problem domain that best meets my requirements?
What sequence of activities should I complete to design a hybrid identity solution for the technology or
problem domain?
What hybrid identity technology and configuration options are available to help me meet my requirements?
What are the trade-offs between those options so that I can select the best option for my business?
Who is this guide intended for?

CIO, CITO, Chief Identity Architects, Enterprise Architects and IT Architects responsible for designing a hybrid
identity solution for medium or large organizations.
How can this guide help you?

You can use this guide to understand how to design a hybrid identity solution that is able to integrate a cloud
based identity management system with your current on-premises identity solution.
The following graphic shows an example a hybrid identity solution that enables IT Admins to manage to integrate
their current Windows Server Active Directory solution located on-premises with Microsoft Azure Active Directory
to enable users to use Single Sign-On (SSO) across applications located in the cloud and on-premises.
The above illustration is an example of a hybrid identity solution that is leveraging cloud services to integrate with
on-premises capabilities in order to provide a single experience to the end user authentication process and to
facilitate IT managing those resources. Although this can be a very common scenario, every organization’s hybrid
identity design is likely to be different than the example illustrated in Figure 1 due to different requirements.
This guide provides a series of steps and tasks that you can follow to design a hybrid identity solution that meets
your organization’s unique requirements. Throughout the following steps and tasks, the guide presents the
relevant technologies and feature options available to you to meet functional and service quality level
requirements for your organization.
Assumptions: You have some experience with Windows Server, Active Directory Domain Services and Azure
Active Directory. In this document, we assume you are looking for how these solutions can meet your business
needs on their own or in an integrated solution.
Design considerations overview

This document provides a set of steps and tasks that you can follow to design a hybrid identity solution that best
meets your requirements. The steps are presented in an ordered sequence. Design considerations you learn in
later steps may require you to change decisions you made in earlier steps, however, due to conflicting design
choices. Every attempt is made to alert you to potential design conflicts throughout the document.
You will arrive at the design that best meets your requirements only after iterating through the steps as many
times as necessary to incorporate all of the considerations within the document.
HYBRID IDENTITY PHASE TOPIC LIST
Determine identity requirements Determine business needs

Determine directory synchronization requirements
Determine multi-factor authentication requirements
Define a hybrid identity adoption strategy
Plan for enhancing data security through strong identity Determine data protection requirements
solution Determine content management requirements
Determine access control requirements
Determine incident response requirements
Define data protection strategy
Plan for hybrid identity lifecycle Determine hybrid identity management tasks
Synchronization Management
Determine hybrid identity management adoption strategy
Download this guide

You can download a pdf version of the Hybrid Identity Design Considerations guide from the Technet gallery.
Determine identity requirements for your hybrid
identity solution
The first step in designing a hybrid identity solution is to determine the requirements for the business organization
that will be leveraging this solution. Hybrid identity starts as a supporting role (it supports all other cloud solutions
by providing authentication) and goes on to provide new and interesting capabilities that unlock new workloads for
users. These workloads or services that you wish to adopt for your users will dictate the requirements for the
hybrid identity design. These services and workloads need to leverage hybrid identity both on-premises and in the
cloud.
You need to go over these key aspects of the business to understand what it is a requirement now and what the
company plans for the future. If you don’t have the visibility of the long term strategy for hybrid identity design,
chances are that your solution will not be scalable as the business needs grow and change. T he diagram below
shows an example of a hybrid identity architecture and the workloads that are being unlocked for users. This is just
an example of all the new possibilities that can be unlocked and delivered with a solid hybrid identity strategy.
Some components that are part of the hybrid identity architecture
Determine business needs

Each company will have different requirements, even if these companies are part of the same industry, the real
business requirements might vary. You can still leverage best practices from the industry, but ultimately it is the
company’s business needs that will lead you to define the requirements for the hybrid identity design.
Make sure to answer the following questions to identify your business needs:
Is your company looking to cut IT operational cost?
Is your company looking to secure cloud assets (SaaS apps, infrastructure)?
Is your company looking to modernize your IT?
Are your users more mobile and demanding IT to create exceptions into your DMZ to allow different type
of traffic to access different resources?
Does your company have legacy apps that needed to be published to these modern users but are not
easy to rewrite?
Does your company need to accomplish all these tasks and bring it under control at the same time?
Is your company looking to secure users’ identities and reduce risk by bringing new tools that leverage the
expertise of Microsoft’s Azure security expertise on-premises?
Is your company trying to get rid of the dreaded “external” accounts on premises and move them to the cloud
where they are no longer a dormant threat inside your on-premises environment?
Analyze on-premises identity infrastructure

Now that you have an idea regarding your company business requirements, you need to evaluate your on-
premises identity infrastructure. This evaluation is important for defining the technical requirements to integrate
your current identity solution to the cloud identity management system. Make sure to answer the following
questions:
What authentication and authorization solution does your company use on-premises?
Does your company currently have any on-premises synchronization services?
Does your company use any third-party Identity Providers (IdP)?
You also need to be aware of the cloud services that your company might have. Performing an assessment to
understand the current integration with SaaS, IaaS or PaaS models in your environment is very important. Make
sure to answer the following questions during this assessment:
Does your company have any integration with a cloud service provider?
If yes, which services are being used?
Is this integration currently in production or is it a pilot?
NOTE
If you don’t have an accurate mapping of all your apps and cloud services, you can use the Cloud App Discovery tool. This
tool can provide your IT department with visibility into all your organization’s business and consumer cloud apps. That makes
it easier than ever to discover shadow IT in your organization, including details on usage patterns and any users accessing
your cloud applications. To get started see Cloud app discovery.
Evaluate identity integration requirements

Next, you need to evaluate the identity integration requirements. This evaluation is important to define the
technical requirements for how users will authenticate, how the organization’s presence will look in the cloud, how
the organization will allow authorization and what the user experience is going to be. Make sure to answer the
following questions:
Will your organization be using federation, standard authentication or both?
Is federation a requirement? Because of the following:
Kerberos-based SSO
Your company has an on-premises applications (either built in-house or 3rd party) that uses SAML or
similar federation capabilities.
MFA via Smart Cards. RSA SecurID, etc.
Client access rules that address the questions below:
1. Can I block all external access to Office 365 based on the IP address of the client?
2. Can I block all external access to Office 365, except Exchange ActiveSync?
3. Can I block all external access to Office 365, except for browser-based apps (OWA, SPO)
4. Can I block all external access to Office 365 for members of designated AD groups
Security/auditing concerns
Already existing investment in federated authentication
What name will our organization use for our domain in the cloud?
Does the organization have a custom domain?
1. Is that domain public and easily verifiable via DNS?
2. If it is not, then do you have a public domain that can be used to register an alternate UPN in AD?
Are the user identifiers consistent for cloud representation?
Does the organization have apps that require integration with cloud services?
Does the organization have multiple domains and will they all use standard or federated authentication?
Evaluate applications that run in your environment

Now that you have an idea regarding your on-premises and cloud infrastructure, you need to evaluate the
applications that run in these environments. This evaluation is important to define the technical requirements to
integrate these applications to the cloud identity management system. Make sure to answer the following
questions:
Where will our applications live?
Will users be accessing on-premises applications? In the cloud? Or both?
Are there plans to take the existing application workloads and move them to the cloud?
Are there plans to develop new applications that will reside either on-premises or in the cloud that will use
cloud authentication?
Evaluate user requirements

You also have to evaluate the user requirements. This evaluation is important to define the steps that will be
needed for on-boarding and assisting users as they transition to the cloud. Make sure to answer the following
questions:
Will users be accessing applications on-premises?
Will users be accessing applications in the cloud?
How do users typically login to their on-premises environment?
How will users sign-in to the cloud?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Determine incident response
requirements will go over the options available and pros/cons of each option. By having answered those questions you will
select which option best suits your business needs.
Next steps
See also
Synchronization is all about providing users an identity in the cloud based on their on-premises identity. Whether
or not they will use synchronized account for authentication or federated authentication, the users will still need to
have an identity in the cloud. This identity will need to be maintained and updated periodically. The updates can
take many forms, from title changes to password changes.
Start by evaluating the organizations on-premises identity solution and user requirements. This evaluation is
important to define the technical requirements for how user identities will be created and maintained in the cloud.
For a majority of organizations, Active Directory is on-premises and will be the on-premises directory that users
will by synchronized from, however in some cases this will not be the case.
Make sure to answer the following questions:
Do you have one AD forest, multiple, or none?
How many Azure AD directories will you be synchronizing to?
1. Are you using filtering?
2. Do you have multiple Azure AD Connect servers planned?
Do you currently have a synchronization tool on-premises?
If yes, does your users if users have a virtual directory/integration of identities?
Do you have any other directory on-premises that you want to synchronize (e.g. LDAP Directory, HR database,
etc)?
Are you going to be doing any GALSync?
What is the current state of UPNs in your organization?
Do you have a different directory that users authenticate against?
Does your company use Microsoft Exchange?
Do they plan of having a hybrid exchange deployment?
Now that you have an idea about your synchronization requirements, you need to determine which tool is the
correct one to meet these requirements. Microsoft provides several tools to accomplish directory integration and
synchronization. See the Hybrid Identity directory integration tools comparison table for more information.
Now that you have your synchronization requirements and the tool that will accomplish this for your company,
you need to evaluate the applications that use these directory services. This evaluation is important to define the
technical requirements to integrate these applications to the cloud. Make sure to answer the following questions:
Will these applications be moved to the cloud and use the directory?
Are there special attributes that need to be synchronized to the cloud so these applications can use them
successfully?
Will these applications need to be re-written to take advantage of cloud auth?
Will these applications continue to live on-premises while users access them using the cloud identity?
You also need to determine the security requirements and constraints directory synchronization. This evaluation is
important to get a list of the requirements that will be needed in order to create and maintain user’s identities in
the cloud. Make sure to answer the following questions:
Where will the synchronization server be located?
Will it be domain joined?
Will the server be located on a restricted network behind a firewall, such as a DMZ?
Will you be able to open the required firewall ports to support synchronization?
Do you have a disaster recovery plan for the synchronization server?
Do you have an account with the correct permissions for all forests you want to synch with?
If your company doesn’t know the answer for this question, review the section “Permissions for
password synchronization” in the article Install the Azure Active Directory Sync Service and determine if
you already have an account with these permissions or if you need to create one.
If you have mutli-forest sync is the sync server able to get to each forest?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Determine incident response
requirements will go over the options available. By having answered those questions you will select which option best suits
your business needs.
Next steps
See also
for your hybrid identity solution
In this world of mobility, with users accessing data and applications in the cloud and from any device, securing this
information has become paramount. Every day there is a new headline about a security breach. Although, there is
no guarantee against such breaches, multi-factor authentication, provides an additional layer of security to help
prevent these breaches. Start by evaluating the organizations requirements for multi-factor authentication. That is,
what is the organization trying to secure. This evaluation is important to define the technical requirements for
setting up and enabling the organizations users for multi-factor authentication.
NOTE
If you are not familiar with MFA and what it does, it is strongly recommended that you read the article What is Azure Multi-
Factor Authentication? prior to continue reading this section.
Make sure to answer the following:

Is your company trying to secure Microsoft apps?
How these apps are published?
Does your company provide remote access to allow employees to access on-premises apps?
If yes, what type of remote access?You also need to evaluate where the users who are accessing these applications
will be located. This evaluation is another important step to define the proper multi-factor authentication strategy.
Make sure to answer the following questions:
Where are the users going to be located?
Can they be located anywhere?
Does your company want to establish restrictions according to the user’s location?
Once you understand these requirements, it is important to also evaluate the user’s requirements for multi-factor
authentication. This evaluation is important because it will define the requirements for rolling out multi-factor
authentication. Make sure to answer the following questions:
Are the users familiar with multi-factor authentication?
Will some uses be required to provide additional authentication?
If yes, all the time, when coming from external networks, or accessing specific applications, or under
other conditions?
Will the users require training on how to setup and implement multi-factor authentication?
What are the key scenarios that your company wants to enable multi-factor authentication for their users?
After answering the previous questions, you will be able to understand if there are multi-factor authentication
already implemented on-premises. This evaluation is important to define the technical requirements for setting up
and enabling the organizations users for multi-factor authentication. Make sure to answer the following questions:
Does your company need to protect privileged accounts with MFA?
Does your company need to enable MFA for certain application for compliance reasons?
Does your company need to enable MFA for all eligible users of these application or only administrators?
Do you need have MFA always enabled or only when the users are logged outside of your corporate network?
Next steps
See also
Determine hybrid identity lifecycle adoption strategy
In this task, you’ll define the identity management strategy for your hybrid identity solution to meet the business
requirements that you defined in Determine hybrid identity management tasks.
To define the hybrid identity management tasks according to the end-to-end identity lifecycle presented earlier in
this step, you will have to consider the options available for each lifecycle phase.
Access management and provisioning

With a good account access management solution, your organization can track precisely who has access to what
information across the organization.
Access control is a critical function of a centralized, single-point provisioning system. Besides protecting sensitive
information, access controls expose existing accounts that have unapproved authorizations or are no longer
necessary. To control obsolete accounts, the provisioning system links together account information with
authoritative information about the users who own the accounts. Authoritative user identity information is typically
maintained in the databases and directories of human resources.
Accounts in sophisticated IT enterprises include hundreds of parameters that define the authorities, and these
details can be controlled by your provisioning system. New users can be identified with the data that you provide
from the authoritative source. The access request approval capability initiates the processes that approve (or reject)
resource provisioning for them.
LIFECYCLE MANAGEMENT
PHASE ON PREMISES CLOUD HYBRID
LIFECYCLE MANAGEMENT
PHASE ON PREMISES CLOUD HYBRID
Account Management and By using the Active You have to create an Extend Active Directory
Provisioning Directory® Domain Services account for every user who identities into the cloud
(AD DS) server role, you can will access a Microsoft cloud through synchronization and
create a scalable, secure, and service. You can also change federation
manageable infrastructure user accounts or delete
for user and resource them when they’re no
management, and provide longer needed. By default,
support for directory- users do not have
enabled applications such as administrator permissions,
Microsoft® Exchange Server. but you can optionally
assign them. For more
You can provision groups in information, see Managing
AD DS through an Identity Users in Azure AD.
manager
You can provision users in Within Azure Active
AD DS Directory, one of the major
features is the ability to
Administrators can use manage access to resources.
access control to manage These resources can be part
user access to shared of the directory, as in the
resources for security case of permissions to
purposes. In Active manage objects through
Directory, access control is roles in the directory, or
administered at the object resources that are external
level by setting different to the directory, such as
levels of access, or SaaS applications, Azure
permissions, to objects, such services, and SharePoint
as Full Control, Write, Read, sites or on-premises
or No Access. Access control resources.
in Active Directory defines
how different users can use At the center of Azure Active
Active Directory objects. By Directory’s access
default, permissions on management solution is the
objects in Active Directory security group. The resource
are set to the most secure owner (or the administrator
setting. of the directory) can assign a
group to provide a certain
access right to the resources
they own. The members of
the group will be provided
the access, and the resource
owner can delegate the right
to manage the members list
of a group to someone else
– such as a department
manager or a helpdesk
administrator
The Managing groups in

Azure AD topic provides
more information on
managing access through
groups.
Role-based access control

Role-based access control (RBAC) uses roles and provisioning policies to evaluate, test, and enforce your business
processes and rules for granting access to users. Key administrators create provisioning policies and assign users
to roles and that define sets of entitlements to resources for these roles. RBAC extends the identity management
solution to use software-based processes and reduce user manual interaction in the provisioning process. Azure
AD RBAC enables the company to restrict the amount of operations that an individual can do once he has access to
Azure Management Portal. By using RBAC to control access to the portal, IT Admins ca delegate access by using the
following access management approaches:
Group-based role assignment: You can assign access to Azure AD groups that can be synced from your local
Active Directory. This enables you to leverage the existing investments that your organization has made in
tooling and processes for managing groups. You can also use the delegated group management feature of
Azure AD Premium.
Leverage built in roles in Azure: You can use three roles — Owner, Contributor, and Reader, to ensure that
users and groups have permission to do only the tasks they need to do their jobs.
Granular access to resources: You can assign roles to users and groups for a particular subscription, resource
group, or an individual Azure resource such as a website or database. In this way, you can ensure that users
have access to all the resources they need and no access to resources that they do not need to manage.
Provisioning and other customization options

Your team can use business plans and requirements to decide how much to customize the identity solution. For
example, a large enterprise might require a phased roll-out plan for workflows and custom adapters that is based
on a time line for incrementally provisioning applications that are widely used across geographies. Another
customization plan might provide for two or more applications to be provisioned across an entire organization,
after successful testing. User-application interaction can be customized, and procedures for provisioning resources
might be changed to accommodate automated provisioning.
You can deprovision to remove a service or component. For example, deprovisioning an account means that the
account is deleted from a resource.
The hybrid model of provisioning resources combines request and role-based approaches, which are both
supported by Azure AD. For a subset of employees or managed systems, a business might want to automate access
with role-based assignment. A business might also handle all other access requests or exceptions through a
request-based model. Some businesses might start with manual assignment, and evolve toward a hybrid model,
with an intention of a fully role-based deployment at a future time.
Other companies might find it impractical for business reasons to achieve complete role-based provisioning, and
target a hybrid approach as a wanted goal. Still other companies might be satisfied with only request-based
provisioning, and not want to invest additional effort to define and manage role-based, automated provisioning
policies.
License management
Group-based license management in Azure AD lets administrators assign users to a security group and Azure AD
automatically assigns licenses to all the members of the group. If a user is subsequently added to, or removed from
the group, a license will be automatically assigned or removed as appropriate.
You can use groups you synchronize from on-premises AD or manage in Azure AD. Pairing this up with Azure AD
premium Self-Service Group Management you can easily delegate license assignment to the appropriate decision
makers. You can be assured that problems like license conflicts and missing location data are automatically sorted
out.
Self-regulating user administration

When your organization starts to provision resources across all internal organizations, you implement the self-
regulating user administration capability. You can realize the advantages and benefits of provisioning users across
organizational boundaries. In this environment, a change in a user's status is automatically reflected in access rights
across organization boundaries and geographies. You can reduce provisioning costs and streamline the access and
approval processes. The implementation realizes the full potential of implementing role-based access control for
end-to-end access management in your organization. You can reduce administrative costs through automated
procedures for governing user provisioning. You can improve security by automating security policy enforcement,
and streamline and centralize user lifecycle management and resource provisioning for large user populations.
NOTE
For more information, see Setting up Azure AD for self service application access management
License-based (Entitlement-based) Azure AD services work by activating a subscription in your Azure AD

directory/service tenant. Once the subscription is active the service capabilities can be managed by
directory/service administrators and used by licensed users. For more information, see How does Azure AD
licensing work? Integration with other 3rd party providers
Azure Active Directory provides single-sign on and enhanced application access security to thousands of SaaS
applications and on-premises web applications. For a detailed list of Azure Active Directory application gallery for
supported SaaS applications, see Azure Active Directory federation compatibility list: third-party identity providers
that can be used to implement single sign-on
Define synchronization management

Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. With this integration users and
organizations can take advantage of the following:
Organizations can provide users with a common hybrid identity across on-premises or cloud-based services
leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
Administrators can provide conditional access based on application resource, device and user identity, network
location and multi-factor authentication.
Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and
third-party applications.
Developers can build applications that leverage the common identity model, integrating applications into Active
Directory on-premises or Azure for cloud-based applications
The following figure has an example of a high-level view of identity synchronization process.
Identity synchronization process

Review the following table to compare the synchronization options:
SYNCHRONIZATION MANAGEMENT
OPTION ADVANTAGES DISADVANTAGES
Sync-based (through DirSync or Users,and groups synchronized from

AADConnect) on-premises and cloud
Policy control: Account policies can be
set through Active Directory, which
gives the administrator the ability to
manage password policies,
workstation,restrictions, lock-out
controls, and more, without having to
perform additional tasks in the cloud.
Access control: Can restrict access to
the cloud service so that,the services
can be accessed through the corporate
environment, through online servers, or
both.
Reduced support calls: If users have
fewer passwords to remember, they are
less likely to forget them.
Security: User identities and information
are protected because all of the servers
and services used in single sign-on,are
mastered and controlled on-premises.
Support for strong authentication: You
can use strong authentication (also
called two-factor authentication) with
the cloud service. However, if you use
strong authentication, you must use
single sign-on.
Federation-based (through AD FS) Enabled by Security Token Service (STS). Requires specialized personnel for
When you configure an STS to provide deployment and maintenance of
single sign-on access with a Microsoft dedicated on-prem AD FS servers. There
cloud service, you will be creating a are restrictions on the use of strong
federated trust between your on- authentication if you plan to use AD FS
premises STS and the federated domain for your STS. For more information, see
you’ve specified in your Azure AD Configuring Advanced Options for AD
tenant. FS 2.0.
Allows end users to use the same set of
credentials to obtain access to multiple
resources
end users do not have to maintain
multiple sets of credentials. Yet, the
users have to provide their credentials
to each one of the participating
resources.,B2B and B2C scenarios
supported.
NOTE
For more information see, Integrating your on-premises identities with Azure Active Directory.
See Also
Define data protection strategy for your hybrid
identity solution
In this task, you’ll define the data protection strategy for your hybrid identity solution to meet the business
requirements that you defined in:
Determine data protection requirements
Determine content management requirements
Define data protection options

As explained in Determine directory synchronization requirements, Microsoft Azure AD can synchronize with your
on-premises Active Directory Domain Services (AD DS). This integration lets organizations use Azure AD to verify
users' credentials when they are trying to access corporate resources. You can do this for both scenarios: data at
rest on-premises and in the cloud. Access to data in Azure AD requires user authentication via a security token
service (STS).
Once authenticated, the user principal name (UPN) is read from the authentication token. Then, the authorization
system determines the replicated partition and container corresponding to the user’s domain. Information on the
user’s existence, enabled state, and role then helps the authorization system determine whether access to the
target tenant is authorized for the user in that session. Certain authorized actions (specifically, create user and
password reset) create an audit trail that a tenant administrator then uses to manage compliance efforts or
investigations.
Moving data from your on-premises datacenter into Azure Storage over an Internet connection may not always be
feasible due to data volume, bandwidth availability, or other considerations. The Azure Storage Import/Export
Service provides a hardware-based option for placing/retrieving large volumes of data in blob storage. It allows
you to send BitLocker-encrypted hard disk drives directly to an Azure datacenter where cloud operators upload the
contents to your storage account, or they can download your Azure data to your drives to return to you. Only
encrypted disks are accepted for this process (using a BitLocker key generated by the service itself during the job
setup). The BitLocker key is provided to Azure separately, thus providing out of band key sharing.
Since data in transit can take place in different scenarios, is also relevant to know that Microsoft Azure uses virtual
networking to isolate tenants’ traffic from one another, employing measures such as host- and guest-level
firewalls, IP packet filtering, port blocking, and HTTPS endpoints. However, most of Azure’s internal
communications, including infrastructure-to-infrastructure and infrastructure-to-customer (on-premises), are also
encrypted. Another important scenario is the communications within Azure datacenters; Microsoft manages
networks to assure that no VM can impersonate or eavesdrop on the IP address of another. TLS/SSL is used when
accessing Azure Storage or SQL Databases, or when connecting to Cloud Services. In this case, the customer
administrator is responsible for obtaining a TLS/SSL certificate and deploying it to their tenant infrastructure. Data
traffic moving between Virtual Machines in the same deployment or between tenants in a single deployment via
Microsoft Azure Virtual Network can be protected through encrypted communication protocols such as HTTPS,
SSL/TLS, or others.
Depending on how you answered the questions in Determine data protection requirements, you should be able to
determine how you want to protect your data and how the hybrid identity solution can assist you with that
process. The following table shows the options supported by Azure that are available for each data protection
scenario.
DATA PROTECTION OPTIONS AT REST IN THE CLOUD AT REST ON-PREMISES IN TRANSIT
BitLocker Drive Encryption X X
SQL Server to encrypt X X

databases
VM-to-VM Encryption X
SSL/TLS X
VPN X
NOTE
Read Compliance by Feature at Microsoft Azure Trust Center to know more about the certifications that each Azure service
is compliant with. Since the options for data protection use a multilayer approach, comparison between those options are
not applicable for this task. Ensure that you are leveraging all options available for each state of the data.
Define content management options

One advantage of using Azure AD to manage a hybrid identity infrastructure is that the process is fully transparent
from the end user’s perspective. The user tries to access a shared resource, the resource requires authentication,
the user has to send an authentication request to Azure AD in order to obtain the token and access the resource.
This entire process happens in the background, without user interaction. It is also possible to grant permission to a
group of users in order to allow them to perform certain common actions.
Organizations that are concern about data privacy usually require data classification for their solution. If their
current on-premises infrastructure is already using data classification, it is possible to use Azure AD as the main
repository for the user’s identity. A common tool that it is used on-premises for data classification is called Data
Classification Toolkit for Windows Server 2012 R2. This tool can help to identify, classify, and protect data on file
servers in your private cloud. It is also possible to use the Automatic File Classification in Windows Server 2012 to
accomplish this task.
If your organization doesn’t have data classification in place but needs to protect sensitive files without adding new
Servers on-premises, they can use Microsoft Azure Rights Management Service. Azure RMS uses encryption,
identity, and authorization policies to help secure your files and email, and it works across multiple devices—
phones, tablets, and PCs. Because Azure RMS is a cloud service, there’s no need to explicitly configure trusts with
other organizations before you can share protected content with them. If they already have an Office 365 or an
Azure AD directory, collaboration across organizations is automatically supported. You can also synchronize just
the directory attributes that Azure RMS needs to support a common identity for your on-premises Active Directory
accounts, by using Azure Active Directory Synchronization Services (AAD Sync) or Azure AD Connect.
A vital part of content management is to understand who is accessing which resource, therefore a rich logging
capability is important for the identity management solution. Azure AD provides log over 30 days including:
Changes in role membership (ex: user added to Global Admin role)
Credential updates (ex: password changes)
Domain management (ex: verifying a custom domain, removing a domain)
Adding or removing applications
User management (ex: adding, removing, updating a user)
Adding or removing licenses
NOTE
Read Microsoft Azure Security and Audit Log Management to know more about logging capabilities in Azure. Depending on
how you answered the questions in Determine content management requirements, you should be able to determine how
you want the content to be managed in your hybrid identity solution. While all options exposed in Table 6 are capable of
integrating with Azure AD, it is important to define which is more appropriate for your business needs.
CONTENT MANAGEMENT OPTIONS ADVANTAGES DISADVANTAGES
Centralized on-premises (Active Full control over the server Higher maintenance (keep up with
Directory Rights Management Server) infrastructure responsible for classifying updates, configuration and potential
the data upgrades), since IT owns the Server
Built-in capability in Windows Server, Require a server infrastructure on-
no need for extra license or subscription premises
Can be integrated with Azure AD in a Doesn’t leverage Azure capabilities
hybrid scenario natively
Supports information rights
management (IRM) capabilities in
Microsoft Online services such as
Exchange Online and SharePoint
Online, as well as Office 365
Supports on-premises Microsoft server
products, such as Exchange Server,
SharePoint Server, and file servers that
run Windows Server and File
Classification Infrastructure (FCI).
Centralized in the cloud (Azure RMS) Easier to manage compared to the on- Your organization must have a cloud
premises solution subscription that supports RMS
Can be integrated with AD DS in a Your organization must have an Azure
hybrid scenario AD directory to support user
Fully integrated with Azure AD authentication for RMS
Doesn’t require a server on-premises in
order to deploy the service
Supports on-premises Microsoft server
products such as Exchange Server,
SharePoint, Server, and file servers that
run Windows Server and File
Classification, Infrastructure (FCI)
IT, can have complete control over their
tenant’s key with BYOK capability.
Hybrid (Azure RMS integrated with, This scenario accumulates the Your organization must have a cloud
On-Premises Active Directory Rights advantages of both, centralized on- subscription that supports RMS
Management Server) premises and in the cloud. Your organization must have an Azure
AD directory to support user
authentication for RMS,
Requires a connection between Azure
cloud service and on-premises
infrastructure
Define access control options

By leveraging the authentication, authorization and access control capabilities available in Azure AD you can
enable your company to use a central identity repository while allowing users and partners to use single sign-on
(SSO) as shown in the following figure:
Centralized management and fully integration with other directories
Azure Active Directory provides single sign-on to thousands of SaaS applications and on-premises web
applications. See the Azure Active Directory federation compatibility list: third-party identity providers that can be
used to implement single sign-on article for more details about the SSO third-party that were tested by Microsoft.
This capability enables organization to implement a variety of B2B scenarios while keeping control of the identity
and access management. However, during the B2B designing process, is important to understand the
authentication method that is used by the partner and validate if this method is supported by Azure. Currently, the
following methods are supported by Azure AD:
Security Assertion Markup Language (SAML)
OAuth
Kerberos
Tokens
Certificates
NOTE
read Azure Active Directory Authentication Protocols to know more details about each protocol and its capabilities in Azure.
Using the Azure AD support, mobile business applications can use the same easy Mobile Services authentication
experience to allow employees to sign into their mobile applications with their corporate Active Directory
credentials. With this feature, Azure AD is supported as an identity provider in Mobile Services alongside the other
identity providers already supported (which include Microsoft Accounts, Facebook ID, Google ID, and Twitter ID). If
the on-premises apps use the user’s credential located at the company’s AD DS, the access from partners and
users coming from the cloud should be transparent. You can manage user’s conditional access control to (cloud-
based) web applications, web API, Microsoft cloud services, third-party SaaS applications, and native (mobile) client
applications, and have the benefits of security, auditing, reporting all in one place. However, it is recommended to
validate the implementation in a non-production environment or with a limited number of users.
TIP
it is important to mention that Azure AD does not have Group Policy as AD DS has. In order to enforce policy for devices,
you need a mobile device management solution such as Microsoft Intune.
Once the user is authenticated using Azure AD, it is important to evaluate the level of access that the user has. The
level of access that the user has over a resource can vary. While Azure AD can add an additional security layer by
controlling access to some resources, keep in mind that the resource itself can also have its own access control list
separately, such as the access control for files located in a File Server. The following figure summarizes the levels
of access control that you can have in a hybrid scenario:
Each interaction in the diagram showed in Figure X represents one access control scenario that can be covered by
Azure AD. Below you have a description of each scenario:
1. Conditional Access to applications that are hosted on-premises: You can use registered devices with access
policies for applications that are configured to use AD FS with Windows Server 2012 R2. For more
information about setting up conditional access for on-premises, see Setting up On-premises Conditional
Access using Azure Active Directory Device Registration.
2. Access Control to the Azure portal: Azure also lets you control access to the portal by using role-based
access control (RBAC)). This method enables the company to restrict the number of operations that an
individual can do in the Azure portal. By using RBAC to control access to the portal, IT Admins can delegate
access by using the following access management approaches:
Group-based role assignment: You can assign access to Azure AD groups that can be synced from your
local Active Directory. This lets you leverage the existing investments that your organization has made in
tooling and processes for managing groups. You can also use the delegated group management feature
of Azure AD Premium.
Use built-in roles in Azure: You can use three roles — Owner, Contributor, and Reader, to ensure that
users and groups have permission to do only the tasks they need to do their jobs.
Granular access to resources: You can assign roles to users and groups for a particular subscription,
resource group, or an individual Azure resource such as a website or database. In this way, you can
ensure that users have access to all the resources they need and no access to resources that they do not
need to manage.
NOTE
If you are building applications and want to customize the access control for them, it is also possible to use Azure AD
Application Roles for authorization. Review this WebApp-RoleClaims-DotNet example on how to build your app to use this
capability.
1. Conditional Access for Office 365 applications with Microsoft Intune: IT admins can provision conditional
access device policies to secure corporate resources, while at the same time allowing information workers
on compliant devices to access the services. For more information, see Conditional Access Device Policies
for Office 365 services.
2. Conditional Access for Saas apps: This feature allows you to configure per-application multi-factor
authentication access rules and the ability to block access for users not on a trusted network. You can apply
the multi-factor authentication rules to all users that are assigned to the application, or only for users within
specified security groups. Users may be excluded from the multi-factor authentication requirement if they
are accessing the application from an IP address that in inside the organization’s network.
Since the options for access control use a multilayer approach, comparison between those options are not
applicable for this task. Ensure that you are leveraging all options available for each scenario that requires you to
control access to your resources.
Define incident response options

Azure AD can assist IT to identity potential security risks in the environment by monitoring user’s activity. IT can
use Azure AD Access and Usage reports to gain visibility into the integrity and security of your organization’s
directory. With this information, an IT admin can better determine where possible security risks may lie so that
they can adequately plan to mitigate those risks. Azure AD Premium subscription has a set of security reports that
can enable IT to obtain this information. Azure AD reports are categorized as follows:
Anomaly reports: Contain sign-in events that were found to be anomalous. The goal is to make you aware of
such activity and enable you to make a determination about whether an event is suspicious.
Integrated Application report: Provides insights into how cloud applications are being used in your
organization. Azure Active Directory offers integration with thousands of cloud applications.
Error reports: Indicate errors that may occur when provisioning accounts to external applications.
User-specific reports: Display device/sign in activity data for a specific user.
Activity logs: Contain a record of all audited events within the last 24 hours, last 7 days, or last 30 days, as well
as group activity changes, and password reset and registration activity.
TIP
Another report that can also help the Incident Response team working on a case is the user with leaked credentials report.
This report surfaces any matches between the leaked credentials list and your tenant.
Other important built-in reports in Azure AD that can be used during an incident response investigation and are:
Password reset activity: provide the admin with insights into how actively password reset is being used in the
organization.
Password reset registration activity: provides insights into which users have registered their methods for
password reset, and which methods they have selected.
Group activity: provides a history of changes to the group (ex: users added or removed) that were initiated in
the Access Panel.
In addition to the core reporting capability of Azure AD Premium that you can use during an Incident Response
investigation process, IT can also take advantage of the Audit Report to obtain information such as:
Changes in role membership (for example, user added to Global Admin role)
Credential updates (for example, password changes)
Domain management (for example, verifying a custom domain, removing a domain)
Adding or removing applications
User management (for example, adding, removing, updating a user)
Adding or removing licenses
Since the options for incident response use a multilayer approach, comparison between those options is not
applicable for this task. Ensure that you are leveraging all options available for each scenario that requires you to
use Azure AD reporting capability as part of your company’s incident response process.
Next steps
Determine hybrid identity management tasks
See Also
Plan for enhancing data security through strong
identity solution
The first step to protect the data is identify who can access that data and as part of this process you need to have
an identity solution that can integrates with your system to provide authentication and authorization capabilities.
Authentication and authorization are often confused with each other and their roles misunderstood. In reality they
are quite different, as shown in the figure below:
Mobile device management lifecycle stages

When planning your hybrid identity solution you must understand the data protection requirements for your
business and which options are available to best fulfil these requirements.
NOTE
Once you finish planning for data security, review Determine multi-factor authentication requirements to ensure that your
selections regarding multi-factor authentication requirements were not affected by the decisions you made in this section.

In the age of mobility, most companies have a common goal: enable their users to be productive on their mobile
devices while on-premises or remotely from anywhere in order to increase productivity. While this could be a
common goal, companies that have such requirement will also be concern regarding the amount of threats that
must be mitigated in order to keep company’s data secure and maintain user’s privacy. Each company might have
different requirements in this regard; different compliance rules that will vary according to which industry the
company is acting will lead to different design decisions.
However, there are some security aspects that should be explored and validated, regardless of the industry, which
are explained in the next section.
Data protection paths

Data protection paths
In the above diagram, the identity component will be the first one to be verified before data is accessed. However,
this data can be in different states during the time it was accessed. Each number on this diagram represents a path
in which data can be located at some point in time. These numbers are explained below:
1. Data protection at the device level.
2. Data protection while in transit.
3. Data protection while at rest on-premises.
4. Data protection while at rest in the cloud.
Although the technical controls that will enable IT to protect the data itself on each one of those phases are not
directly offered by the hybrid identity solution, it is necessary that the hybrid identity solution is capable of
leveraging both on-premises and cloud identity management resources to identify the user before grant access to
the data. When planning your hybrid identity solution ensure that the following questions are answered according
to your organization’s requirements:
Data protection at rest

Regardless of where the data is at rest (device, cloud or on-premises), it is important to perform an assessment to
understand the organization needs in this regard. For this area, ensure that the following questions are asked:
Does your company need to protect data at rest?
If yes, is the hybrid identity solution able to integrate with your current on-premises infrastructure?
If yes, is the hybrid identity solution able to integrate with your workloads located in the cloud?
Is the cloud identity management able to protect the user’s credentials and other data stored in the cloud?
Data protection in transit

Data in transit between the device and the datacenter or between the device and the cloud must be protected.
However, being in-transit does not necessarily mean a communications process with a component outside of your
cloud service; it moves internally, also, such as between two virtual networks. For this area, ensure that the
following questions are asked:
Does your company need to protect data in transit?
If yes, is the hybrid identity solution able to integrate with secure controls such as SSL/TLS?
Does the cloud identity management keep the traffic to and within the directory store (within and between
datacenters) signed?
Compliance
Regulations, laws and regulatory compliance requirements will vary according to the industry that your company
belongs. Companies in high regulated industries must address identity-management concerns related to
compliance issues. Regulations such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability
Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA) and the Payment Card Industry Data Security Standard (PCI DSS)
are very strict regarding identity and access. The hybrid identity solution that your company will adopt must have
the core capabilities that will fulfill the requirements of one or more of these regulations. For this area, ensure that
the following questions are asked:
Is the hybrid identity solution compliant with the regulatory requirements for your business?
Does the hybrid identity solution has built in capabilities that will enable your company to be compliant
regulatory requirements?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Define Data Protection Strategy
will go over the options available and advantages/disadvantages of each option. By having answered those questions you
will select which option best suits your business needs.
Next steps
Determine content management requirements
See Also
Determine content management requirements for
your hybrid identity solution
Understanding the content management requirements for your business may direct affect your decision on which
hybrid identity solution to use. With the proliferation of multiple devices and the capability of users to bring their
own devices (BYOD), the company must protect its own data but it also must keep user’s privacy intact. Usually
when a user has his own device he might have also multiple credentials that will be alternating according to the
application that he uses. It is important to differentiate what content was created using personal credentials versus
the ones created using corporate credentials. Your identity solution should be able to interact with cloud services
to provide a seamless experience to the end user while ensure his privacy and increase the protection against data
leakage.
Your identity solution will be leveraged by different technical controls in order to provide content management as
shown in the figure below:
Security controls that will be leveraging your identity management system

In general, content management requirements will leverage your identity management system in the following
areas:
Privacy: identifying the user that owns a resource and applying the appropriate controls to maintain integrity.
Data Classification: identify the user or group and level of access to an object according to its classification.
Data Leakage Protection: security controls responsible for protecting data to avoid leakage will need to interact
with the identity system to validate the user’s identity. This is also important for auditing trail purpose.
NOTE
Read data classification for cloud readiness for more information about best practices and guidelines for data classification.
When planning your hybrid identity solution ensure that the following questions are answered according to your
organization’s requirements:
Does your company have security controls in place to enforce data privacy?
If yes, will those security controls be able to integrate with the hybrid identity solution that you are going
to adopt?
Does your company use data classification?
If yes, is the current solution able to integrate with the hybrid identity solution that you are going to
adopt?
Does your company currently have any solution for data leakage?
If yes, is the current solution able to integrate with the hybrid identity solution that you are going to
adopt?
Does your company need to audit access to resources?
If yes, what type of resources?
If yes, what level of information is necessary?
If yes, where the audit log must reside? On-premises or in the cloud?
Does your company need to encrypt any emails that contain sensitive data (SSNs, credit card numbers, etc)?
Does your company need to encrypt all documents/contents shared with external business partners?
Does your company need to enforce corporate policies on certain kinds of emails (do no reply all, do not
forward)?
NOTE
Next steps
See Also
Determine access control requirements for your
hybrid identity solution
When an organization is designing their hybrid identity solution they can also use this opportunity to review
access requirements for the resources that they are planning to make it available for users. The data access cross
all four pillars of identity, which are:
Administration
Authentication
Authorization
Auditing
The sections that follows will cover authentication and authorization in more details, administration and auditing
are part of the hybrid identity lifecycle. Read Determine hybrid identity management tasks for more information
about these capabilities.
NOTE
Read The Four Pillars of Identity - Identity Management in the Age of Hybrid IT for more information about each one of
those pillars.
Authentication and authorization

There are different scenarios for authentication and authorization, these scenarios will have specific requirements
that must be fulfilled by the hybrid identity solution that the company is going to adopt. Scenarios involving
Business to Business (B2B) communication can add an extra challenge for IT Admins since they will need to ensure
that the authentication and authorization method used by the organization can communicate with their business
partners. During the designing process for authentication and authorization requirements, ensure that the
following questions are answered:
Will your organization authenticate and authorize only users located at their identity management system?
Are there any plans for B2B scenarios?
If yes, do you already know which protocols (SAML, OAuth, Kerberos, Tokens or Certificates) will be used
to connect both businesses?
Does the hybrid identity solution that you are going to adopt support those protocols?
Another important point to consider is where the authentication repository that will be used by users and partners
will be located and the administrative model to be used. Consider the following two core options:
Centralized: in this model the user’s credentials, policies and administration can be centralized on-premises or
in the cloud.
Hybrid: in this model the user’s credentials, policies and administration will be centralized on-premises and a
replicated in the cloud.
Which model your organization will adopt will vary according to their business requirements, you want to answer
the following questions to identify where the identity management system will reside and the administrative mode
to use:
Does your organization currently have an identity management on-premises?
If yes, do they plan to keep it?
Are there any regulation or compliance requirements that your organization must follow that dictates
where the identity management system should reside?
Does your organization use single sign-on for apps located on-premises or in the cloud?
If yes, does the adoption of a hybrid identity model affect this process?
Access Control
While authentication and authorization are core elements to enable access to corporate data through user’s
validation, it is also important to control the level of access that these users will have and the level of access
administrators will have over the resources that they are managing. Your hybrid identity solution must be able to
provide granular access to resources, delegation and role base access control. Ensure that the following question
are answered regarding access control:
Does your company have more than one user with elevated privilege to manage your identity system?
If yes, does each user need the same access level?
Would your company need to delegate access to users to manage specific resources?
If yes, how frequently this happens?
Would your company need to integrate access control capabilities between on-premises and cloud resources?
Would your company need to limit access to resources according to some conditions?
Would your company have any application that needs custom control access to some resources?
If yes, where are those apps located (on-premises or in the cloud)?
If yes, where are those target resources located (on-premises or in the cloud)?
NOTE
will go over the options available and advantages/disadvantages of each option. By answering those questions you will select
which option best suits your business needs.
Next steps
See Also
Determine incident response requirements for your
hybrid identity solution
Large or medium organizations most likely will have a security incident response in place to help IT take actions
accordingly to the level of incident. The identity management system is an important component in the incident
response process because it can be used to help identifying who performed a specific action against the target.
The hybrid identity solution must be able to provide monitoring and reporting capabilities that can be leveraged
by IT to take actions to identify and mitigate a potential threat. In a typical incident response plan you will have the
following phases as part of the plan:
1. Initial assessment.
2. Incident communication.
3. Damage control and risk reduction.
4. Identification of what it was compromise and severity.
5. Evidence preservation.
6. Notification to appropriate parties.
7. System recovery.
8. Documentation.
9. Damage and cost assessment.
10. Process and plan revision.
During the identification of what it was compromise and severity- phase, it will be necessary to identify the
systems that have been compromised, files that have been accessed and determine the sensitivity of those files.
Your hybrid identity system should be able to fulfill these requirements to assist you identifying the user that
made those changes.
Monitoring and reporting

Many times the identity system can also help in initial assessment phase mainly if the system has built in auditing
and reporting capabilities. During the initial assessment, IT Admin must be able to identify a suspicious activity, or
the system should be able to trigger it automatically based on a pre-configured task. Many activities could indicate
a possible attack, however in other cases, a badly configured system might lead to a number of false positives in
an intrusion detection system.
The identity management system should assist IT admins to identify and report those suspicious activities. Usually
these technical requirements can be fulfilled by monitoring all systems and having a reporting capability that can
highlight potential threats. Use the questions below to help you design your hybrid identity solution while taking
into consideration incident response requirements:
Does your company has a security incident response in place?
If yes, is the current identity management system used as part of the process?
Does your company need to identify suspicious sign-on attempts from users across different devices?
Does your company need to detect potential compromised user’s credentials?
Does your company need to audit user’s access and action?
Does your company need to know when a user reset his password?
Policy enforcement
During damage control and risk reduction-phase, it is important to quickly reduce the actual and potential effects
of an attack. That action that you will take at this point can make the difference between a minor and a major one.
The exact response will depend on your organization and the nature of the attack that you face. If the initial
assessment concluded that an account was compromised, you will need to enforce policy to block this account.
That’s just one example where the identity management system will be leveraged. Use the questions below to help
you design your hybrid identity solution while taking into consideration how policies will be enforced to react to
an ongoing incident:
Does your company have policies in place to block users from access the network if necessary?
If yes, does the current solution integrate with the hybrid identity management system that you are
going to adopt?
Does your company need to enforce conditional access for users that are in quarantine?
NOTE
Make sure to take notes of each answer and understand the rationale behind the answer. Define data protection strategy
Next steps
Define data protection strategy
See Also
Plan for Hybrid Identity Lifecycle
Identity is one of the foundations of your enterprise mobility and application access strategy. Whether you are
signing on to your mobile device or SaaS app, your identity is the key to gaining access to everything. At its
highest level, an identity management solution encompasses unifying and syncing between your identity
repositories which includes automating and centralizing the process of provisioning resources. The identity
solution should be a centralized identity across on-premises and cloud and also use some form of identity
federation to maintain centralized authentication and securely share and collaborate with external users and
businesses. Resources range from operating systems and applications to people in, or affiliated with, an
organization. Organizational structure can be altered to accommodate the provisioning policies and procedures.
It is also important to have an identity solution geared to empower your users by providing them with self-service
experiences to keep them productive. Your identity solution is more robust if it enables single sign-on for users
across all the resources they need access Administrators at all levels can use standardized procedures for
managing user credentials. Some levels of administration can be reduced or eliminated, depending on the breadth
of the provisioning management solution. Furthermore, you can securely distribute administration capabilities,
manually or automatically, among various organizations. For example, a domain administrator can serve only the
people and resources in that domain. This user can do administrative and provisioning tasks, but is not authorized
to do configuration tasks, such as creating workflows.
Determine Hybrid Identity Management Tasks

Distributing administrative tasks in your organization improves the accuracy and effectiveness of administration
and improves the balance of the workload of an organization. Following are the pivots that define a robust identity
management system.
To define hybrid identity management tasks, you must understand some essential characteristics of the
organization that will be adopting hybrid identity. It is important to understand the current repositories being used
for identity sources. By knowing those core elements, you will have the foundational requirements and based on
that you will need to ask more granular questions that will lead you to a better design decision for your Identity
solution.
While defining those requirements, ensure that at least the following questions are answered
Provisioning options:
Does the hybrid identity solution support a robust account access management and provisioning
system?
How are users, groups, and passwords going to be managed?
Is the identity lifecycle management responsive?
How long does password updates account suspension take?
License management:
Does the hybrid identity solution handles license management?
If yes, what capabilities are available?
Does the solution handle group-based license management?
- If yes, is it possible to assign a security group to it?

- If yes, will the cloud directory automatically assign licenses to all the members of the group?
- What happens if a user is subsequently added to, or removed from the group, will a license be
automatically assigned or removed as appropriate?
Integration with other third-party identity providers:

Can this hybrid solution be integrated with third-party identity providers to implement single sign-on?
Is it possible to unify all the different identity providers into a cohesive identity system?
If yes, how and which are they and what capabilities are available?
Synchronization Management
One of the goals of an identity manager, to be able to bring all the identity providers and keep them synchronized.
You keep the data synchronized based on an authoritative master identity provider. In a hybrid identity scenario,
with a synchronized management model, you manage all user and device identities in an on-premises server and
synchronize the accounts and, optionally, passwords to the cloud. The user enters the same password on-premises
as he or she does in the cloud, and at sign-in, the password is verified by the identity solution. This model uses a
directory synchronization tool.
To proper design the

synchronization of your hybrid identity solution ensure that the following questions are answered: • What are the
sync solutions available for the hybrid identity solution? • What are the single sign on capabilities available? •
What are the options for identity federation between B2B and B2C?
Next steps
Determine hybrid identity management adoption strategy
See Also
In this task, you’ll define the hybrid identity adoption strategy for your hybrid identity solution to meet the business
requirements that were discussed in :
Determine business needs
Define business needs strategy

The first task addresses determining the organizations business needs. This can be very broad and scope creep can
occur if you are not careful. In the beginning keep it simple but always remember to plan for a design that will
accommodate and facilitate change in the future. Regardless of whether it is a simple design or an extremely
complex one, Azure Active Directory is the Microsoft Identity platform that supports Office 365, Microsoft Online
Services and cloud aware applications.
Define an integration strategy

Microsoft has three main integration scenarios which are cloud identities, synchronized identities, and federated
identities. You should plan on adopting one of these integration strategies. The strategy you choose can vary and
the decisions in choosing one may include, what type of user experience you want to provide, do you have some of
the existing infrastructure already in-place, and what is the most cost effective.
The scenarios defined in the above figure are:

Cloud identities: these are identities that exist solely in the cloud. In the case of Azure AD, they would reside
specifically in your Azure AD directory.
Synchronized: these are identities that exist on-premises and in the cloud. Using Azure AD Connect, these
users are either created or joined with existing Azure AD accounts. The user’s password hash is synchronized
from the on-premises environment to the cloud in what is called a password hash. When using synchronized
the one caveat is that if a user is disabled in the on-premises environment, it can take up to 3 hours for that
account status to show up in Azure AD. This is due to the synchronization time interval.
Federated: these identities exist both on-premises and in the cloud. Using Azure AD Connect, these users are
either created or joined with existing Azure AD accounts.
NOTE
For more information about the Synchronization options read Integrating your on-premises identities with Azure Active
Directory.
The following table will help in determining the advantages and disadvantages of each of the following strategies:
STRATEGY ADVANTAGES DISADVANTAGES
Cloud identities Easier to manage for small organization. Users will need to sign-in when
Nothing to install on-premises- No accessing workloads in the cloud
additional hardware needed Passwords may or may not be the same
Easily disabled if the user leaves the for cloud and on-premises identities
company
Synchronized On-premises password will authenticate Some customers may be reluctant to

both on-premises and cloud directories synchronize their directories with the
Easier to manage for small, medium or cloud due specific company’s police
large organizations
Users can have single sign-on (SSO) for
some resources
Microsoft preferred method for
synchronization
Easier to manage
Federated Users can have single sign-on (SSO) More steps to setup and configure
If a user is terminated or leaves, the Higher maintenance
account can,be immediately disabled May require additional hardware for the
and access revoked, STS infrastructure
Supports advanced scenarios that May require additional hardware to
cannot be,accomplished with install the federation server.Additional
synchronized software is required if AD FS is used
Require extensive setup for SSO
Critical point of failure if the federation
server is down, users won’t be able to
authenticate
Client experience
The strategy that you use will dictate the user sign-in experience. The following tables provide you with information
on what the users should expect their sign-in experience to be. Note that not all federated identity providers
support SSO in all scenarios.
Doman-joined and private network applications:
SYNCHRONIZED IDENTITY FEDERATED IDENTITY
Web Browsers Forms based authentication single sign on, sometimes required to
supply organization ID
Outlook Prompt for credentials Prompt for credentials
Skype for Business (Lync) Prompt for credentials single-sign on for Lync, prompted
credentials for Exchange
Skydrive Pro Prompt for credentials single sign on

Office Pro Plus Subscription Prompt for credentials single sign on
External or untrusted sources:
Web Browsers Forms based authentication Forms based authentication
Outlook, Skype for Business (Lync), Prompt for credentials Prompt for credentials
Skydrive Pro, Office subscription
Exchange ActiveSync Prompt for credentials single-sign on for Lync, prompted

credentials for Exchange
Mobile apps Prompt for credentials Prompt for credentials
If you have determined from task 1 that you have a 3rd party IdP or are going to use one to provide federation
with Azure AD, you need to be aware of the following supported capabilities:
Any SAML 2.0 provider which is compliant for the SP-Lite profile can support authentication to Azure AD and
associated applications
Supports passive authentication, which facilitates auth to OWA, SPO, etc.
Exchange Online clients can be supported via the SAML 2.0 Enhanced Client Profile (ECP)
You must also be aware of what capabilities will not be available:
Without WS-Trust/Federation support, all other active clients will break
That means no Lync client, OneDrive client, Office Subscription, Office Mobile prior to Office 2016
Transition of Office to passive authentication will allow them to support pure SAML 2.0 IdPs, but support will
still be on a client-by-client basis
NOTE
For the most updated list read the article http://aka.ms/ssoproviders.
Define synchronization strategy

In this task you will define the tools that will be used to synchronize the organization’s on-premises data to the
cloud and what topology you should use. Because, most organizations use Active Directory, information on using
Azure AD Connect to address the questions above is provided in some detail. For environments that do not have
Active Directory, there is information about using FIM 2010 R2 or MIM 2016 to help plan this strategy. However,
future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information
may be able to assist.
Synchronization tools
Over the years, several synchronization tools have existed and used for various scenarios. Currently Azure AD
Connect is the go to tool of choice for all supported scenarios. AAD Sync and DirSync are also still around and may
even be present in your environment now.
NOTE
For the latest information regarding the supported capabilities of each tool, read Directory integration tools comparison
article.
Supported topologies
When defining a synchronization strategy, the topology that is used must be determined. Depending on the
information that was determined in step 2 you can determine which topology is the proper one to use. The single
forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single
instance of Azure AD. This is going to be used in a majority of the scenarios and is the expected topology when
using Azure AD Connect Express installation as shown in the figure below.
Single
Forest Scenario It is very common for large and even small organizations to have multiple forests, as shown in
Figure 5.
NOTE
For more information about the different on-premises and Azure AD topologies with Azure AD Connect sync read the article
Topologies for Azure AD Connect.
Multi-Forest Scenario
If this the case then the multi-forest-single Azure AD topology should be considered if the following items are true:
Users have only 1 identity across all forests – the uniquely identifying users section below describes this in
more detail.
The user authenticates to the forest in which their identity is located
UPN and Source Anchor (immutable id) will come from this forest
All forests are accessible by Azure AD Connect – this means it does not need to be domain joined and can be
placed in a DMZ if this facilitates this.
Users have only one mailbox
The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global
Address List (GAL)
If there is no mailbox on the user, then any forest may be used to contribute these values
If you have a linked mailbox, then there is also another account in a different forest used to sign in.
NOTE
Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. In the context of Directory
Synchronization, this unique identifier is referred to as the SourceAnchor. In the context of Single Sign-On, this is referred to
as the ImmutableId. Design concepts for Azure AD Connect for more considerations regarding the use of SourceAnchor.
If the above are not true and you have more than one active account or more than one mailbox, Azure AD Connect
will pick one and ignore the other. If you have linked mailboxes but no other account, these accounts will not be
exported to Azure AD and that user will not be a member of any groups. This is different from how it was in the
past with DirSync and is intentional to better support these multi-forest scenarios. A multi-forest scenario is shown
in the figure below.
Multi-forest multiple Azure AD scenario

It is recommended to have just a single directory in Azure AD for an organization but it is supported it a 1:1
relationship is kept between an Azure AD Connect sync server and an Azure AD directory. For each instance of
Azure AD, you will need an installation of Azure AD Connect. Also, Azure AD, by design is isolated and users in one
instance of Azure AD will not be able to see users in another instance.
It is possible and supported to connect one on-premises instance of Active Directory to multiple Azure AD
directories as shown in the figure below:
Single-forest filtering scenario
In order to do this the following must be true:
Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of
objects. This done, for example, by scoping each server to a particular domain or OU.
A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-
premises AD must use separate namespaces
Users in one instance of Azure AD will only be able to see users from their instance. They will not be able to see
users in the other instances
Only one of the Azure AD directories can enable Exchange hybrid with the on-premises AD
Mutual exclusivity also applies to write-back. This makes some write-back features not supported with this
topology since these assume a single on-premises configuration. This includes:
Group write-back with default configuration
Device write-back
Be aware that the following is not supported and should not be chosen as an implementation:
It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory
even if they are configured to synchronize mutually exclusive set of object
It is unsupported to sync the same user to multiple Azure AD directories.
It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in
another Azure AD directory.
It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.
Azure AD directories are by design isolated. It is unsupported to change the configuration of Azure AD Connect
sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between
the directories. It is also unsupported to export users as contacts to another on-premises AD using Azure AD
Connect sync.
NOTE
If your organization restricts computers on your network from connecting to the Internet, this article lists the endpoints
(FQDNs, IPv4, and IPv6 address ranges) that you should include in your outbound allow lists and Internet Explorer Trusted
Sites Zone of client computers to ensure your computers can successfully use Office 365. For more information read Office
365 URLs and IP address ranges.
Define multi-factor authentication strategy

In this task you will define the multi-factor authentication strategy to use. Azure Multi-Factor Authentication comes
in two different version. One is a cloud-based and the other is on-premises based using the Azure MFA Server.
Based on the evaluation you did above you can determine which solution is the correct one for your strategy. Use
the table below to determine which design option best fulfill your company’s security requirement:
Multi-factor design options:
ASSET TO SECURE MFA IN THE CLOUD MFA ON-PREMISES
Microsoft apps yes yes
SaaS apps in the app gallery yes yes
IIS applications published through yes yes

Azure AD App Proxy
IIS applications not published through no yes

the Azure AD App Proxy
Remote access as VPN, RDG no yes
Even though you may have settled on a solution for your strategy, you still need to use the evaluation from above
on where your users are located. This may cause the solution to change. Use the table below to assist you
determining this:
USER LOCATION PREFERRED DESIGN OPTION
Azure Active Directory Multi-FactorAuthentication in the cloud
Azure AD and on-premises AD using federation with AD FS Both
Azure AD and on-premises AD using Azure AD Connect no Both

password sync
Azure AD and on-premises using Azure AD Connect with Both

password sync
On-premises AD Multi-Factor Authentication Server
NOTE
You should also ensure that the multi-factor authentication design option that you selected supports the features that are
required for your design. For more information read Choose the multi-factor security solution for you.
Multi-Factor Auth Provider
Multi-factor authentication is available by default for global administrators who have a Azure Active Directory
tenant. However, if you wish to extend multi-factor authentication to all of your users and/or want to your global
administrators to be able to take advantage features such as the management portal, custom greetings, and
reports, then you must purchase and configure Multi-Factor Authentication Provider.
NOTE
You should also ensure that the multi-factor authentication design option that you selected supports the features that are
required for your design.
Next steps
See also
Azure Active Directory hybrid identity design
considerations- next steps
Now that you’ve completed defining your requirements and examining all the options for your mobile device
management solution, you’re ready to take the next steps for deploying the supporting infrastructure that’s right
for you and your organization.
Hybrid identity solutions

-Leveraging specific solution scenarios that fit your needs is a great way to review and plan for the details of
deploying a mobile device management infrastructure. The following solutions outline several of the most common
mobile device management scenarios:
The manage mobile devices and PCs in enterprise environments solution helps you manage mobile devices by
extending your on-premises System Center 2012 Configuration Manager infrastructure into the cloud with
Microsoft Intune. This hybrid infrastructure helps IT Pros in medium and large environments enable BYOD and
remote access while reducing administrative complexity.
The managing mobile devices for Configuration Manager 2007 solution helps you manage mobile devices when
your infrastructure rests on a System Center Configuration Manager 2007. This solution shows you how to set
up a single server running System Center 2012 Configuration Manager so you can then run Microsoft Intune
and take advantage of its MDM ability.
The managing mobile devices in small environments solution is intended for small businesses that need to
support MDM. It explains how to use Microsoft Intune to extend your current infrastructure to support mobile
device management and BYOD. This solution describes the simplest scenario supported for using Microsoft
Intune in a standalone, cloud-only configuration with no local servers.
Hybrid identity documentation

Conceptual and procedural planning, deployment, and administration content are useful when implementing your
mobile device management solution:
Microsoft System Center solutions can help you capture and aggregate knowledge about your infrastructure,
policies, processes, and best practices so that your IT staff can build manageable systems and automate
operations.
Microsoft Intune is a cloud-based device management service that helps you to manage your computers and
mobile devices and to secure your company’s information.
MDM for Office 365 allows you to manage and secure mobile devices when they're connected to your Office
365 organization. You can use MDM for Office 365 to set device security policies and access rules, and to wipe
mobile devices if they’re lost or stolen.
Hybrid identity resources

Monitoring the following resources often provides the latest news and updates on mobile device management
solutions:
Microsoft Enterprise Mobility blog
Microsoft In The Cloud blog
Microsoft Intune blog
Microsoft System Center Configuration Manager blog
Microsoft System Center Configuration Manager Team blog
See also
Hybrid Identity directory integration tools
comparison
Over the years the directory integration tools have grown and evolved. This document is to help provide a
consolidated view of these tools and a comparison of the features that are available in each.
NOTE
Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools
are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so
that you always know where to get the most current functionality.
DirSync and Azure AD Sync are deprecated. More information can be found in here.
Use the following key for each of the tables.

● = Available Now
FR = Future Release
PP = Public Preview
On-Premises to Cloud Synchronization

AZURE ACTIVE
DIRECTORY AZURE ACTIVE FOREFRONT MICROSOFT
AZURE ACTIVE SYNCHRONIZATIO DIRECTORY IDENTITY IDENTITY
DIRECTORY N SERVICES (AAD SYNCHRONIZATIO MANAGER 2010 R2 MANAGER 2016
FEATURE CONNECT SYNC) N TOOL (DIRSYNC) (FIM) (MIM)
Connect to single ● ● ● ● ●
on-premises AD
forest
Connect to ● ● ● ●
multiple on-
premises AD
forests
Connect to ●
multiple on-
premises
Exchange Orgs
Connect to single ●* ● ●
on-premises
LDAP directory
Connect to ●* ● ●
multiple on-
premises LDAP
directories
AZURE ACTIVE
DIRECTORY AZURE ACTIVE FOREFRONT MICROSOFT
AZURE ACTIVE SYNCHRONIZATIO DIRECTORY IDENTITY IDENTITY
DIRECTORY N SERVICES (AAD SYNCHRONIZATIO MANAGER 2010 R2 MANAGER 2016
FEATURE CONNECT SYNC) N TOOL (DIRSYNC) (FIM) (MIM)
Connect to on- ●* ● ●
premises AD and
on-premises
LDAP directories
Connect to FR ● ●
custom systems
(i.e. SQL, Oracle,
MySQL, etc.)
Synchronize ●
customer defined
attributes
(directory
extensions)
Connect to on- FR ● ●
premises HR (i.e.,
SAP, Oracle
eBusiness,People
Soft)
Supports FIM ● ●
synchronization
rules and
connectors for
provisioning to
on-premises
systems.
* Currently there are two supported options for this. They are:
1. You can use the generic LDAP connector and enable it outside of Azure AD Connect. This is complex and
requires a partner for on-boarding and a premier support agreement to maintain. This option can handle both
single and multiple LDAP directories.
2. You can develop your own solution for moving objects from LDAP to Active Directory. Then synchronize the
objects with Azure AD Connect. MIM or FIM could be used as a possible solution for moving the objects.
Cloud to On-Premises Synchronization

AZURE ACTIVE AZURE ACTIVE FOREFRONT MICROSOFT
AZURE ACTIVE DIRECTORY DIRECTORY IDENTITY IDENTITY
DIRECTORY SYNCHRONIZATIO SYNCHRONIZATIO MANAGER 2010 R2 MANAGER 2016
FEATURE CONNECT N SERVICES N TOOL (DIRSYNC) (FIM) (MIM)
Writeback of ● ●
devices
Attribute ● ● ● ● ●
writeback (for
Exchange hybrid
deployment )
Writeback of ●
groups objects
passwords (from
self-service
password reset
(SSPR) and
password
change)
Authentication Feature Support

Password Sync ● ● ●
for single on-
premises AD
forest
Password Sync ● ●
for multiple on-
premises AD
forests
Single Sign-on ● ● ● ● ●
with Federation
passwords (from
SSPR and
password
change)
Set-up and Installation

AZURE ACTIVE AZURE ACTIVE
DIRECTORY DIRECTORY
AZURE ACTIVE SYNCHRONIZATION SYNCHRONIZATION MICROSOFT IDENTITY
FEATURE DIRECTORY CONNECT SERVICES TOOL (DIRSYNC) MANAGER 2016 (MIM)
Supports installation ● ● ●
on a Domain
Controller
Supports installation ● ● ●
using SQL Express
Easy upgrade from ●

DirSync
AZURE ACTIVE AZURE ACTIVE
DIRECTORY DIRECTORY
AZURE ACTIVE SYNCHRONIZATION SYNCHRONIZATION MICROSOFT IDENTITY
FEATURE DIRECTORY CONNECT SERVICES TOOL (DIRSYNC) MANAGER 2016 (MIM)
Localization of Admin ● ● ●
UX to Windows
Server languages
Localization of end ●
user UX to Windows
Server languages
Support for Windows ● for Sync, No for ● ● ●

Server 2008 and federation
Windows Server 2008
R2
Support for Windows ● ● ● ●

Server 2012 and
Windows Server 2012
R2
Filtering and Configuration

Filter on ● ● ● ● ●
Domains and
Organizational
Units
Filter on objects’ ● ● ● ● ●
attribute values
Allow minimal set ● ●

of attributes to
be synchronized
(MinSync)
Allow different ● ●
service templates
to be applied for
attribute flows
Allow removing ● ●
attributes from
flowing from AD
to Azure AD
Allow advanced ● ● ● ●
customization for
attribute flows
Next steps
Learn more about Integrating your on-premises identities with Azure Active Directory.
Quickstart: Add new users to Azure Active Directory
This article explains how to delete or add users in your organization into your orgnization's Azure Active Directory
(Azure AD) tenant using the Azure portal or by synchronizing your on-premises Windows Server AD user account
data.
Add cloud-based users

2. Select Azure Active Directory and then Users and groups.
3. On Users and groups, select All users, and then select New user.
4. Enter details for the user, such as Name and User name. The domain name portion of the user name must
either be the initial default domain name "[domain name].onmicrosoft.com" or a verified, non-federated
custom domain name such as "contoso.com."
5. Copy or otherwise note the generated user password so that you can provide it to the user after this process is
complete.
6. Optionally, you can open and fill out the information in Profile, Groups, or Directory role for the user. For
more information about user and administrator roles, see Assigning administrator roles in Azure AD.
7. On User, select Create.
8. Securely distribute the generated password to the new user so that the user can sign in.
TIP
You can also synchronize user account data from on-premises Windows Server AD. Microsoft’s identity solutions span on-
premises and cloud-based capabilities, creating a single user identity for authentication and authorization to all resources,
regardless of location. We call this Hybrid Identity. Azure AD Connect can be used to integrate your on-premises directories
with Azure Active Directory for hybrid identity scenarios. This allows you to provide a common identity for your users for
Office 365, Azure, and SaaS applications integrated with Azure AD.
Delete users from Azure AD
3. On the Users and groups blade, select the user to delete from the list.
4. On the blade for the selected user, select Overview, and then in the command bar, select Delete.
Learn more
Next steps
In this quickstart, you’ve learned how to add new users to Azure AD Premium.
You can use the following link to create a new user in Azure AD from the Azure portal.
Add or change profile information for a user in Azure
Active Directory
This article explains how to add user profile information, such as a profile picture or phone and email
authentication information, in Azure Active Directory (Azure AD). For information about adding new users in your
organization, see Add new users to Azure Active Directory.
To change profile information

1. Sign in to the Azure AD Admin Center with an account that's a global admin for the directory.
3. Select All users.

4. Select a user from the list.
5. For the selected user, select Profile.
6. Add or change the profile information. Then, in the command bar, select Save.
Next steps
Add new users to Azure Active Directory
Reset the password for a user in Azure Active Directory
Assign a user to administrator roles in Azure Active Directory
Delete a user from a directory in Azure Active Directory
Sharing accounts with Azure AD
Overview
Sometimes organizations need to use a single username and password for multiple people, which typically
happens in two cases:
When accessing applications that require a unique sign in and password for each user, whether on-premises
apps or consumer cloud services (for example, corporate social media accounts).
When creating multi-user environments. You might have a single, local account that has elevated privileges and
is used to do core setup, administration, and recovery activities. For example, the local "global administrator"
account for Office 365 or the root account in Salesforce.
Traditionally, these accounts are shared by distributing the credentials (username and password) to the right
individuals or storing them in a shared location where multiple trusted agents can access them.
The traditional sharing model has several drawbacks:
Enabling access to new applications requires you to distribute credentials to everyone that needs access.
Each shared application may require its own unique set of shared credentials, requiring users to remember
multiple sets of credentials. When users have to remember many credentials, the risk increases that they resort
to risky practices. (for example, writing down passwords).
You can't tell who has access to an application.
You can't tell who has accessed an application.
When you want to remove access to an application, you have to update the credentials and redistribute them to
everyone that needs access to that application.
Azure Active Directory account sharing

Azure AD provides a new approach to using shared accounts that eliminates these drawbacks.
The Azure AD administrator configures which applications a user can access by using the Access Panel and
choosing the type of single sign-on best suited for that application. One of those types, password-based single-sign
on, lets Azure AD act as a kind of "broker" during the sign-on process for that app.
Users log in once with their organizational account. This account is the same one they regularly use to access their
desktop or email. They can discover and access only those applications that they are assigned to. With shared
accounts, this list of applications can include any number of shared credentials. The end-user doesn't need to
remember or write down the various accounts they might be using.
Shared accounts not only increase oversight and improve usability, they also enhance your security. Users with
permissions to use the credentials don't see the shared password, but rather get permissions to use the password
as part of an orchestrated authentication flow. Further, some password SSO applications give you the option of
using Azure AD to periodically rollover (update) passwords. The system uses large, complex passwords, which
increases account security. The administrator can easily grant or revoke access to an application, knows who has
access to the account, and who has accessed it in the past.
Azure AD supports shared accounts for any Enterprise Mobility Suite (EMS), Premium, or Basic licensed users,
across all types of password single sign-on applications. You can share accounts for any of thousands of pre-
integrated applications in the application gallery and can add your own password-authenticating application with
custom SSO apps.
Azure AD features that enable account sharing include:
Password single sign-on
Password single sign-on agent
Group assignment
Custom Password apps
App usage dashboard/reports
End-user access portals
App proxy
Active Directory Marketplace
Sharing an account
To use Azure AD to share an account, you need to:
Add an application app gallery or custom application
Configure the application for password Single Sign-On (SSO)
Use group-based assignment and select the option to enter a shared credential
Optional: in some applications, such as Facebook, Twitter, or LinkedIn, you can enable the option for Azure AD
automated password roll-over
You can also make your shared account more secure with Multi-Factor Authentication (MFA) (learn more about
securing applications with Azure AD) and you can delegate the ability to manage who has access to the application
using Azure AD Self-service Group Management.
Related articles
Article Index for Application Management in Azure Active Directory
Protecting apps with conditional access
Self-service group management/SSAA
Assign a user to administrator roles in Azure Active
Directory
This article explains how to assign an administrative role to a user in Azure Active Directory (Azure AD). For
information about adding new users in your organization, see Add new users to Azure Active Directory. Added
users don't have administrator permissions by default, but you can assign roles to them at any time.
Assign a role to a user


5. For the selected user, select Directory role and then assign the user to a role from the Directory role list.
For more information about user and administrator roles, see Assigning administrator roles in Azure AD.
6. Select Save.
Next steps
Quickstart: Add or delete users in Azure Active Directory
Restore a deleted user in Azure Active Directory
This article contains instructions to restore or permanently delete a previously deleted user. When you delete a
user in the Azure Active Directory (Azure AD), the deleted user is retained for 30 days from the deletion date.
During that time, the user and its properties can be restored.
How to restore a recently deleted user

When a user is recently deleted, all directory information is preserved. If the user is restored, that information is
restored as well.
1. In the Azure AD admin center, select Users and groups > All users.
2. Under Show, filter the page to show Recently deleted users.
3. Select one or more recently deleted users.
4. Select Restore user.
How to permanently delete a recently deleted user

1. In the Azure AD admin center, select Users and groups > All users.
2. Under Show, filter the page to show Recently deleted users.
3. Select one or more recently deleted users.
4. Select Delete permanently.
Required permissions
The following permissions are sufficient to restore a user.
ROLE PERMISSIONS
Company Administrator Can restore deleted users

Partner Tier1 Support
User Account Administrator
Company Administrator Can permanently delete users

User Account Administrator
Next steps
These articles provide additional information on Azure Active Directory user management.
Quickstart: Add or delete users to Azure Active Directory
What is Azure AD B2B collaboration?
Azure AD business-to-business (B2B) collaboration capabilities enable any organization using Azure AD to
work safely and securely with users from any other organization, small or large. Those organizations can be
with Azure AD or without, or even with an IT organization or without.
Organizations using Azure AD can provide access to documents, resources, and applications to their partners,
while maintaining complete control over their own corporate data. Developers can use the Azure AD business-
to-business APIs to write applications that bring two organizations together in more securely. Also, it's pretty
easy for end users to navigate.
97% of our customers have told us Azure AD B2B collaboration is very important to them.
As of early April 2017, we had about 3 million users already using Azure AD B2B collaboration capabilities.
And more than 23% of Azure AD organizations that have more than 10 users are already benefiting from
these capabilities.
The key benefits of Azure AD B2B collaboration to your organization

Work with any user from any partner
Partners use their own credentials
No requirement for partners to use Azure AD
No external directories or complex set-up required
Simple and secure collaboration
Provide access to any corporate app or data, while applying sophisticated, Azure AD-powered
authorization policies
Easy for users
Enterprise-grade security for apps and data
No management overhead
No external account or password management
No sync or manual account lifecycle management
No external administrative overhead
You can easily add B2B collaboration users to your organization

Admins can add B2B collaboration (guest) users in the Azure portal.
Enable your collaborators to bring their own identity

B2B collaborators can sign in with an identity of their choice. If the user doesn’t have a Microsoft account or an
Azure AD account – one is created for them seamlessly at the time for offer redemption.
Delegate to application and group owners
Application and group owners can add B2B users directly to any application that you care about, whether it is a
Microsoft application or not. Admins can delegate permission to add B2B users to non-admins. Non-admins
can use the Azure AD Application Access Panel to add B2B collaboration users to applications or groups.
Authorization policies protect your corporate content
Conditional access policies, such as multi-factor authentication, can be enforced:
At the tenant level
At the application level
For specific users to protect corporate apps and data
Use our APIs and sample code to easily build applications to onboard
Bring your external partners on board in ways customized to your organization’s needs.
Using the B2B collaboration invitation APIs, you can customize your onboarding experiences, including
creating self-service sign-up portals. We provide sample code for a self-service portal on Github.
With Azure AD B2B collaboration, you can get the full power of Azure AD to protect your partner relationships
in a way that end users find easy and intuitive. So go ahead, join the thousands of organizations that are
already using Azure AD B2B for their external collaboration!
Next steps
Administrator experiences are found in the Azure portal.
Information worker experiences are available in the Access Panel.
And, as always, connect with the product team for any feedback, discussions, and suggestions through
our Microsoft Tech Community.
Browse our other articles on Azure AD B2B collaboration:
How do Azure Active Directory admins add B2B collaboration users?
How do information workers add B2B collaboration users?
The elements of the B2B collaboration invitation email
B2B collaboration invitation redemption
Troubleshooting Azure Active Directory B2B collaboration
Azure Active Directory B2B collaboration frequently asked questions (FAQ)
Azure Active Directory B2B collaboration API and customization
Multi-factor authentication for B2B collaboration users
Add B2B collaboration users without an invitation
B2B collaboration user auditing and reporting
How do Azure Active Directory admins add B2B
collaboration users?
Global Admins and limited admins can use the Azure portal to invite B2B collaboration users to the directory, to
any group or to any application.
Admins adding guest users to the directory

Add B2B collaboration users to the directory as an Azure AD administrator, as shown in the following video:
Admins adding guest users to a group

Add B2B collaboration users to a group as an Azure AD administrator, as shown in the following video:
Admins adding guest users to an application

Add B2B collaboration users to an application as an Azure AD administrator, as shown in the following video:
Admins resending invitations to guest users

You can go to a B2B collaboration user's profile page and resend invitations to any not-yet-redeemed guest
users:
![NOTE] If you resend invitations, the invitation is sent from the signed-in user to individual users even if the
original invitation was sent to a specific app or group.
Related articles
How do information workers add B2B collaboration
users to Azure Active Directory?
Information workers can use the Application Access Panel to add B2B collaboration users to groups and
applications that they administer.
Information workers adding B2B collaboration users to an application

Assign B2B collaboration users to an app as an information worker in a partner organization, as shown in the
following video:
Information workers adding B2B collaboration users to a group

Information workers can similarly add B2B collaboration users to an assigned group that is enabled for self-
service group management.
NOTE
You cannot add B2B collaboration users to a dynamic group or to a group that is synced with on-premises Active Directory.
Next steps
Azure Active Directory B2B collaboration API and
customization
We've had many customers tell us that they want to customize the invitation process in a way that works best for
their organizations. With our API, you can do just that. https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation
Capabilities of the invitation API

The API offers the following capabilities:
1. Invite an external user with any email address.
"invitedUserDisplayName": "Sam"
"invitedUserEmailAddress": "gsamoogle@gmail.com"
2. Customize where you want your users to land after they accept their invitation.
"inviteRedirectUrl": "https://myapps.microsoft.com/"
3. Choose to send the standard invitation mail through us
"sendInvitationMessage": true
with a message to the recipient that you can customize
"customizedMessageBody": "Hello Sam, let's collaborate!"
4. And choose to cc: people you want to keep in the loop about your inviting this collaborator.
5. Or completely customize your invitation and onboarding workflow by choosing not to send notifications
through Azure AD.
"sendInvitationMessage": false
In this case, you get back a redemption URL from the API that you can embed in an email template, IM, or
other distribution method of your choice.
6. Finally, if you are an admin, you can choose to invite the user as member.
"invitedUserType": "Member"
Authorization model
The API can be run in the following authorization modes:
App + User mode
In this mode, whoever is using the API needs to have the permissions to be create B2B invitations.
App only mode
In app only context, the app needs the User.ReadWrite.All or Directory.ReadWrite.All scopes for the invitation to
succeed.
For more information, refer to: https://graph.microsoft.io/docs/authorization/permission_scopes
PowerShell
It is now possible to use PowerShell to add and invite external users to an organization easily. Create an invitation
using the cmdlet:
New-AzureADMSInvitation
You can use the following options:

-InvitedUserDisplayName
-InvitedUserEmailAddress
-SendInvitationMessage
-InvitedUserMessageInfo
You can also check out the invitation API reference in https://developer.microsoft.com/graph/docs/api-
reference/v1.0/resources/invitation
Next steps
Azure Active Directory B2B collaboration code and
PowerShell samples
PowerShell example
You can bulk-invite external users to an organization from email addresses that you have stored in a .CSV file.
1. Prepare the .CSV file Create a new CSV file and name it invitations.csv. In this example, the file is saved in
C:\data, and contains the following information:
NAME INVITEDUSEREMAILADDRESS
Gmail B2B Invitee b2binvitee@gmail.com
Outlook B2B invitee b2binvitee@outlook.com
2. Get the latest Azure AD PowerShell To use the new cmdlets, you must install the updated Azure AD
PowerShell module, which you can download from the Powershell module's release page
3. Sign in to your tenancy
$cred = Get-Credential
Connect-AzureAD -Credential $cred
4. Run the PowerShell cmdlet
$invitations = import-csv C:\data\invitations.csv

$messageInfo = New-Object Microsoft.Open.MSGraph.Model.InvitedUserMessageInfo
$messageInfo.customizedMessageBody = “Hey there! Check this out. I created an invitation through
PowerShell”
foreach ($email in $invitations) {New-AzureADMSInvitation -InvitedUserEmailAddress
$email.InvitedUserEmailAddress -InvitedUserDisplayName $email.Name -InviteRedirectUrl
https://wingtiptoysonline-dev-ed.my.salesforce.com -InvitedUserMessageInfo $messageInfo -
SendInvitationMessage $true}
This cmdlet sends an invitation to the email addresses in invitations.csv. Additional features of this cmdlet include:
Customized text in the email message
Including a display name for the invited user
Sending messages to CCs or suppressing email messages altogether
Code sample
Here we illustrate how to call the invitation API, in "app-only" mode, to get the redemption URL for the resource to
which you are inviting the B2B user. The goal is to send a custom invitation email. The email can be composed
with an HTTP client, so you can customize how it looks and send it through Graph API.
namespace SampleInviteApp
{
using System;
using System.Linq;
using System.Net.Http;
using System.Net.Http.Headers;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
using Newtonsoft.Json;
class Program
{
/// <summary>
/// Microsoft graph resource.
/// </summary>
static readonly string GraphResource = "https://graph.microsoft.com";
/// <summary>
/// Microsoft graph invite endpoint.
/// </summary>
static readonly string InviteEndPoint = "https://graph.microsoft.com/v1.0/invitations";
/// <summary>
/// Authentication endpoint to get token.
/// </summary>
static readonly string EstsLoginEndpoint = "https://login.microsoftonline.com";
/// <summary>
/// This is the tenantid of the tenant you want to invite users to.
/// </summary>
private static readonly string TenantID = "";
/// <summary>
/// This is the application id of the application that is registered in the above tenant.
/// The required scopes are available in the below link.
/// https://developer.microsoft.com/graph/docs/api-reference/v1.0/api/invitation_post
/// </summary>
private static readonly string TestAppClientId = "";
/// <summary>
/// Client secret of the application.
/// </summary>
private static readonly string TestAppClientSecret = @"
/// <summary>
/// This is the email address of the user you want to invite.
/// </summary>
private static readonly string InvitedUserEmailAddress = @"";
/// <summary>
/// This is the display name of the user you want to invite.
/// </summary>
private static readonly string InvitedUserDisplayName = @"";
/// <summary>
/// Main method.
/// </summary>
/// <param name="args">Optional arguments</param>
static void Main(string[] args)
{
Invitation invitation = CreateInvitation();
SendInvitation(invitation);
}
/// <summary>
/// Create the invitation object.
/// </summary>
/// <returns>Returns the invitation object.</returns>
private static Invitation CreateInvitation()
{
// Set the invitation object.
Invitation invitation = new Invitation();
invitation.InvitedUserDisplayName = InvitedUserDisplayName;
invitation.InvitedUserEmailAddress = InvitedUserEmailAddress;
invitation.InviteRedirectUrl = "https://www.microsoft.com";
invitation.SendInvitationMessage = true;
return invitation;
}
/// <summary>
/// Send the guest user invite request.
/// </summary>
/// <param name="invitation">Invitation object.</param>
private static void SendInvitation(Invitation invitation)
{
string accessToken = GetAccessToken();
HttpClient httpClient = GetHttpClient(accessToken);
// Make the invite call.

HttpContent content = new StringContent(JsonConvert.SerializeObject(invitation));
content.Headers.Add("ContentType", "application/json");
var postResponse = httpClient.PostAsync(InviteEndPoint, content).Result;
string serverResponse = postResponse.Content.ReadAsStringAsync().Result;
Console.WriteLine(serverResponse);
}
/// <summary>
/// Get the HTTP client.
/// </summary>
/// <param name="accessToken">Access token</param>
/// <returns>Returns the Http Client.</returns>
private static HttpClient GetHttpClient(string accessToken)
{
// setup http client.
HttpClient httpClient = new HttpClient();
httpClient.Timeout = TimeSpan.FromSeconds(300);
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer",
accessToken);
httpClient.DefaultRequestHeaders.Add("client-request-id", Guid.NewGuid().ToString());
Console.WriteLine(
"CorrelationID for the request: {0}",
httpClient.DefaultRequestHeaders.GetValues("client-request-id").Single());
return httpClient;
}
/// <summary>
/// Get the access token for our application to talk to microsoft graph.
/// </summary>
/// <returns>Returns the access token for our application to talk to microsoft graph.</returns>
private static string GetAccessToken()
{
string accessToken = null;
// Get the access token for our application to talk to microsoft graph.
try
{
AuthenticationContext testAuthContext =
new AuthenticationContext(string.Format("{0}/{1}", EstsLoginEndpoint, TenantID));
AuthenticationResult testAuthResult = testAuthContext.AcquireTokenAsync(
GraphResource,
new ClientCredential(TestAppClientId, TestAppClientSecret)).Result;
accessToken = testAuthResult.AccessToken;
}
catch (AdalException ex)
{
Console.WriteLine("An exception was thrown while fetching the token: {0}.", ex);
throw;
}
return accessToken;
}
/// <summary>
/// Invitation class.
/// </summary>
public class Invitation
{
/// <summary>
/// Gets or sets display name.
/// </summary>
public string InvitedUserDisplayName { get; set; }
/// <summary>
/// Gets or sets display name.
/// </summary>
public string InvitedUserEmailAddress { get; set; }
/// <summary>
/// Gets or sets a value indicating whether Invitation Manager should send the email to
InvitedUser.
/// </summary>
public bool SendInvitationMessage { get; set; }
/// <summary>
/// Gets or sets invitation redirect URL
/// </summary>
public string InviteRedirectUrl { get; set; }
}
}
}
Next steps
B2B collaboration user properties
Adding a B2B collaboration user to a role
Delegate B2B collaboration invitations
Dynamic groups and B2B collaboration
Configure SaaS apps for B2B collaboration
B2B collaboration user tokens
B2B collaboration user claims mapping
Office 365 external sharing
B2B collaboration current limitations
Self-service portal for Azure AD B2B collaboration
sign-up
Customers can do a lot with the built-in features that are exposed through our IT admin Azure portal and our
Application Access Panel for end users. But we are also aware that businesses need to customize the onboarding
workflow for B2B users to fit their organization’s needs. They can do that with our API.
In discussions with our customers, we see one common need rise up above all others. The inviting organization
may not know ahead of time who the individual external collaborators are who need access to their resources. They
wanted a way for users from partner companies to sign themselves up with a set of policies that the inviting
organization controls. This scenario is possible through our APIs, so we published a project on Github that did just
that: sample Github project.
Our Github project demonstrates how organizations can use our APIs, and provide a policy-based, self-service sign-
up capability for their trusted partners, with rules that determine the apps they can access. Partner users can get
access to resources when they need them, securely, without requiring the inviting organization to manually
onboard them. You can easily deploy the project into an Azure subscription of your choice.
As-is code
Remember that this code is made available as a sample to demonstrate usage of the Azure Active Directory B2B
invitation API. It should be customized by your dev team or a partner, and should be reviewed before being
deployed in a production scenario.
Next steps
The elements of the B2B collaboration invitation
email - Azure Active Directory
Invitation emails are a critical component to bring partners on board as B2B collaboration users in Azure AD. You
can use them to increase the recipient's trust. you can add legitimacy and social proof to the email, to make sure
the recipient feels comfortable with selecting the Get Started button to accept the invitation. This trust is a key
means to reduce sharing friction. And you also want to make the email look great!
Explaining the email

Let's look at a few elements of the email so you know how best to use their capabilities.
Subject
The subject of the email follows the following pattern: You're invited to the <tenantname> organization
From address
We use a LinkedIn-like pattern for the From address. You should be clear who the inviter is and from which
company, and also clarify that the email is coming from a Microsoft email address. The format is: <Display name
of inviter> from <tenantname> (via Microsoft) <invites@microsoft.com>
Reply To
The reply-to email is set to the inviter's email when available, so that replying to the email sends an email back to
the inviter.
Branding
The invitation emails from your tenant use the company branding that you may have set up for your tenant. If
you want to take advantage of this capability, here are the details on how to configure it. The banner logo appears
in the email. Follow the image size and quality instructions here for best results. In addition, the company name
also shows up in the call to action.
Call to action
The call to action consists of two parts: explaining why the recipient has received the mail and what the recipient
is being asked to do about it.
The "why" section can be addressed using the following pattern: You've been invited to access applications
in the <tenantname> organization
And the "what you're being asked to do" section is indicated by the presence of the Get Started button.
When the recipient has been added without the need for invitations, this button doesn't show up.
Inviter's information
The inviter's display name is included in the email. And in addition, if you've set up a profile picture for your
Azure AD account, the inviting email will include that picture as well. Both are intended to increase your
recipient's confidence in the email.
If you haven't yet set up your profile picture, an icon with the inviter's initials in place of the picture is shown:
Body
The body contains the message that the inviter composes or is passed through the invitation API. It is a text area,
so it does not process HTML tags for security reasons.
Footer section
The footer contains the Microsoft company brand and lets the recipient know if the email was sent from an
unmonitored alias. Special cases:
The inviter doesn't have an email address in the inviting tenancy
The recipient doesn't need to redeem the invitation
Next steps
What is Azure AD B2B collaboration
Azure Active Directory B2B collaboration invitation
redemption
Azure AD and Microsoft account users

For users with existing Azure AD account or Microsoft accounts, the redemption experience is as easy as signing
in.
Social ID user first-time redemption

Azure AD B2B collaboration makes it easy for any email address to be used for redemption. Look at the
redemption experience when a non-Microsoft email address is used for B2B collaboration. This redemption flow
is more involved, because you might have to create an account at the time of redemption. Check it out in the
following video:
Next steps
Add B2B collaboration guest users without an
invitation
You can allow a user, such as a partner representative, to add users from the partner to your organization
without needing invitations to be redeemed. All you must do is grant that user enumeration privileges in the
directory you're using for the partner org.
Grant these privileges when:
1. A user in the host organization (for example, WoodGrove) invites one user from the partner organization (for
example, Sam@litware.com) as Guest.
2. The admin in the host organization sets up policies that allow Sam to identify and add other users from the
partner organization (Litware).
3. Now Sam can add other users from Litware to the WoodGrove directory, groups, or applications without
needing invitations to be redeemed. If Sam has the appropriate enumeration privileges in Litware, it happens
automatically.
Next steps
Conditional access for B2B collaboration users
Multi-factor authentication for B2B users

With Azure AD B2B collaboration, organizations can enforce multi-factor authentication (MFA) policies for B2B
users. These policies can be enforced at the tenant, app, or individual user level, the same way that they are
enabled for full-time employees and members of the organization. MFA policies are enforced at the resource
organization.
Example:
1. Admin or information worker in Company A invites user from company B to an application Foo in company
A.
2. Application Foo in company A is configured to require MFA on access.
3. When the user from company B attempts to access app Foo in the company A tenant, they are asked to
complete an MFA challenge.
4. The user can set up their MFA with company A, and chooses their MFA option.
5. This scenario works for any identity (Azure AD or MSA, for example, if users in Company B authenticate using
social ID)
6. Company A must have sufficient Premium Azure AD licenses that support MFA. The user from company B
consumes this license from company A.
The inviting tenancy is always responsible for MFA for users from the partner organization, even if the partner
organization has MFA capabilities.
Setting up MFA for B2B collaboration users
To discover how easy it is to set up MFA for B2B collaboration users, see how in the following video:
B2B users MFA experience for offer redemption

Check out the following animation to see the redemption experience:
MFA reset for B2B collaboration users

Currently, the admin can require B2B collaboration users to proof up again only by using the following
PowerShell cmdlets:
1. Connect to Azure AD
$cred = Get-Credential
Connect-MsolService -Credential $cred
2. Get all users with proof up methods
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e=

{($_.StrongAuthenticationMethods).MethodType}}
Here is an example:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e=

{($_.StrongAuthenticationMethods).MethodType}}
3. Reset the MFA method for a specific user to require the B2B collaboration user to set proof-up methods
again. Example:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@

WoodGroveAzureAD.onmicrosoft.com
Why do we perform MFA at the resource tenancy?

In the current release, MFA is always in the resource tenancy, for reasons of predictability. For example, let’s say a
Contoso user (Sally) is invited to Fabrikam and Fabrikam has enabled MFA for B2B users.
If Contoso has MFA policy enabled for App1 but not App2, then if we look at the Contoso MFA claim in the token,
we might see the following issue:
Day 1: A user has MFA in Contoso and is accessing App1, then no additional MFA prompt is shown in
Fabrikam.
Day 2: The user has accessed App 2 in Contoso, so now when accessing Fabrikam, they must register for
MFA there.
This process can be confusing and could lead to drop in sign-in completions.
Moreover, even if Contoso has MFA capability, it is not always the case the Fabrikam would trust the Contoso
MFA policy.
Finally, resource tenant MFA also works for MSAs and social IDs and for partner orgs that do not have MFA set
up.
Therefore, the recommendation for MFA for B2B users is to always require MFA in the inviting tenant. This
requirement could lead to double MFA in some cases, but whenever accessing the inviting tenant, the end-users
experience is predictable: Sally must register for MFA with the inviting tenant.
Device -based, location-based, and risk-based conditional access for B2B users
When Contoso enables device-based conditional access policies for their corporate data, access is prevented
from devices that are not managed by Contoso and not compliant with the Contoso device policies.
If the B2B user’s device isn't managed by Contoso, access of B2B users from the partner organizations is blocked
in whatever context these policies are enforced. However, Contoso can create exclusion lists containing specific
partner users to exclude them from the device-based conditional access policy.
Location-based conditional access for B2B
Location-based conditional access policies can be enforced for B2B users if the inviting organization is able to
create a trusted IP address range that defines their partner organizations.
Risk-based conditional access for B2B
Currently, risk-based sign-in policies cannot be applied to B2B users because the risk evaluation is performed at
the B2B user’s home organization.
Next steps
Article index for application management in Azure Active Directory
Delegate invitations for Azure Active Directory B2B
collaboration
With Azure Active Directory (Azure AD) business-to-business (B2B) collaboration, you do not have to be a global
admin to send invitations. Instead, you can use policies and delegate invitations to users whose roles allow them
to send invitations. An important new way to delegate guest user invitations is through the Guest Inviter role.
Guest Inviter role

We can assign the user to Guest Inviter role to send invitations. You don't have to be member of the global admin
role to send invitations. By default, regular users can also invoke the invite API unless a global admin disabled
invitations for regular users. A user can also invoke the API using the Azure portal or PowerShell.
Here's an example that shows how to use PowerShell to add a user to the Guest Inviter role:
Add-MsolRoleMember -RoleObjectId 95e79109-95c0-4d8e-aee3-d01accf2d47b -RoleMemberEmailAddress

<RoleMemberEmailAddress>
Control who can invite
With Azure AD B2B collaboration, a tenant admin can set the following invitation policies:
Turn off invitations
Only admins and users in the Guest Inviter role can invite
Admins, the Guest Inviter role, and members can invite
All users, including guests, can invite
By default, tenants are set to #4. (All users, including guests, can invite B2B users.)
Next steps
B2B collaboration code and PowerShell samples
Grant permissions to users from partner
organizations in your Azure Active Directory tenant
Azure Active Directory (Azure AD) B2B collaboration users are added as guest users to the directory, and guest
permissions in the directory are restricted by default. Your business may need some guest users to fill higher-
privilege roles in your organization. To support defining higher-privilege roles, guest users can be added to any
roles you desire, based on your organization's needs.
Default role
Global Administrator Role

Limited Administrator Role
Next steps
Delegate B2bB collaboration invitations
Dynamic groups and Azure Active Directory B2B
collaboration
What are dynamic groups?

Dynamic configuration of security group membership for Azure Active Directory (Azure AD) is available in the
Azure portal. Administrators can set rules to populate groups that are created in Azure AD based on user
attributes (such as userType, department, or country). Members can be automatically added to or removed from a
security group based on their attributes. These groups can provide access to applications or cloud resources
(SharePoint sites, documents) and to assign licenses to members. Read more about dynamic groups in Dedicated
groups in Azure Active Directory.
The appropriate Azure AD Premium P1 or P2 licensing is required to create and use dynamic groups. Learn more
in the article Create attribute-based rules for dynamic group membership in Azure Active Directory.
What are the built-in dynamic groups?

The All users dynamic group enables tenant admins to create a group containing all users in the tenant with a
single click. By default, the All users group includes all users in the directory, including Members and Guests.
Within the new Azure Active Directory admin portal, you can choose to enable the All users group in the Group
Settings view.
Hardening the All users dynamic group

By default, the All users group contains your B2B collaboration (guest) users as well. You can further secure your
All users group by using a rule to remove guest users. The following illustration shows the All users group
modified to exclude guests.
You might also find it useful to create a new dynamic group that contains only guest users, so that you can apply
policies (such as Azure AD Conditional Access policies) to them. What such a group might look like:
Next steps
Auditing and reporting a B2B collaboration user
With guest users, you have auditing capabilities similar to with member users. Here's an example of the invitation
and redemption history of invitee Sam Oogle:
You can dive into each of these events to get the details. For example, let's look at the acceptance details.
You can also export these logs from Azure AD and use the reporting tool of your choice to get customized reports.
Next steps
Azure Active Directory B2B collaboration for hybrid
organizations
In a hybrid organization, where you have both on-premises and cloud resources, you might want to give external
partners access to both local and cloud resources. For access to local resources, you can manage partner accounts
locally in your on-premises Active Directory environment. Partners sign in with their partner account credentials to
access your organization's resources. To give partners access to cloud resources using these same credentials, you
can now use Azure Active Directory (Azure AD) Connect to sync the partner accounts to the cloud as Azure AD B2B
users (that is, users with UserType = Guest).
Identify unique attributes for UserType

Before you enable synchronization of the UserType attribute, you must first decide how to derive the UserType
attribute from on-premises Active Directory. In other words, what parameters in your on-premises environment are
unique to your external collaborators? Determine a parameter that distinguishes these external collaborators from
members of your own organization.
Two common approaches for this are to:
Designate an unused on-premises Active Directory attribute (for example, extensionAttribute1) to use as the
source attribute.
Alternatively, derive the value for UserType attribute from other properties. For example, you want to
synchronize all users as Guest if their on-premises Active Directory UserPrincipalName attribute ends with the
domain @partners.fabrikam123.org.
For detailed attribute requirements, see Enable synchronization of UserType.
Configure Azure AD Connect to sync users to the cloud

After you identify the unique attribute, you can configure Azure AD Connect to sync these users to the cloud as
Azure AD B2B users (that is, users with UserType = Guest). From an authorization point of view, these users are
indistinguishable from B2B users created through the Azure AD B2B collaboration invitation process.
For implementation instructions, see Enable synchronization of UserType.
Next steps
For an overview of Azure AD B2B collaboration, see What is Azure AD B2B collaboration?
For an overview of Azure AD Connect, see Integrate your on-premises directories with Azure Active Directory.
Office 365 external sharing and Azure Active
Directory B2B collaboration
External sharing in Office 365 (OneDrive, SharePoint Online, Unified Groups, etc.) and Azure Active Directory
(Azure AD) B2B collaboration are technically the same thing. All external sharing (except OneDrive/SharePoint
Online), including guests in Office 365 Groups, already uses the Azure AD B2B collaboration invitation APIs for
sharing.
OneDrive/SharePoint Online has a separate invitation manager. Support for external sharing in
OneDrive/SharePoint Online started before Azure AD developed its support. Over time, OneDrive/SharePoint
Online external sharing has accrued several features and many millions of users who use the product's in-built
sharing pattern. However, there are some subtle differences between how OneDrive/SharePoint Online external
sharing works and how Azure AD B2B collaboration works:
OneDrive/SharePoint Online adds users to the directory after users have redeemed their invitations. So,
before redemption, you don't see the user in Azure AD portal. If another site invites a user in the
meantime, a new invitation is generated. However, when you use Azure AD B2B collaboration, users are
added immediately on invitation so that they show up everywhere.
The redemption experience in OneDrive/SharePoint Online looks different from the experience in Azure
AD B2B collaboration. After a user redeems an invitation, the experiences look alike.
Azure AD B2B collaboration invited users can be picked from OneDrive/SharePoint Online sharing dialog
boxes. OneDrive/SharePoint Online invited users also show up in Azure AD after they redeem their
invitations.
To manage external sharing in OneDrive/SharePoint Online with Azure AD B2B collaboration, set the
OneDrive/SharePoint Online external sharing setting to Only allow sharing with external users
already in the directory. Users can go to externally shared sites and pick from external collaborators that
the admin has added. The admin can add the external collaborators through the B2B collaboration
invitation APIs.
Next steps
Azure Active Directory B2B collaboration licensing
guidance
You can use Azure AD B2B collaboration capabilities to invite guest users into your Azure AD tenant to allow
them to access Azure AD services and other resources in your organization. If you want to provide access to paid
Azure AD features, B2B collaboration guest users must be licensed with appropriate Azure AD licenses.
Specifically:
Azure AD Free capabilities are available for guest users without additional licensing.
If you want to provide access to paid Azure AD features to B2B users, you must have enough licenses to
support those B2B guest users.
An inviting tenant with an Azure AD paid license has B2B collaboration use rights to an additional five B2B
guest users invited to the tenant.
The customer who owns the inviting tenant must be the one to determine how many B2B collaboration users
need paid Azure AD capabilities. Depending on the paid Azure AD features you want for your guest users,
you must have enough Azure AD paid licenses to cover B2B collaboration users in the same 5:1 ratio.
A B2B collaboration guest user is added as a user from a partner company, not an employee of your
organization or an employee of a different business in your conglomerate. A B2B guest user can sign in with
external credentials or credentials owned by your organization as described in this article.
In other words, B2B licensing is set not by how the user authenticates but rather by the relationship of the user
to your organization. If these users are not partners, they are treated differently in licensing terms. They are not
considered to be a B2B collaboration user for licensing purposes even if their UserType is marked as “Guest.”
They should be licensed normally, at one license per user. These users include:
Your employees
Staff signing in using external identities
An employee of a different business in your conglomerate
Licensing examples
A customer wants to invite 100 B2B collaboration users to its Azure AD tenant. The customer assigns access
management and provisioning for all users, but 50 users also require MFA and conditional access. This
customer must purchase 10 Azure AD Basic licenses and 10 Azure AD Premium P1 licenses to cover these
B2B users correctly. If the customer plans to use Identity Protection features with B2B users, they must have
Azure AD Premium P2 licenses to cover the invited users in the same 5:1 ratio.
A customer has 10 employees who are all currently licensed with Azure AD Premium P1. They now want to
invite 60 B2B users who all require multi-factor authentication (MFA). Under the 5:1 licensing rule, the
customer must have at least 12 Azure AD Premium P1 licenses to cover all 60 B2B collaboration users.
Because they already have 10 Premium P1 licenses for their 10 employees, they have rights to invite 50 B2B
users with Premium P1 features like MFA. In this example, then, they must purchase 2 additional Premium P1
licenses to cover the remaining 10 B2B collaboration users.
NOTE
There is no way yet to assign licenses directly to the B2B users to enable these B2B collaboration user rights.
The customer who owns the inviting tenant must be the one to determine how many B2B collaboration users
need paid Azure AD capabilities. Depending on which paid Azure AD features you want for your guest users, you
must have enough Azure AD paid licenses to cover B2B collaboration users in the 5:1 ratio.
Additional licensing details

There is no need to actually assign licenses to B2B user accounts. Based on the 5:1 ratio, licensing is
automatically calculated and reported.
If no paid Azure AD license exists in the tenant, every invited user gets the rights that the Azure AD Free
edition offers.
If a B2B collaboration user already has a paid Azure AD license from their organization, they do not consume
one of the B2B collaboration licenses of the inviting tenant.
Advanced discussion: What are the licensing considerations when we

add users from a conglomerate organization as “members” using your
APIs?
A B2B guest user is one that is invited from a partner organization to work with the host organization. Typically,
any other case does not qualify as B2B even it uses B2B features. Let’s look at two cases in particular:
1. If a host invites an employee using a consumer address
This scenario is not compliant with our licensing policies and is not recommended.
2. If a host organization adds a user from another conglomerate organization
a. In this case, the user is invited using B2B APIs, but this case is not traditionally B2B. Ideally, we
should have these organizations invite the other orgs users as members (our API allows that). In
this case, licenses have to be assigned to these members for them to access resources in the
inviting organization.
b. Some organizations may want to add the other org’s users to be added as “Guest” as a policy.
There are two cases here:
The conglomerate organization is already using Azure AD and the invited users are licensed
in the other organization: in this case, we don’t expect invited users to need to follow the 1:5
formula laid out earlier in this document.
The conglomerate organization is not using Azure AD or doesn’t have adequate licenses: In
this case, follow the 1:5 formula laid out earlier in this document.
Next steps
Limitations of Azure AD B2B collaboration
Azure Active Directory (Azure AD) B2B collaboration is currently subject to the limitations described in this article.
Possible double multi-factor authentication

With Azure AD B2B, you can enforce multi-factor authentication at the resource organization (the inviting
organization). The reasons for this approach are detailed in Conditional access for B2B collaboration users. If a
partner already has multi-factor authentication set up and enforced, their users might have to perform the
authentication once in their home organization and then again in yours.
Instant-on
In the B2B collaboration flows, we add users to the directory and dynamically update them during invitation
redemption, app assignment, and so on. The updates and writes ordinarily happen in one directory instance and
must be replicated across all instances. Replication is completed once all instances are updated. Sometimes when
the object is written or updated in one instance and the call to retrieve this object is to another instance,
replication latencies can occur. If that happens, refresh or retry to help. If you are writing an app using our API,
then retries with some back-off is a good, defensive practice to alleviate this issue.
Next steps
Azure Active Directory B2B collaboration FAQs
These frequently asked questions (FAQs) about Azure Active Directory (Azure AD) business-to-business (B2B)
collaboration are periodically updated to include new topics.
Can we customize our sign-in page so it is more intuitive for our B2B collaboration guest users?
Absolutely! See our blog post about this feature. For more information about how to customize your
organization's sign-in page, see Add company branding to sign in and Access Panel pages.
Can B2B collaboration users access SharePoint Online and OneDrive?
Yes. However, the ability to search for existing guest users in SharePoint Online by using the people picker is Off
by default. To turn on the option to search for existing guest users, set
ShowPeoplePickerSuggestionsForGuestUsers to On. You can turn this setting on either at the tenant level or
at the site collection level. You can change this setting by using the Set-SPOTenant and Set-SPOSite cmdlets.
With these cmdlets, members can search all existing guest users in the directory. Changes in the tenant scope do
not affect SharePoint Online sites that have already been provisioned.
Is the CSV upload feature still supported?
Yes. For more information about using the .csv file upload feature, see this PowerShell sample.
How can I customize my invitation emails?
You can customize almost everything about the inviter process by using the B2B invitation APIs.
Can an invited external user leave the organization after being invited?
The inviting organization administrator can delete a B2B collaboration guest user from their directory, but the
guest user cannot leave the inviting organization directory by themselves.
Can guest users reset their multi-factor authentication method?
Yes. Guest users can reset their multi-factor authentication method the same way that regular users do.
Which organization is responsible for multi-factor authentication licenses?
The inviting organization performs multi-factor authentication. The inviting organization must make sure that the
organization has enough licenses for their B2B users who are using multi-factor authentication.
What if a partner organization already has multi-factor authentication set up? Can we trust their multi-factor
authentication, and not use our own multi-factor authentication?
This feature is planned for a future release, so that then you can select specific partners to exclude from your (the
inviting organization's) multi-factor authentication.
How can I use delayed invitations?
An organization might want to add B2B collaboration users, provision them to applications as needed, and then
send invitations. You can use the B2B collaboration invitation API to customize the onboarding workflow.
Can I make a guest user a limited administrator?
Absolutely. For more information, see Adding guest users to a role.
Does Azure AD B2B collaboration allow B2B users to access the Azure portal?
Unless a user is assigned the role of limited administrator or global administrator, B2B collaboration users won't
require access to the Azure portal. However, B2B collaboration users who are assigned the role of limited
administrator or global administrator can access the portal. Also, if a guest user who is not assigned one of these
admin roles accesses the portal, the user might be able to access certain parts of the experience. The guest user
role has some permissions in the directory.
Can I block access to the Azure portal for guest users?
Yes! When you configure this policy, be careful to avoid accidentally blocking access to members and admins. To
block a guest user's access to the Azure portal, use a conditional access policy in the Windows Azure classic
deployment model API:
1. Modify the All Users group so that it contains only members.
2. Create a dynamic group that contains guest users.
3. Set up a conditional access policy to block guest users from accessing the portal, as shown in the
following video:
Does Azure AD B2B collaboration support multi-factor authentication and consumer email accounts?
Yes. Multi-factor authentication and consumer email accounts are both supported for Azure AD B2B
collaboration.
Do you plan to support password reset for Azure AD B2B collaboration users?
Yes. Here are the important details for self-service password reset (SSPR) for a B2B user who is invited from a
partner organization:
SSPR occurs only in the identity tenant of the B2B user.
If the identity tenant is a Microsoft account, the Microsoft account SSPR mechanism is used.
If the identity tenant is a just-in-time (JIT) or "viral" tenant, a password reset email is sent.
For other tenants, the standard SSPR process is followed for B2B users. Like member SSPR for B2B users, in
the context of the resource, tenancy is blocked.
Is password reset available for guest users in a just-in-time (JIT ) or "viral" tenant who accepted invitations with
a work or school email address, but who didn't have a pre -existing Azure AD account?
Yes. A password reset mail can be sent that allows a user to reset their password in the JIT tenancy.
Does Microsoft Dynamics CRM provide online support for Azure AD B2B collaboration?
Currently, Microsoft Dynamics CRM does not provide online support for Azure AD B2B collaboration. However,
we plan to support this in the future.
What is the lifetime of an initial password for a newly created B2B collaboration user?
Azure AD has a fixed set of character, password strength, and account lockout requirements that apply equally to
all Azure AD cloud user accounts. Cloud user accounts are accounts that are not federated with another identity
provider, such as
Microsoft account
Facebook
Active Directory Federation Services
Another cloud tenant (for B2B collaboration)
For federated accounts, password policy depends on the policy that is applied in the on-premises tenancy and
the user's Microsoft account settings.
An organization might want to have different experiences in their applications for tenant users and guest
users. Is there standard guidance for this? Is the presence of the identity provider claim the correct model to
use?
A guest user can use any identity provider to authenticate. For more information, see Properties of a B2B
collaboration user. Use the UserType property to determine user experience. The UserType claim is not
currently included in the token. Applications should use the Graph API to query the directory for the user, and to
get the UserType.
Where can I find a B2B collaboration community to share solutions and to submit ideas?
We're constantly listening to your feedback, to improve B2B collaboration. We invite you to share your user
scenarios, best practices, and what you like about Azure AD B2B collaboration. Join the discussion in the
Microsoft Tech Community.
We also invite you to submit your ideas and vote for future features at B2B Collaboration Ideas.
Can we send an invitation that is automatically redeemed, so that the user is just “ready to go”? Or does the
user always have to click through to the redemption URL?
Invitations that are sent by a user in the inviting organization who is also a member of the partner organization
do not require redemption by the B2B user.
We recommend that you invite one user from the partner organization to join the inviting organization. Add this
user to the guest inviter role in the resource organization. This user can invite other users in the partner
organization by using the sign-in UI, PowerShell scripts, or APIs. Then, B2B collaboration users from that
organization aren't required to redeem their invitations.
How does B2B collaboration work when the invited partner is using federation to add their own on-premises
authentication?
If the partner has an Azure AD tenant that is federated to the on-premises authentication infrastructure, on-
premises single sign-on (SSO) is automatically achieved. If the partner doesn't have an Azure AD tenant, an
Azure AD account is created for new users.
I thought Azure AD B2B didn't accept gmail.com and outlook.com email addresses, and that B2C was used
for those kinds of accounts?
We are removing the differences between B2B and business-to-consumer (B2C) collaboration in terms of which
identities are supported. The identity used is not a good reason to choose between using B2B or using B2C. For
information about choosing your collaboration option, see Compare B2B collaboration and B2C in Azure Active
Directory.
What applications and services support Azure B2B guest users?
All Azure AD-integrated applications support Azure B2B guest users.
Can we force multi-factor authentication for B2B guest users if our partners don't have multi-factor
authentication?
Yes. For more information, see Conditional access for B2B collaboration users.
In SharePoint, you can define an "allow" or "deny" list for external users. Can we do this in Azure?
Yes. Azure AD B2B collaboration supports allow lists and deny lists.
What licenses do we need to use Azure AD B2B?
For information about what licenses your organization needs to use Azure AD B2B, see Azure Active Directory
B2B collaboration licensing guidance.
Next steps
How do Azure AD admins add B2B collaboration users?
Troubleshooting Azure AD B2B collaboration
Azure AD B2B collaboration API and customization
Article index for application management in Azure AD
Troubleshooting Azure Active Directory B2B
collaboration
Here are some remedies for common problems with Azure Active Directory (Azure AD) B2B collaboration.
I’ve added an external user but do not see them in my Global Address
Book or in the people picker
In cases where external users are not populated in the list, the object might take a few minutes to replicate.
A B2B guest user is not showing up in SharePoint Online/OneDrive

people picker
The ability to search for existing guest users in the SharePoint Online (SPO) people picker is OFF by default to
match legacy behavior.
You can enable this feature by using the setting 'ShowPeoplePickerSuggestionsForGuestUsers' at the tenant and
site collection level. You can set the feature using the Set-SPOTenant and Set-SPOSite cmdlets, which allow
members to search all existing guest users in the directory. Changes in the tenant scope do not affect already
provisioned SPO sites.
Invitations have been disabled for directory

If you are notified that you do not have permissions to invite users, verify that your user account is authorized to
invite external users under User Settings:
If you have recently modified these settings or assigned the Guest Inviter role to a user, there might be a 15-60
minute delay before the changes take effect.
The user that I invited is receiving an error during redemption

Common errors include:
Invitee’s Admin has disallowed EmailVerified Users from being created in their tenant
When inviting users whose organization is using Azure Active Directory, but where the specific user’s account
does not exist (for example, the user does not exist in Azure AD contoso.com). The administrator of contoso.com
may have a policy in place preventing users from being created. The user must check with their admin to
determine if external users are allowed. The external user’s admin may need to allow Email Verified users in their
domain (see this article on allowing Email Verified Users).
External user does not exist already in a federated domain

If you are using federation authentication and the user does not already exist in Azure Active Directory, the user
cannot be invited.
To resolve this issue, the external user’s admin must synchronize the user’s account to Azure Active Directory.
How does ‘#’, which is not normally a valid character, sync with Azure
AD?
“#” is a reserved character in UPNs for Azure AD B2B collaboration or external users, because the invited account
user@contoso.com becomes user_contoso.com#EXT@fabrikam.onmicrosoft.com. Therefore, # in UPNs coming
from on-premises aren't allowed to sign in to the Azure portal.
I receive an error when adding external users to a synchronized group

External users can be added only to “assigned” or “Security” groups and not to groups that are mastered on-
premises.
My external user did not receive an email to redeem

The invitee should check with their ISP or spam filter to ensure that the following address is allowed:
Invites@microsoft.com
I notice that the custom message does not get included with
invitation messages at times
To comply with privacy laws, our APIs do not include custom messages in the email invitation when:
The inviter doesn’t have an email address in the inviting tenant
When an appservice principal sends the invitation
If this scenario is important to you, you can suppress our API invitation email, and send it through the email
mechanism of your choice. Consult your organization’s legal counsel to make sure any email you send this way
also complies with privacy laws.
Next steps
Properties of an Azure Active Directory B2B
collaboration user
An Azure Active Directory (Azure AD) business-to-business (B2B) collaboration user is a user with UserType =
Guest. This guest user typically is from a partner organization and has limited privileges in the inviting directory,
by default.
Depending on the inviting organization's needs, an Azure AD B2B collaboration user can be in one of the
following account states:
State 1: Homed in an external instance of Azure AD and represented as a guest user in the inviting
organization. In this case, the B2B user signs in by using an Azure AD account that belongs to the invited
tenant. If the partner organization doesn't use Azure AD, the guest user in Azure AD is still created. The
requirements are that they redeem their invitation and Azure AD verifies their email address. This
arrangement is also called a just-in-time (JIT) tenancy or a "viral" tenancy.
State 2: Homed in a Microsoft account and represented as a guest user in the host organization. In this
case, the guest user signs in with a Microsoft account. The invited user's social identity (google.com or
similar), which is not a Microsoft account, is created as a Microsoft account during offer redemption.
State 3: Homed in the host organization's on-premises Active Directory and synced with the host
organization's Azure AD. During this release, you must use PowerShell to manually change the UserType
of such users in the cloud.
State 4: Homed in host organization's Azure AD with UserType = Guest and credentials that the host
organization manages.
Now, let's see what an Azure AD B2B collaboration user in State 1 looks like in Azure AD.
Before invitation redemption
After invitation redemption
Key properties of the Azure AD B2B collaboration user
UserType
This property indicates the relationship of the user to the host tenancy. This property can have two values:
Member: This value indicates an employee of the host organization and a user in the organization's
payroll. For example, this user expects to have access to internal-only sites. This user would not be
considered an external collaborator.
Guest: This value indicates a user who isn't considered internal to the company, such as an external
collaborator, partner, customer, or similar user. Such a user wouldn't be expected to receive a CEO's
internal memo, or receive company benefits, for example.
NOTE
The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property
simply indicates the user's relationship to the host organization and allows the organization to enforce policies that
depend on this property.
Source
This property indicates how the user signs in.
Invited User: This user has been invited but has not yet redeemed an invitation.
External Active Directory: This user is homed in an external organization and authenticates by using an
Azure AD account that belongs to the other organization. This type of sign-in corresponds to State 1.
Microsoft account: This user is homed in a Microsoft account and authenticates by using a Microsoft
account. This type of sign-in corresponds to State 2.
Windows Server Active Directory: This user is signed in from on-premises Active Directory that belongs to
this organization. This type of sign-in corresponds to State 3.
Azure Active Directory: This user authenticates by using an Azure AD account that belongs to this
organization. This type of sign-in corresponds to State 4.
NOTE
Source and UserType are independent properties. A value of Source does not imply a particular value for UserType.
Can Azure AD B2B users be added as members instead of guests?

Typically, an Azure AD B2B user and guest user are synonymous. Therefore, an Azure AD B2B collaboration user
is added as a user with UserType = Guest by default. However, in some cases, the partner organization is a
member of a larger organization to which the host organization also belongs. If so, the host organization might
want to treat users in the partner organization as members instead of guests. Use the Azure AD B2B Invitation
Manager APIs to add or invite a user from the partner organization to the host organization as a member.
Filter for guest users in the directory

Convert UserType
Currently, it is possible for users to convert UserType from Member to Guest and vice-versa by using PowerShell.
However, the UserType property is supposed to represent the user's relationship to the organization. Therefore,
the value of this property should change only if the relationship of the user to the organization changes. If the
relationship of the user changes, should issues, like whether the user principal name (UPN) should change, be
addressed? Should the user continue to have access to the same resources? Should a mailbox be assigned?
Therefore, we do not recommend changing the UserType by using PowerShell as an atomic activity. In addition,
in case this property becomes immutable by using PowerShell, we do not recommend taking a dependency on
this value.
Remove guest user limitations

There may be cases where you want to give your guest users higher privileges. You can add a guest user to any
role and even remove the default guest user restrictions in the directory to give a user the same privileges as
members.
It is possible to turn off the default guest user limitations so that a guest user in the company directory is given
the same permissions as a member user.
Next steps
B2B collaboration user auditing and reporting
Understand user tokens in Azure AD B2B
collaboration
If you want to know what the token looks like for a B2B collaboration user, here are the bearer token details and
token content for an Azure Active Directory (Azure AD) guest and a Microsoft account guest in the resource
tenant (for tenantid 04dcc6ab-388a-4559-b527-fbec656300ea). To see the JSON Web Token (JWT) contents, use
https://jwt.io/ or http://calebb.net.
Azure AD guest token

Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ilk0dWVLMm9hSU5RaVFiNVlFQlNZVnlEY3BBVSIsImtpZCI6Ilk0dWVLMm9hSU5R
aVFiNVlFQlNZVnlEY3BBVSJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0LyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3M
ubmV0LzA0ZGNjNmFiLTM4OGEtNDU1OS1iNTI3LWZiZWM2NTYzMDBlYS8iLCJpYXQiOjE0ODQ4MDM5MTgsIm5iZiI6MTQ4NDgwMzkxOCwiZXh
wIjoxNDg0ODA3ODE4LCJhY3IiOiIxIiwiYWlvIjoiQVFBQkFBRUFBQURSTllSUTNkaFJTcm0tNEstYWRwQ0pJNWNncGtYQ0VOTHdnN1Z1emh
FQURIajNOOWNIMzhRWGFBakhrYUtPRFhneWJpcnVRYVhpa3RZZ3I2M0xMQTVTVDlEeXV2dEtQSUdlXzJpVFRhdjNqSkxuTlRSZ2JWRFpwckh
SaEtZbWl5RWdBQSIsImFsdHNlY2lkIjoiNTo6MTAwMzAwMDA4MDFCQUZDNyIsImFtciI6WyJwd2QiLCJyc2EiXSwiYXBwaWQiOiJjNDRiNDA
4My0zYmIwLTQ5YzEtYjQ3ZC05NzRlNTNjYmRmM2MiLCJhcHBpZGFjciI6IjIiLCJlX2V4cCI6MTA4MDAsImVtYWlsIjoicmFqZXNiQG1pY3J
vc29mdC5jb20iLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiw
iaW5fY29ycCI6InRydWUiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTk1IiwibmFtZSI6InJhamVzaCIsIm9pZCI6IjA1ODAyY2M1LTgxMWUtNDZ
iZC1iMWI2LTU5NDZlNjY4ODIyZiIsInBsYXRmIjoiMyIsInB1aWQiOiIxMDAzM0ZGRjlEOEY5OTUzIiwic2NwIjoidXNlcl9pbXBlcnNvbmF
0aW9uIiwic3ViIjoiS1d3QnVCNk5ROU5UYmpoSUI1OHEwM2FlQVl6cEk2TWxiMkpncGk1aV9ITSIsInRpZCI6IjA0ZGNjNmFiLTM4OGEtNDU
1OS1iNTI3LWZiZWM2NTYzMDBlYSIsInVuaXF1ZV9uYW1lIjoicmFqZXNiQG1pY3Jvc29mdC5jb20iLCJ2ZXIiOiIxLjAifQ.Vllr1hGXpBlp
XDBKRHHYbMr_1_DwKNY3eCObBOfEaxJirwqujqCZodPrAkIOJlFYyhkILyHZQUi_D1w7XoPsd6U4GQlgOoFfzbye-
P_NdRFabHMlv32gCgHz1xo11aPP453EiwwG5OHnWaHYLBpuqi3sNeKx06xbTFj07HmADDaR4aM0jwy031d6GkD0LdU-Xkazi5-
h8parVRLOkkLZA0oxMFoxl_-VHr1hOzxCkbWgRoug4t97161i5tGil99CcpJ6NK8uQld7TveC40sjJ735Sksn-
Uq_NZcJuXCEVsH0xK5evaeFBFSEqACXjKTvYkJWtAx8Kr8yWZAcEg0YMQ
Microsoft account guest token

Authorization: Bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ilk0dWVLMm9hSU5RaVFiNVlFQlNZVnlEY3BBVSIsImtpZCI6Ilk0dWVLMm9hSU5R
aVFiNVlFQlNZVnlEY3BBVSJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0LyIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3M
ubmV0LzA0ZGNjNmFiLTM4OGEtNDU1OS1iNTI3LWZiZWM2NTYzMDBlYS8iLCJpYXQiOjE0ODQ4MDMwNjEsIm5iZiI6MTQ4NDgwMzA2MSwiZXh
wIjoxNDg0ODA2OTYxLCJhY3IiOiIxIiwiYWlvIjoiQVFBQkFBRUFBQURSTllSUTNkaFJTcm0tNEstYWRwQ0pEeEd4a3lUdmJ2d1RoSHJnTEd
PaGZEbTA1aXJndC1lR1d3YTl5QUZQQTJQc19nZHF2bHQ1X1AtaDhrT2IwdUdza3dyYklBbUhvMEtRM005N2ZCVlRtdzRKY0NfaFVkWW1PZ25
QYVlOY1BRQXBIYmFMcUlaZGhaRXhtQVZJeXFmaElBQSIsImFsdHNlY2lkIjoiMTpsaXZlLmNvbTowMDAzMDAwMEEwNzBCOTYyIiwiYW1yIjp
bInB3ZCJdLCJhcHBpZCI6ImM0NGI0MDgzLTNiYjAtNDljMS1iNDdkLTk3NGU1M2NiZGYzYyIsImFwcGlkYWNyIjoiMiIsImVfZXhwIjoxMDg
wMCwiZW1haWwiOiJiYXNhcmFqZXNoQGxpdmUuY29tIiwiZmFtaWx5X25hbWUiOiJiYXNhIiwiZ2l2ZW5fbmFtZSI6InJhamVzaCIsImlkcCI
6ImxpdmUuY29tIiwiaXBhZGRyIjoiMTY3LjIyMC4xLjE5NSIsIm5hbWUiOiJiYXNhcmFqZXNoIiwib2lkIjoiMjU0NmU3NDEtNmZjNi00ZDI
0LTg2NTQtZjkyNDc5MzI0ZjM3IiwicGxhdGYiOiIzIiwicHVpZCI6IjEwMDMzRkZGOURBQjk2NDYiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXR
pb24iLCJzdWIiOiI4Y2N5OEh4cmE5UTl2aGdYOXhBODFBeWJEV3dsVmxjXzRBZVJYZ2lzamM4IiwidGlkIjoiMDRkY2M2YWItMzg4YS00NTU
5LWI1MjctZmJlYzY1NjMwMGVhIiwidW5pcXVlX25hbWUiOiJsaXZlLmNvbSNiYXNhcmFqZXNoQGxpdmUuY29tIiwidmVyIjoiMS4wIn0.LSI
BlJpElXpsGXOGaFINW-jOBHsI0Dxe3oX-
YIEsccegDCspl6UnRjpwzs0nBL09B4N0oqLd7ZwXZAQURpgaAFnWvROxkIGpNTE_ppSKU1suud8keG5VnTEu82em95G1_c_eW1nOemPvbADC
C8h08p2wxNm8QyEhmYqauN6qYbeqOnioRERXO3zOPg8nSXFcGPhvumJ_BW8XKnW4zLdhK78c3PgynPnwtIm08SksMRDzGMgUc9RK1bpPQtgX
8iFQByEljf5cuE_h_e1Nr5Y4StrhS3JCiQLTYZ727YY-lSm5DERiQrt7MkP5BHprEmSByofSvACj5TmVdqBFUjobuA
Next steps
Azure Active Directory (Azure AD) B2B collaboration works with most apps that integrate with Azure AD. In this
section, we walk through instructions for configuring some popular SaaS apps for use with Azure AD B2B.
Before you look at app-specific instructions, here are some rules of thumb:
For most of the apps, user setup needs to happen manually. That is, users must be created manually in the
app as well.
For apps that support automatic setup, such as Dropbox, separate invitations are created from the apps.
Users must be sure to accept each invitation.
In the user attributes, to mitigate any issues with mangled user profile disk (UPD) in guest users, always
set User Identifier to user.mail.
Dropbox Business
To enable users to sign in using their organization account, you must manually configure Dropbox Business to
use Azure AD as a Security Assertion Markup Language (SAML) identity provider. If Dropbox Business has not
been configured to do so, it cannot prompt or otherwise allow users to sign in using Azure AD.
1. To add the Dropbox Business app into Azure AD, select Enterprise applications in the left pane, and then
click Add.
2. In the Add an application window, enter dropbox in the search box, and then select Dropbox for
Business in the results list.
3. On the Single sign-on page, select Single sign-on in the left pane, and then enter user.mail in the User
Identifier box. (It's set as UPN by default.)
4. To download the certificate to use for Dropbox configuration, select Configure DropBox, and then select
SAML Single Sign On Service URL in the list.
5. Sign in to Dropbox with the sign-on URL from the Single sign-on page.
6. On the menu, select Admin Console.
7. In the Authentication dialog box, select More, upload the certificate and then, in the Sign in URL box,
enter the SAML single sign-on URL.
8. To configure automatic user setup in the Azure portal, select Provisioning in the left pane, select
Automatic in the Provisioning Mode box, and then select Authorize.
After guest or member users have been set up in the Dropbox app, they receive a separate invitation from
Dropbox. To use Dropbox single sign-on, invitees must accept the invitation by clicking a link in it.
Box
You can enable users to authenticate Box guest users with their Azure AD account by using federation that's
based on the SAML protocol. In this procedure, you upload metadata to Box.com.
1. Add the Box app from the enterprise apps.
2. Configure single sign-on in the following order:
a. In the Sign on URL box, ensure that the sign-on URL is set appropriately for Box in the Azure portal.
This URL is the URL of your Box.com tenant. It should follow the naming convention https://.box.com.
The Identifier does not apply to this app, but it still appears as a mandatory field.
b. In the User identifier box, enter user.mail (for SSO for guest accounts).
c. Under SAML Signing Certificate, click Create new certificate.
d. To begin configuring your Box.com tenant to use Azure AD as an identity provider, download the
metadata file and then save it to your local drive.
e. Forward the metadata file to the Box support team, which configures single sign-on for you.
3. For Azure AD automatic user setup, in the left pane, select Provisioning, and then select Authorize.
Like Dropbox invitees, Box invitees must redeem their invitation from the Box app.
Next steps
See the following articles on Azure AD B2B collaboration:
B2B collaboration user claims mapping in Azure
Active Directory
Azure Active Directory (Azure AD) supports customizing the claims issued in the SAML token for B2B
collaboration users. When a user authenticates to the application, Azure AD issues a SAML token to the app that
contains information (or claims) about the user that uniquely identifies them. By default, this includes the user's
user name, email address, first name, and last name. You can view or edit the claims sent in the SAML token to
the application under the Attributes tab.
There are two possible reasons why you might need to edit the claims issued in the SAML token.
1. The application has been written to require a different set of claim URIs or claim values
2. Your application requires the NameIdentifier claim to be something other than the user principal name
stored in Azure Active Directory.
For information on how to add and edit claims, check out this article on claims customization, Customizing
claims issued in the SAML token for pre-integrated apps in Azure Active Directory. For B2B collaboration users,
mapping NameID and UPN cross-tenant are prevented for security reasons.
Next steps
Compare B2B collaboration and B2C in Azure Active
Directory
Both Azure Active Directory (Azure AD) B2B collaboration and Azure AD B2C allow you to work with external users
in Azure AD. But how do they compare?
B2B COLLABORATION CAPABILITIES AZURE AD B2C STAND-ALONE OFFERING
Intended for: Organizations that want to be able to Intended for: Inviting customers of your mobile and web apps,
authenticate users from a partner organization, regardless of whether individuals, institutional or organizational customers
identity provider. into your Azure AD.
Identities supported: Employees with work or school accounts, Identities supported: Consumer users with local application
partners with work or school accounts, or any email address. accounts (any email address or user name) or any supported
Soon to support direct federation. social identity with direct federation.
Which directory the partner users are in: Partner users from Which directory the customer user entities are in: In the
the external organization are managed in the same directory application directory. Managed separately from the
as employees, but annotated specially. They can be managed organization’s employee and partner directory (if any.
the same way as employees, can be added to the same
groups, and so on
Single sign-on (SSO) to all Azure AD-connected apps is SSO to customer owned apps within the Azure AD B2C
supported. For example, you can provide access to Office 365 tenants is supported. SSO to Office 365 or to other Microsoft
or on-premises apps, and to other SaaS apps such as and non-Microsoft SaaS apps is not supported.
Salesforce or Workday.
Partner lifecycle: Managed by the host/inviting organization. Customer lifecycle: Self-serve or managed by the application.
Security policy and compliance: Managed by the host/inviting Security policy and compliance: Managed by the application.
organization.
Branding: Host/inviting organization’s brand is used. Branding: Managed by application. Typically tends to be
product branded, with the organization fading into the
background.
More info: Blog post, Documentation More info: Product page, Documentation
Next steps
Getting support for B2B collaboration
Getting support for B2B collaboration
You’ve read through the documentation, you’ve done the right things, but still can’t get something to work? Open a
support ticket (requires a support plan):
1. In the Azure portal, navigate to the Help and Support blade, and select New Support Request:
Issue type: Technical
Subscription: Choose affected subscription
Service: Active Directory
Support Plan: Choose relevant support plan
2. Describe your problem:

Choose the appropriate severity that reflects you needs.
Choose Problem Type as User and Group Management
Choose Category as Adding Users (B2B)
Include any error messages such as CorrelationID, affected users, and so on.
3. For a support representative to contact you for further troubleshooting, add your contact information.
Manage access to resources with Azure Active
Directory groups
Azure Active Directory (Azure AD) is a comprehensive identity and access management solution that provides a
robust set of capabilities to manage access to on-premises and cloud applications and resources including
Microsoft online services like Office 365 and a world of non-Microsoft SaaS applications. This article provides an
overview, but if you want to start using Azure AD groups right now, follow the instructions in Managing security
groups in Azure AD. If you want to see how you can use PowerShell to manage groups in Azure Active directory
you can read more in Azure Active Directory cmdlets for group management.
NOTE
To use Azure Active Directory, you need an Azure account. If you don't have an account, you can sign up for a free Azure
account.
Within Azure AD, one of the major features is the ability to manage access to resources. These resources can be
part of the directory, as in the case of permissions to manage objects through roles in the directory, or resources
that are external to the directory, such as SaaS applications, Azure services, and SharePoint sites or on-premises
resources. There are four ways a user can be assigned access rights to a resource:
1. Direct assignment
Users can be assigned directly to a resource by the owner of that resource.
2. Group membership
A group can be assigned to a resource by the resource owner, and by doing so, granting the members of
that group access to the resource. Membership of the group can then be managed by the owner of the
group. Effectively, the resource owner delegates the permission to assign users to their resource to the
owner of the group.
3. Rule-based
The resource owner can use a rule to express which users should be assigned access to a resource. The
outcome of the rule depends on the attributes used in that rule and their values for specific users, and by
doing so, the resource owner effectively delegates the right to manage access to their resource to the
authoritative source for the attributes that are used in the rule. The resource owner still manages the rule
itself and determines which attributes and values provide access to their resource.
4. External authority
The access to a resource is derived from an external source; for example, a group that is synchronized from
an authoritative source such as an on-premises directory or a SaaS app such as WorkDay. The resource
owner assigns the group to provide access to the resource, and the external source manages the members
of the group.
Watch a video that explains access management
You can watch a short video that explains more about this:
Azure AD: Introduction to dynamic membership for groups
How does access management in Azure Active Directory work?

At the center of the Azure AD access management solution is the security group. Using a security group to
manage access to resources is a well-known paradigm, which allows for a flexible and easily understood way to
provide access to a resource for the intended group of users. The resource owner (or the administrator of the
directory) can assign a group to provide a certain access right to the resources they own. The members of the
group will be provided the access, and the resource owner can delegate the right to manage the members list of a
group to someone else, such as a department manager or a helpdesk administrator.
The owner of a group can also make that group available for self-service requests. In doing so, an end user can
search for and find the group and make a request to join, effectively seeking permission to access the resources
that are managed through the group. The owner of the group can set up the group so that join requests are
approved automatically or require approval by the owner of the group. When a user makes a request to join a
group, the join request is forwarded to the owners of the group. If one of the owners approves the request, the
requesting user is notified and the user is joined to the group. If one of the owners denies the request, the
requesting user is notified but not joined to the group.
Getting started with access management

Ready to get started? You should try out some of the basic tasks you can do with Azure AD groups. Use these
capabilities to provide specialized access to different groups of people for different resources in your
organization. A list of basic first steps are listed below.
Creating a simple rule to configure dynamic memberships for a group
Using a group to manage access to SaaS applications
Making a group available for end user self-service
Syncing an on-premises group to Azure using Azure AD Connect
Managing owners for a group
Next steps
Now that you have understood the basics of access management, here are some additional advanced capabilities
available in Azure Active Directory for managing access to your applications and resources.
Using attributes to create advanced rules
Managing security groups in Azure AD
Setting up dedicated groups in Azure AD
Graph API reference for groups
Azure Active Directory cmdlets for configuring group settings
Create a group and add members in Azure Active
Directory
This article explains how to create and populate a new group in Azure Active Directory. Use a group to perform
management tasks such as assigning licenses or permissions to a number of users or devices at once.
How do I create a group?

2. Select More services, enter User and groups in the text box, and then select Enter.
3. On the Users and groups blade, select All groups.

4. On the Users and groups - All groups blade, select the Add command.
5. On the Group blade, add a name and description for the group.
6. To select members to add to the group, select Assigned in the Membership type box, and then select
Members. For more information about how to manage the membership of a group dynamically, see
Using attributes to create advanced rules for group membership.
7. On the Members blade, select one or more users or devices to add to the group and select the Select button
at the bottom of the blade to add them to the group. The User box filters the display based on matching your
entry to any part of a user or device name. No wildcard characters are accepted in that box.
8. When you finish adding members to the group, select Create on the Group blade.
Next steps
These articles provide additional information on Azure Active Directory.
See existing groups
Manage settings of a group
Manage members of a group
Manage memberships of a group
Manage dynamic rules for users in a group
Azure Active Directory version 2 cmdlets for group
management
This article contains examples of how to use PowerShell to manage your groups in Azure Active Directory (Azure
AD). It also tells you how to get set up with the Azure AD PowerShell module. First, you must download the Azure
AD PowerShell module.
Install the Azure AD PowerShell module

To install the Azure AD PowerShell module, use the following commands:
PS C:\Windows\system32> install-module azuread
To verify that the module was installed, use the following command:
PS C:\Windows\system32> get-module azuread
ModuleType Version Name ExportedCommands

---------- --------- ---- ----------------
Binary 2.0.0.115 azuread {Add-AzureADAdministrati...}
Now you can start using the cmdlets in the module. For a full description of the cmdlets in the Azure AD module,
please refer to the online reference documentation for Azure Active Directory PowerShell Version 2.
Connect to the directory

Before you can start managing groups using Azure AD PowerShell cmdlets, you must connect your PowerShell
session to the directory you want to manage. Use the following command:
PS C:\Windows\system32> Connect-AzureAD
The cmdlet prompts you for the credentials you want to use to access your directory. In this example, we are using
karen@drumkit.onmicrosoft.com to access the demonstration directory. The cmdlet returns a confirmation to show
the session was connected successfully to your directory:
Account Environment Tenant

------- ----------- ------
Karen@drumkit.onmicrosoft.com AzureCloud 85b5ff1e-0402-400c-9e3c-0f…
Now you can start using the AzureAD cmdlets to manage groups in your directory.
Retrieve groups
To retrieve existing groups from your directory, use the Get-AzureADGroups cmdlet.
To retrieve all groups in the directory, use the cmdlet without parameters:
PS C:\Windows\system32> get-azureadgroup
The cmdlet returns all groups in the connected directory.

You can use the -objectID parameter to retrieve a specific group for which you specify the group’s objectID:
PS C:\Windows\system32> get-azureadgroup -ObjectId e29bae11-4ac0-450c-bc37-6dae8f3da61b
The cmdlet now returns the group whose objectID matches the value of the parameter you entered:
DeletionTimeStamp :
ObjectId : e29bae11-4ac0-450c-bc37-6dae8f3da61b
ObjectType : Group
Description :
DirSyncEnabled :
DisplayName : Pacific NW Support
LastDirSyncTime :
Mail :
MailEnabled : False
MailNickName : 9bb4139b-60a1-434a-8c0d-7c1f8eee2df9
OnPremisesSecurityIdentifier :
ProvisioningErrors : {}
ProxyAddresses : {}
SecurityEnabled : True
You can search for a specific group using the -filter parameter. This parameter takes an ODATA filter clause and
returns all groups that match the filter, as in the following example:
PS C:\Windows\system32> Get-AzureADGroup -Filter "DisplayName eq 'Intune Administrators'"
DeletionTimeStamp :
ObjectId : 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df
ObjectType : Group
Description : Intune Administrators
DirSyncEnabled :
DisplayName : Intune Administrators
LastDirSyncTime :
Mail :
MailEnabled : False
MailNickName : 4dd067a0-6515-4f23-968a-cc2ffc2eff5c
ProxyAddresses : {}
NOTE
The Azure AD PowerShell cmdlets implement the OData query standard. For more information, see $filter in OData system
query options using the OData endpoint.
Create groups
To create a new group in your directory, use the New-AzureADGroup cmdlet. This cmdlet creates a new security
group called “Marketing":
PS C:\Windows\system32> New-AzureADGroup -Description "Marketing" -DisplayName "Marketing" -MailEnabled $false
-SecurityEnabled $true -MailNickName "Marketing"
Update groups
To update an existing group, use the Set-AzureADGroup cmdlet. In this example, we’re changing the DisplayName
property of the group “Intune Administrators.” First, we’re finding the group using the Get-AzureADGroup cmdlet
and filter using the DisplayName attribute:
DeletionTimeStamp :
ObjectType : Group
Description : Intune Administrators
DirSyncEnabled :
LastDirSyncTime :
Mail :
MailEnabled : False
ProxyAddresses : {}
Next, we’re changing the Description property to the new value “Intune Device Administrators”:
PS C:\Windows\system32> Set-AzureADGroup -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -Description "Intune

Device Administrators"
Now if we find the group again, we see the Description property is updated to reflect the new value:
DeletionTimeStamp :
ObjectType : Group
Description : Intune Device Administrators
DirSyncEnabled :
LastDirSyncTime :
Mail :
MailEnabled : False
ProxyAddresses : {}
Delete groups
To delete groups from your directory, use the Remove-AzureADGroup cmdlet as follows:
PS C:\Windows\system32> Remove-AzureADGroup -ObjectId b11ca53e-07cc-455d-9a89-1fe3ab24566b
Manage group membership

Add members
To add new members to a group, use the Add-AzureADGroupMember cmdlet. This command adds a member to
the Intune Administrators group we used in the previous example:
PS C:\Windows\system32> Add-AzureADGroupMember -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -RefObjectId

72cd4bbd-2594-40a2-935c-016f3cfeeeea
The -ObjectId parameter is the ObjectID of the group to which we want to add a member, and the -RefObjectId is
the ObjectID of the user we want to add as a member to the group.
Get members
To get the existing members of a group, use the Get-AzureADGroupMember cmdlet, as in this example:
PS C:\Windows\system32> Get-AzureADGroupMember -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df
DeletionTimeStamp ObjectId ObjectType

----------------- -------- ----------
72cd4bbd-2594-40a2-935c-016f3cfeeeea User
8120cc36-64b4-4080-a9e8-23aa98e8b34f User
Remove members
To remove the member we previously added to the group, use the Remove-AzureADGroupMember cmdlet, as is
shown here:
PS C:\Windows\system32> Remove-AzureADGroupMember -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -MemberId

Verify members
To verify the group memberships of a user, use the Select-AzureADGroupIdsUserIsMemberOf cmdlet. This cmdlet
takes as its parameters the ObjectId of the user for which to check the group memberships, and a list of groups for
which to check the memberships. The list of groups must be provided in the form of a complex variable of type
“Microsoft.Open.AzureAD.Model.GroupIdsForMembershipCheck”, so we first must create a variable with that type:
PS C:\Windows\system32> $g = new-object Microsoft.Open.AzureAD.Model.GroupIdsForMembershipCheck
Next, we provide values for the groupIds to check in the attribute “GroupIds” of this complex variable:
PS C:\Windows\system32> $g.GroupIds = "b11ca53e-07cc-455d-9a89-1fe3ab24566b", "31f1ff6c-d48c-4f8a-b2e1-

abca7fd399df"
Now, if we want to check the group memberships of a user with ObjectID 72cd4bbd-2594-40a2-935c-
016f3cfeeeea against the groups in $g, we should use:
PS C:\Windows\system32> Select-AzureADGroupIdsUserIsMemberOf -ObjectId 72cd4bbd-2594-40a2-935c-016f3cfeeeea -
GroupIdsForMembershipCheck $g
OdataMetadata
Value
-------------
-----
https://graph.windows.net/85b5ff1e-0402-400c-9e3c-0f9e965325d1/$metadata#Collection(Edm.String)
{31f1ff6c-d48c-4f8a-b2e1-abca7fd399df}
The value returned is a list of groups of which this user is a member. You can also apply this method to check
Contacts, Groups or Service Principals membership for a given list of groups, using Select-
AzureADGroupIdsContactIsMemberOf, Select-AzureADGroupIdsGroupIsMemberOf or Select-
AzureADGroupIdsServicePrincipalIsMemberOf
Disable group creation by your users

You can prevent non-admin users from creating security groups. The default behavior in Microsoft Online
Directory Services (MSODS) is to allow non-admin users to create groups, whether or not self-service group
management (SSGM) is also enabled. The SSGM setting controls behavior only in the My Apps access panel.
To disable group creation for non-admin users:
1. Verify that non-admin users are allowed to create groups:
PS C:\> Get-MsolCompanyInformation | fl UsersPermissionToCreateGroupsEnabled
2. If it returns UsersPermissionToCreateGroupsEnabled : True , then non-admin users can create groups. To

disable this feature:
Set-MsolCompanySettings -UsersPermissionToCreateGroupsEnabled $False
Manage owners of groups

To add owners to a group, use the Add-AzureADGroupOwner cmdlet:
PS C:\Windows\system32> Add-AzureADGroupOwner -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -RefObjectId

The -ObjectId parameter is the ObjectID of the group to which we want to add an owner, and the -RefObjectId is
the ObjectID of the user we want to add as an owner of the group.
To retrieve the owners of a group, use the Get-AzureADGroupOwner cmdlet:
PS C:\Windows\system32> Get-AzureADGroupOwner -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df
The cmdlet returns the list of owners for the specified group:
DeletionTimeStamp ObjectId ObjectType

----------------- -------- ----------
e831b3fd-77c9-49c7-9fca-de43e109ef67 User
If you want to remove an owner from a group, use the Remove-AzureADGroupOwner cmdlet:
PS C:\Windows\system32> remove-AzureADGroupOwner -ObjectId 31f1ff6c-d48c-4f8a-b2e1-abca7fd399df -OwnerId
e831b3fd-77c9-49c7-9fca-de43e109ef67
Reserved aliases
When a group is created, certain endpoints allow the end user to specify a mailNickname or alias to be used as part
of the email address of the group. Groups with the following highly privileged email aliases can only be created by
an Azure AD global administrator.
abuse
admin
administrator
hostmaster
majordomo
postmaster
root
secure
security
ssl-admin
webmaster
Next steps
You can find more Azure Active Directory PowerShell documentation at Azure Active Directory Cmdlets.
Integrating your on-premises identities with Azure Active Directory
Manage group membership for users in your Azure
Active Directory tenant
This article explains how to manage the members for a group in Azure Active Directory (Azure AD).
How do I find the members and manage them?


4. On the Users and groups - All groups blade, select a group.
5. On the Group - *groupname* blade, select Members.
6. To add members to the group, on the Group - Members blade, select Add Members.
7. On the Members blade, select one or more users or devices to add to the group and select the Select button
at the bottom of the blade to add them to the group. The User box filters the display based on matching your
entry to any part of a user or device name. No wildcard characters are accepted in that box.
8. To remove members from the group, on the Group - Members blade, select a member.
9. On the membername blade, select the Remove command, and confirm your choice at the prompt.
10. When you finish changing members for the group, select Save.
Additional information
See existing groups
Create a new group and adding members
Managing owners for a group
Once a resource owner has assigned access to a resource to an Azure AD group, the membership of the group is
managed by the group owner. The resource owner effectively delegates the permission to assign users to the
resource to the owner of the group.
Add an owner to a group

1. In the Azure AD admin center, select Users and groups.
2. Select All groups, and then open the group that you want to add owners to.
3. Select Add Owners.
4. On the Add owners page, select the user that you want to add as the owner of this group, and make sure this
name is added to the Selected pane.
Remove an owner from a group

1. In the Azure AD admin center, select Users and groups.
2. Select All groups, and then open the group from which you want to remove owners.
3. Select the Owners tab.
4. Select the owner that you want to remove from this group, and then select Remove.
Manage to which groups a group belongs in your
Azure Active Directory tenant
Groups can contain other groups in Azure Active Directory. Here's how to manage those memberships.
How do I find the groups of which my group is a member?

3. Select All groups.

4. Select a group.
5. Select Group memberships.
6. To add your group as a member of another group, on the Group - Group memberships blade, select the Add
command.
7. Select a group from the Select Group blade, and then select the Select button at the bottom of the blade.
You can add your group to only one group at a time. The User box filters the display based on matching
your entry to any part of a user or device name. No wildcard characters are accepted in that box.
8. To remove your group as a member of another group, on the Group - Group memberships blade, select a
group.
9. Select the Remove command, and confirm your choice at the prompt.
10. When you finish changing group memberships for your group, select Save.
See existing groups
Group-based licensing basics in Azure Active
Directory
Using Microsoft paid cloud services, such as Office 365, Enterprise Mobility + Security, Dynamics CRM, and other
similar products, requires licenses. These licenses are assigned to each user who needs access to these services. To
manage licenses, administrators use one of the management portals (Office or Azure) and PowerShell cmdlets.
Azure Active Directory (Azure AD) is the underlying infrastructure that supports identity management for all
Microsoft cloud services. Azure AD stores information about license assignment states for users.
Until now, licenses could only be assigned at the individual user level, which can make large-scale management
difficult. For example, to add or remove user licenses based on organizational changes, such as users joining or
leaving the organization or a department, an administrator often must write a complex PowerShell script. This
script makes individual calls to the cloud service.
To address those challenges, Azure AD now includes group-based licensing. You can assign one or more product
licenses to a group. Azure AD ensures that the licenses are assigned to all members of the group. Any new
members who join the group are assigned the appropriate licenses. When they leave the group, those licenses are
removed. This eliminates the need for automating license management via PowerShell to reflect changes in the
organization and departmental structure on a per-user basis.
Features
Here are the main features of group-based licensing:
Licenses can be assigned to any security group in Azure AD. Security groups can be synced on-premises, by
using Azure AD Connect. You can also create security groups directly in Azure AD (also called cloud-only
groups), or automatically via the Azure AD dynamic group feature.
When a product license is assigned to a group, the administrator can disable one or more service plans in
the product. Typically, this is done when the organization is not yet ready to start using a service included in
a product. For example, the administrator might assign Office 365 to a department, but temporarily disable
the Yammer service.
All Microsoft cloud services that require user-level licensing are supported. This includes all Office 365
products, Enterprise Mobility + Security, and Dynamics CRM.
Group-based licensing is currently available only through the Azure portal. If you primarily use other
management portals for user and group management, such as the Office 365 portal, you can continue to
do so. But you should use the Azure portal to manage licenses at group level.
Azure AD automatically manages license modifications that result from group membership changes.
Typically, license modifications are effective within minutes of a membership change.
A user can be a member of multiple groups with license policies specified. A user can also have some
licenses that were directly assigned, outside of any groups. The resulting user state is a combination of all
assigned product and service licenses.
In some cases, licenses cannot be assigned to a user. For example, there might not be enough available
licenses in the tenant, or conflicting services might have been assigned at the same time. Administrators
have access to information about users for whom Azure AD could not fully process group licenses. They
can then take corrective action based on that information.
During public preview, a paid or trial subscription for Azure AD Basic or Premium editions is required in the
tenant to use group-based license management.
Your feedback is welcome!

If you have feedback or feature requests, please share them with us using this forum.
Next steps
To learn more about other scenarios for license management through group-based licensing, see:
Get started with licenses in Azure Active Directory
Assigning licenses to a group in Azure Active Directory
Identifying and resolving license problems for a group in Azure Active Directory
How to migrate individual licensed users to group-based licensing in Azure Active Directory
Azure Active Directory group-based licensing additional scenarios
Assign licenses to users by group membership in
This article walks you through assigning product licenses to a group of users in Azure Active Directory (Azure AD)
and then verifying that they're licensed correctly.
In this example, the tenant contains a security group called HR Department. This group includes all members of
the human resources department (around 1,000 users). You want to assign Office 365 Enterprise E3 licenses to the
entire department. The Yammer Enterprise service that's included in the product must be temporarily disabled
until the department is ready to start using it. You also want to deploy Enterprise Mobility + Security licenses to
the same group of users.
NOTE
Some Microsoft services are not available in all locations. Before a license can be assigned to a user, the administrator has to
specify the Usage location property on the user.
For group license assignment, any users without a usage location specified will inherit the location of the directory. If you
have users in multiple locations, we recommend that you always set usage location as part of your user creation flow in
Azure AD (e.g. via AAD Connect configuration) - that will ensure the result of license assignment is always correct and users
do not receive services in locations that are not allowed.
Step 1: Assign the required licenses

1. Sign in to the Azure portal with an Administrator account. To manage licenses, the account must be a
global administrator role or user account administrator.
2. Select More services in the left navigation pane, and then select Azure Active Directory. You can add this
blade to Favorites or pin it to the portal dashboard.
3. On the Azure Active Directory blade, select Licenses. This opens a blade where you can see and manage
all licensable products in the tenant.
4. Under All products, select both Office 365 Enterprise E3 and Enterprise Mobility + Security by selecting the
product names. To start the assignment, select Assign at the top of the blade.
5. On the Assign license blade, click Users and groups to open the Users and groups blade. Search for the
group name HR Department, select the group, and then be sure to confirm by clicking Select at the bottom
of the blade.
6. On the Assign license blade, click Assignment options (optional), which displays all service plans
included in the two products that we selected previously. Find Yammer Enterprise and turn it Off to
disable that service from the product license. Confirm by clicking OK at the bottom of Assignment
options.
7. To complete the assignment, on the Assign license blade, click Assign at the bottom of the blade.
8. A notification is displayed in the upper-right corner that shows the status and outcome of the process. If the
assignment to the group couldn't be completed (for example, because of pre-existing licenses in the group),
click the notification to view details of the failure.
We've now specified a license template for the HR Department group. A background process in Azure AD has been
started to process all existing members of that group. This initial operation might take some time, depending on
the current size of the group. In the next step, we'll describe how to verify that the process has finished and
determine if further attention is required to resolve problems.
NOTE
You can start the same assignment from an alternative location: Users and groups in Azure AD. Go to Azure Active
Directory > Users and groups > All groups. Then find the group, select it, and go to the Licenses tab. The Assign button
on top of the blade opens the license assignment blade.
Step 2: Verify that the initial assignment has finished

1. Go to Azure Active Directory > Users and groups > All groups. Then find the HR Department group
that licenses were assigned to.
2. On the HR Department group blade, select Licenses. This lets you quickly confirm if licenses have been
fully assigned to users and if there are any errors that you need to look into. The following information is
available:
List of product licenses that are currently assigned to the group. Select an entry to show the specific
services that have been enabled and to make changes.
Status of the latest license changes that were made to the group (if the changes are being processed
or if processing has finished for all user members).
Information about users who are in an error state because licenses couldn't be assigned to them.
3. See more detailed information about license processing under Azure Active Directory > Users and
groups > group name > Audit logs. Note the following activities:
Activity: Start applying group based license to users. This is logged when the system picks up the
license-assignment change on the group and starts applying it to all user members. It contains
information about the change that was made.
Activity: Finish applying group based license to users. This is logged when the system finishes
processing all users in the group. It contains a summary of how many users were successfully
processed and how many users couldn't be assigned group licenses.
Read this section to learn more about how audit logs can be used to analyze changes made by group-based
licensing.
Step 3: Check for license problems and resolve them

1. Go to Azure Active Directory > Users and groups > All groups, and find the HR Department group that
licenses were assigned to.
2. On the HR Department group blade, select Licenses. The notification on top of the blade shows that there are
10 users that licenses couldn't be assigned to. Clicking it opens a list of all users in a licensing-error state for
this group.
3. The Failed assignments column tells us that both product licenses couldn't be assigned to the users. The
Top reason for failure column contains the cause of the failure. In this case, it's Conflicting service
plans.
4. Select a user to open the Licenses blade. This blade shows all licenses that are currently assigned to the
user. In this example, the user has the Office 365 Enterprise E1 license that was inherited from the Kiosk
users group. This conflicts with the E3 license that the system tried to apply from the HR Department
group. As a result, none of the licenses from that group has been assigned to the user.
5. To solve this conflict, remove the user from the Kiosk users group. After Azure AD processes the change,
the HR Department licenses are correctly assigned.
Next steps
To learn more about the feature set for license management through groups, see the following articles:
What is group-based licensing in Azure Active Directory?
Identify and resolve license assignment problems for
a group in Azure Active Directory
Group-based licensing in Azure Active Directory (Azure AD) introduces the concept of users in a licensing error
state. In this article, we explain the reasons why users might end up in this state.
When you assign licenses directly to individual users, without using group-based licensing, the assignment
operation might fail. For example, when you execute the PowerShell cmdlet Set-MsolUserLicense on a user
system, the cmdlet can fail for many reasons that are related to business logic. For example, there might be an
insufficient number of licenses or a conflict between two service plans that can't be assigned at the same time. The
problem is immediately reported back to you.
When you're using group-based licensing, the same errors can occur, but they happen in the background while
the Azure AD service is assigning licenses. For this reason, the errors can't be communicated to you immediately.
Instead, they're recorded on the user object and then reported via the administrative portal. The original intent to
license the user is never lost, but it's recorded in an error state for future investigation and resolution.
How to find license assignment errors

To find license assignment errors
1. To find users in an error state in a specific group, open the pane for the group. Under Licenses, a
notification appears if there are any users in an error state.
2. Select the notification to open a list of all affected users. You can select each user individually to see more
details.
3. To find all groups that contain at least one error, on the Azure Active Directory blade select Licenses, and
then select Overview. An information box is displayed when groups require your attention.
4. Select the box to see a list of all groups with errors. You can select each group for more details.
The following sections give a description of each potential problem and the way to resolve it.
Not enough licenses

Problem: There aren't enough available licenses for one of the products that's specified in the group. You need to
either purchase more licenses for the product or free up unused licenses from other users or groups.
To see how many licenses are available, go to Azure Active Directory > Licenses > All products.
To see which users and groups are consuming licenses, select a product. Under Licensed users, you see a list of all
users who have had licenses assigned directly or via one or more groups. Under Licensed groups, you see all
groups that have that products assigned.
PowerShell: PowerShell cmdlets report this error as CountViolation.
Conflicting service plans

Problem: One of the products that's specified in the group contains a service plan that conflicts with another
service plan that's already assigned to the user via a different product. Some service plans are configured in a way
that they can't be assigned to the same user as another, related service plan.
Consider the following example. A user has a license for Office 365 Enterprise E1 assigned directly, with all the
plans enabled. The user has been added to a group that has the Office 365 Enterprise E3 product assigned to it.
The E3 product contains service plans that can't overlap with the plans that are included in E1, so the group license
assignment fails with the “Conflicting service plans” error. In this example, the conflicting service plans are:
SharePoint Online (Plan 2) conflicts with SharePoint Online (Plan 1).
Exchange Online (Plan 2) conflicts with Exchange Online (Plan 1).
To solve this conflict, you need to disable two of the plans. You can disable the E1 license that's directly assigned to
the user. Or, you need to modify the entire group license assignment and disable the plans in the E3 license.
Alternatively, you might decide to remove the E1 license from the user if it's redundant in the context of the E3
license.
The decision about how to resolve conflicting product licenses always belongs to the administrator. Azure AD
doesn't automatically resolve license conflicts.
PowerShell: PowerShell cmdlets report this error as MutuallyExclusiveViolation.
Other products depend on this license

Problem: One of the products that's specified in the group contains a service plan that must be enabled for
another service plan, in another product, to function. This error occurs when Azure AD attempts to remove the
underlying service plan. For example, this can happen when you remove the user from the group.
To solve this problem, you need to make sure that the required plan is still assigned to users through some other
method or that the dependent services are disabled for those users. After doing that, you can properly remove the
group license from those users.
PowerShell: PowerShell cmdlets report this error as DependencyViolation.
Usage location isn't allowed

Problem: Some Microsoft services aren't available in all locations because of local laws and regulations. Before
you can assign a license to a user, you must specify the Usage location property for the user. You can specify the
location under the User > Profile > Settings section in the Azure portal.
When Azure AD attempts to assign a group license to a user whose usage location isn't supported, it fails and
records an error on the user.
To solve this problem, remove users from nonsupported locations from the licensed group. Alternatively, if the
current usage location values don't represent the actual user location, you can modify them so that the licenses are
correctly assigned next time (if the new location is supported).
PowerShell: PowerShell cmdlets report this error as ProhibitedInUsageLocationViolation.
NOTE
When Azure AD assigns group licenses, any users without a specified usage location inherit the location of the directory. We
recommend that administrators set the correct usage location values on users before using group-based licensing to comply
with local laws and regulations.
What happens when there's more than one product license on a

group?
You can assign more than one product license to a group. For example, you can assign Office 365 Enterprise E3
and Enterprise Mobility + Security to a group to easily enable all included services for users.
Azure AD attempts to assign all licenses that are specified in the group to each user. If Azure AD can't assign one of
the products because of business logic problems, it won't assign the other licenses in the group either. An example
is if there aren't enough licenses for all, or if there are conflicts with other services that are enabled on the user.
You can see the users who failed to get assigned and check which products are affected by this problem.
How do you manage licenses for products with prerequisites?

Some Microsoft Online products you might own are add-ons. Add-ons require a prerequisite service plan to be
enabled for a user or a group before they can be assigned a license. With group-based licensing, the system
requires that both the prerequisite and add-on service plans be present in the same group. This is done to ensure
that any users who are added to the group can receive the fully working product. Let's consider the following
example:
Microsoft Workplace Analytics is an add-on product. It contains a single service plan with the same name. We can
only assign this service plan to a user, or group, when one of the following prerequisites is also assigned:
Exchange Online (Plan 1)
Exchange Online (Plan 2)
If we try to assign this product on its own to a group, the portal returns an error. Selecting the error notification
shows the following details:
If we select the details, it shows the following error message:
License operation failed. Make sure that the group has necessary services before adding or removing a
dependent service. The service Microsoft Workplace Analytics requires Exchange Online (Plan 2) to be
enabled as well.
To assign this add-on license to a group, we must ensure that the group also contains the prerequisite service plan.
For example, we might update an existing group that already contains the full Office 365 E3 product, and then add
the add-on product to it.
It is also possible to create a standalone group that contains only the minimum required products to make the
add-on work. It can be used to license only the selected users for the add-on product. In this example, we have
assigned the following products to the same group:
Office 365 Enterprise E3 with only the Exchange Online (Plan 2) service plan enabled
Microsoft Workplace Analytics
From now on, any users added to this group consume one license of the E3 product and one license of the
Workplace Analytics product. At the same time, those users can be members of another group that gives them the
full E3 product, and they still consume only one license for that product.
TIP
You can create multiple groups for each prerequisite service plan. For example, if you use both Office 365 Enterprise E1 and
Office 365 Enterprise E3 for your users, you can create two groups to license Microsoft Workplace Analytics: one that uses
E1 as a prerequisite and the other that uses E3. This lets you distribute the add-on to E1 and E3 users without consuming
additional licenses.
License assignment fails silently for a user due to duplicate proxy

addresses in Exchange Online
If you use Exchange Online, some users in your tenant might be incorrectly configured with the same proxy
address value. When group-based licensing tries to assign a license to such a user, it fails and does not record an
error. The failure to record the error in this instance is a limitation in the preview version of this feature, and we are
going to address it before General Availability.
TIP
If you notice that some users did not receive a license and there is no error recorded for those users, first check if they have
a duplicate proxy address. To see if there is a duplicate proxy address, execute the following PowerShell cmdlet against
Exchange Online:
Run Get-Recipient | where {$_.EmailAddresses -match "user@contoso.onmicrosoft.com"} | fL Name,

RecipientType,emailaddresses
For more information about this problem, see "Proxy address is already being used" error message in Exchange Online. The
article also includes information on how to connect to Exchange Online by using remote PowerShell.
After you resolve any proxy address problems for the affected users, make sure to force license processing on the
group to make sure that the licenses can now be applied.
How do you force license processing in a group to resolve errors?

Depending on what steps you've taken to resolve the errors, it might be necessary to manually trigger the
processing of a group to update the user state.
For example, if you free up some licenses by removing direct license assignments from users, you need to trigger
the processing of groups that previously failed to fully license all user members. To reprocess a group, go to the
group pane, open Licenses, and then select the Reprocess button on the toolbar.
Next steps
To learn more about other scenarios for license management through groups, see the following:
How to add licensed users to a group for licensing in
You may have existing licenses deployed to users in the organizations via “direct assignment”; that is, using
PowerShell scripts or other tools to assign individual user licenses. If you would like to start using group-based
licensing to manage licenses in your organization, you will need a migration plan to seamlessly replace existing
solutions with group-based licensing.
The most important thing to keep in mind is that you should avoid a situation where migrating to group-based
licensing will result in users temporarily losing their currently assigned licenses. Any process that may result in
removal of licenses should be avoided to remove the risk of users losing access to services and their data.
Recommended migration process

1. You have existing automation (for example, PowerShell) managing license assignment and removal for
users. Leave it running as is.
2. Create a new licensing group (or decide which existing groups to use) and make sure that all required users
are added as members.
3. Assign the required licenses to those groups; your goal should be to reflect the same licensing state your
existing automation (for example, PowerShell) is applying to those users.
4. Verify that licenses have been applied to all users in those groups. This can be done by checking the
processing state on each group and by checking Audit Logs.
You can spot check individual users by looking at their license details. You will see that they have the
same licenses assigned “directly” and “inherited” from groups.
You can run a PowerShell script to verify how licenses are assigned to users.
When the same product license is assigned to the user both directly and through a group, only one
license is consumed by the user. Hence no additional licenses are required to perform migration.
5. Verify that no license assignments failed by checking each group for users in error state. For more
information, see Identifying and resolving license problems for a group.
6. Consider removing the original direct assignments; you may want to do it gradually, in “waves”, to monitor
the outcome on a subset of users first.
You could leave the original direct assignments on users, but when the users leave their licensed groups
they will still retain the original license, which is possibly not want you want.
An example
We have an organization with 1,000 users. All users require Enterprise Mobility + Security (EMS) licenses. 200
users are in the Finance Department and require Office 365 Enterprise E3 licenses. We have a PowerShell script
running on premises adding and removing licenses from users as they come and go. We want to replace the script
with group-based licensing so licenses are managed automatically by Azure AD.
Here is what the migration process could look like:
1. Using the Azure portal assign the EMS license to the All users group in Azure AD. Assign the E3 license to
the Finance department group that contains all the required users.
2. For each group, confirm that license assignment has completed for all users. Go to the blade for each group,
select Licenses, and check the processing status at the top of the Licenses blade.
Look for “Latest license changes have been applied to all users" to confirm processing has
completed.
Look for a notification on top about any users for whom licenses may have not been successfully
assigned. Did we run out of licenses for some users? Do some users have conflicting license SKUs
that prevent them from inheriting group licenses?
3. Spot check some users to verify that they have both the direct and group licenses applied. Go to the blade
for a user, select Licenses, and examine the state of licenses.
This is the expected user state during migration:
This confirms that the user has both direct and inherited licenses. We see that both EMS and E3 are
assigned.
Select each license to show details about the enabled services. This can be used to check if the direct
and group licenses enable exactly the same service plans for the user.
4. After confirming that both direct and group licenses are equivalent, you can start removing direct licenses
from users. You can test this by removing them for individual users in the portal and then run automation
scripts to have them removed in bulk. Here is an example of the same user with the direct licenses removed
through the portal. Notice that the license state remains unchanged, but we no longer see direct
assignments.
Next steps
To learn more about other scenarios for license management through groups, read
Scenarios, limitations, and known issues using groups
to manage licensing in Azure Active Directory
Use the following information and examples to gain a more advanced understanding of Azure Active Directory
(Azure AD) group-based licensing.
Usage location
Some Microsoft services are not available in all locations. Before a license can be assigned to a user, the
administrator has to specify the Usage location property on the user. In the Azure portal, you can specify in User
> Profile > Settings.
For group license assignment, any users without a usage location specified will inherit the location of the directory.
If you have users in multiple locations, make sure to reflect that correctly in your user objects before adding users
to groups with licenses.
NOTE
Group license assignment will never modify an existing usage location value on a user. We recommend that you always set
usage location as part of your user creation flow in Azure AD (e.g. via AAD Connect configuration) - that will ensure the
result of license assignment is always correct, and users do not receive services in locations that are not allowed.
Use group-based licensing with dynamic groups

You can use group-based licensing with any security group, which means it can be combined with Azure AD
dynamic groups. Dynamic groups run rules against user object attributes to automatically add and remove users
from groups.
For example, you can create a dynamic group for some set of products you want to assign to users. Each group is
populated by a rule adding users by their attributes, and each group is assigned the licenses that you want them to
receive. You can assign the attribute on-premises and sync it with Azure AD, or you can manage the attribute
directly in the cloud.
Licenses are assigned to the user shortly after they are added to the group. When the attribute is changed, the user
leaves the groups and the licenses are removed.
Example
Consider the example of an on-premises identity management solution that decides which users should have
access to Microsoft web services. It uses extensionAttribute1 to store a string value representing the licenses the
user should have. Azure AD Connect syncs it with Azure AD.
Users might need one license but not another, or might need both. Here's an example, in which you are
distributing Office 365 Enterprise E5 and Enterprise Mobility + Security (EMS) licenses to users in groups:
Office 365 Enterprise E5: base services
Enterprise Mobility + Security: licensed users
For this example, modify one user and set their extensionAttribute1 to the value of EMS;E5_baseservices; if you
want the user to have both licenses. You can make this modification on-premises. After the change syncs with the
cloud, the user is automatically added to both groups, and licenses are assigned.
WARNING
Use caution when modifying an existing group’s membership rule. When a rule is changed, the membership of the group
will be re-evaluated and users who no longer match the new rule will be removed (users who still match the new rule will
not be affected during this process). Those users will have their licenses removed during the process which may result in loss
of service, or in some cases, loss of data.
If you have a large dynamic group you depend on for license assignment, consider validating any major changes on a
smaller test group before applying them to the main group.
Multiple groups and multiple licenses

A user can be a member of multiple groups with licenses. Here are some things to consider:
Multiple licenses for the same product can overlap, and they result in all enabled services being applied to
the user. The following example shows two licensing groups: E3 base services contains the foundation
services to deploy first, to all users. And E3 extended services contains additional services (Sway and
Planner) to deploy only to some users. In this example, the user was added to both groups:
As a result, the user has 7 of the 12 services in the product enabled, while using only one license for this
product.
Selecting the E3 license shows more details, including information about which groups caused what
services to be enabled for the user.
Direct licenses coexist with group licenses

When a user inherits a license from a group, you can't directly remove or modify that license assignment in the
user's properties. Changes must be made in the group and then propagated to all users.
It is possible, however, to assign the same product license directly to the user, in addition to the inherited license.
You can enable additional services from the product just for one user, without affecting other users.
Directly assigned licenses can be removed, and don’t affect inherited licenses. Consider the user who inherits an
Office 365 Enterprise E3 license from a group.
1. Initially, the user inherits the license only from the E3 basic services group, which enables four service plans,
as shown:
2. You can select Assign to directly assign an E3 license to the user. In this case, you are going to disable all
service plans except Yammer Enterprise:
3. As a result, the user still uses only one license of the E3 product. But the direct assignment enables the
Yammer Enterprise service for that user only. You can see which services are enabled by the group
membership versus the direct assignment:
4. When you use direct assignment, the following operations are allowed:
Yammer Enterprise can be turned off on the user object directly. The On/Off toggle in the illustration
was enabled for this service, as opposed to the other service toggles. Because the service is enabled
directly on the user, it can be modified.
Additional services can be enabled as well, as part of the directly assigned license.
The Remove button can be used to remove the direct license from the user. You can see that the
user now only has the inherited group license and only the original services remain enabled:
Managing new services added to products
When Microsoft adds a new service to a product, it will be enabled by default in all groups to which you have
assigned the product license. Users in your tenant who are subscribed to notifications about product changes will
receive emails ahead of time notifying them about the upcoming service additions.
As an administrator, you can review all groups affected by the change and take action, such as disabling the new
service in each group. For example, if you created groups targeting only specific services for deployment, you can
revisit those groups and make sure that any newly added services are disabled.
Here is an example of what this process may look like:
1. Originally, you assigned the Office 365 Enterprise E5 product to several groups. One of those groups, called
O365 E5 - Exchange only was designed to enable only the Exchange Online (Plan 2) service for its
members.
2. You received a notification from Microsoft that the E5 product will be extended with a new service -
Microsoft Stream. When the service becomes available in your tenant, you can do the following:
3. Go to the Azure Active Directory > Licenses > All products blade and select Office 365 Enterprise E5,
then select Licensed Groups to view a list of all groups with that product.
4. Click on the group you want to review (in this case, O365 E5 - Exchange only). This will open the Licenses
tab. Clicking on the E5 license will open a blade listing all enabled services.
NOTE
The Microsoft Stream service has been automatically added and enabled in this group, in addition to the Exchange
Online service:
5. If you want to disable the new service in this group, click the On/Off toggle next to the service and click the
Save button to confirm the change. Azure AD will now process all users in the group to apply the change;
any new users added to the group will not have the Microsoft Stream service enabled.
NOTE
Users may still have the service enabled through some other license assignment (another group they are members
of or a direct license assignment).
6. If needed, perform the same steps for other groups with this product assigned.
Use PowerShell to see who has inherited and direct licenses

You can use a PowerShell script to check if users have a license assigned directly or inherited from a group.
1. Run the connect-msolservice cmdlet to authenticate and connect to your tenant.
2. Get-MsolAccountSku can be used to discover all provisioned product licenses in the tenant.
3. Use the AccountSkuId value for the license you are interested in with this PowerShell script. This will
produce a list of users who have this license with the information about how the license is assigned.
Use Audit logs to monitor group-based licensing activity
You can use Azure AD audit logs to see all activity related to group-based licensing, including:
who changed licenses on groups
when the system started processing a group license change, and when it finished
what license changes were made to a user as a result of a group license assignment.
NOTE
Audit logs are available on most blades in the Azure Active Directory section of the portal. Depending on where you access
them, filters may be pre-applied to only show activity relevant to the context of the blade. If you are not seeing the results
you expect, examine the filtering options or access the unfiltered audit logs under Azure Active Directory > Activity >
Audit logs.
Find out who modified a group license

1. Set the Activity filter to Set group license and click Apply.
2. The results include all cases of licenses being set or modified on groups.
TIP
You can also type the name of the group in the Target filter to scope the results.
3. Click an item in the list view to see the details of what has changed. Under Modified Properties both old and
new values for the license assignment are listed.
Here is an example of recent group license changes, with details:
Find out when group changes started and finished processing

When a license changes on a group, Azure AD will start applying the changes to all users.
1. To see when groups started processing, set the Activity filter to Start applying group based license to users.
Note that the actor for the operation is Microsoft Azure AD Group-Based Licensing - a system account that
is used to execute all group license changes.
TIP
Click an item in the list to see the Modified Properties field - it shows the license changes that were picked up for
processing. This is useful if you made multiple changes to a group and you are not sure which one was processed.
2. Similarly, to see when groups finished processing, use the filter value Finish applying group based license
to users.
TIP
In this case, the Modified Properties field contains a summary of the results - this is useful to quickly check if
processing resulted in any errors. Sample output:
Modified Properties
...
Name : Result
Old Value : []
New Value : [Users successfully assigned licenses: 6, Users for whom license assignment failed:
0.];
3. To see the complete log for how a group was processed, including all user changes, set the following filters:
Initiated By (Actor): "Microsoft Azure AD Group-Based Licensing"
Date Range (optional): custom range for when you know a specific group started and finished
processing
This sample output shows the start of processing, all resulting user changes, and the finish of processing.
TIP
Clicking items related to Change user license will show details for license changes applied to each individual user.
Deleting a group with an assigned license

It is not possible to delete a group with an active license assigned. An administrator could delete a group not
realizing that it will cause licenses to be removed from users - for this reason we require any licenses to be
removed from the group first, before it can be deleted.
When trying to delete a group in the Azure portal you may see an error notification like this:
Go to the Licenses tab on the group and see if there are any licenses assigned. If yes, remove those licenses and
try to delete the group again.
You may see similar errors when trying to delete the group through PowerShell or Graph API. If you are using a
group synced from on-premises, Azure AD Connect may also report errors if it is failing to delete the group in
Azure AD. In all such cases, make sure to check if there are any licenses assigned to the group, and remove them
first.
Limitations and known issues

If you use group-based licensing, it's a good idea to familiarize yourself with the following list of limitations and
known issues.
Group-based licensing currently does not support groups that contain other groups (nested groups). If you
apply a license to a nested group, only the immediate first-level user members of the group have the
licenses applied.
The feature can only be used with security groups. Office groups are currently not supported and you will
not be able to use them in the license assignment process.
The Office 365 admin portal does not currently support group-based licensing. If a user inherits a license
from a group, this license appears in the Office admin portal as a regular user license. If you try to modify
that license or try to remove the license, the portal returns an error message. Inherited group licenses
cannot be modified directly on a user.
When a user is removed from a group and loses the license, the service plans from that license (for
example, SharePoint Online) are set to a Suspended state. The service plans are not set to a final, disabled
state. This precaution can avoid accidental removal of user data, if an admin makes a mistake in group
membership management.
When licenses are assigned or modified for a large group (for example, 100,000 users), it could impact
performance. Specifically, the volume of changes generated by Azure AD automation might negatively
impact the performance of your directory synchronization between Azure AD and on-premises systems.
In certain high load situations, license processing may be delayed and changes such as adding/removing a
group license, or adding/removing users from group, may take a long time to be processed. If you see your
changes take more than 24 hours to process, please open a support ticket to allow us to investigate. We will
improve performance characteristics of this feature before it reaches General Availability.
License management automation does not automatically react to all types of changes in the environment.
For example, you might have run out of licenses, causing some users to be in an error state. To free up the
available seat count, you can remove some directly assigned licenses from other users. However, the
system does not automatically react to this change and fix users in that error state.
As a workaround to these types of limitations, you can go to the Group blade in Azure AD, and click
Reprocess. This command processes all users in that group and resolves the error states, if possible.
Group-based licensing does not record errors when a license could not be assigned to a user due to a
duplicate proxy address configuration in Exchange Online; such users are skipped during license
assignment. For more information about how to identify and solve this problem, see this section.
Next steps
To learn more about other scenarios for license management through group-based licensing, see:
PowerShell examples for group-based licensing in
Azure AD
Full functionality for group-based licensing is available through the Azure portal, and currently PowerShell support
is limited. However, there are some useful tasks that can be performed using the existing MSOnline PowerShell
cmdlets. This document provides examples of what is possible.
NOTE
Before you begin running cmdlets, make sure you connect to your tenant first, by running the Connect-MsolService
cmdlet.
View product licenses assigned to a group

The Get-MsolGroup cmdlet can be used to retrieve the group object and check the Licenses property: it lists all
product licenses currently assigned to the group.
(Get-MsolGroup -ObjectId 99c4216a-56de-42c4-a4ac-e411cd8c7c41).Licenses

| Select SkuPartNumber
Output:
SkuPartNumber
-------------
ENTERPRISEPREMIUM
EMSPREMIUM
NOTE
The data is limited to product (SKU) information. It is not possible to list the service plans disabled in the license.
Get all groups with licenses

You can find all groups with any license assigned by running the following command:
Get-MsolGroup | Where {$_.Licenses}
More details can be displayed about what products are assigned:
Get-MsolGroup | Where {$_.Licenses} | Select `

ObjectId, `
DisplayName, `
@{Name="Licenses";Expression={$_.Licenses | Select -ExpandProperty SkuPartNumber}}
Output:
ObjectId DisplayName Licenses
-------- ----------- --------
7023a314-6148-4d7b-b33f-6c775572879a EMS E5 – Licensed users EMSPREMIUM
cf41f428-3b45-490b-b69f-a349c8a4c38e PowerBi - Licensed users POWER\_BI\_STANDARD
962f7189-59d9-4a29-983f-556ae56f19a5 O365 E3 - Licensed users ENTERPRISEPACK
c2652d63-9161-439b-b74e-fcd8228a7074 EMSandOffice {ENTERPRISEPREMIUM,EMSPREMIUM}
Get statistics for groups with licenses

You can report basic statistics for groups with licenses. In the example below we list the total user count, the count
of users with licenses already assigned by the group, and the count of users for whom licenses could not be
assigned by the group.
#get all groups with licenses

Get-MsolGroup -All | Where {$_.Licenses} | Foreach {
$groupId = $_.ObjectId;
$groupName = $_.DisplayName;
$groupLicenses = $_.Licenses | Select -ExpandProperty SkuPartNumber
$totalCount = 0;
$licenseAssignedCount = 0;
$licenseErrorCount = 0;
Get-MsolGroupMember -All -GroupObjectId $groupId |

#get full info about each user in the group
Get-MsolUser -ObjectId {$_.ObjectId} |
Foreach {
$user = $_;
$totalCount++
#check if any licenses are assigned via this group

if($user.Licenses | ? {$_.GroupsAssigningLicense -ieq $groupId })
{
$licenseAssignedCount++
}
#check if user has any licenses that failed to be assigned from this group
if ($user.IndirectLicenseErrors | ? {$_.ReferencedObjectId -ieq $groupId })
{
$licenseErrorCount++
}
}
#aggregate results for this group

New-Object Object |
Add-Member -NotePropertyName GroupName -NotePropertyValue $groupName -PassThru |
Add-Member -NotePropertyName GroupId -NotePropertyValue $groupId -PassThru |
Add-Member -NotePropertyName GroupLicenses -NotePropertyValue $groupLicenses -PassThru |
Add-Member -NotePropertyName TotalUserCount -NotePropertyValue $totalCount -PassThru |
Add-Member -NotePropertyName LicensedUserCount -NotePropertyValue $licenseAssignedCount -
PassThru |
Add-Member -NotePropertyName LicenseErrorCount -NotePropertyValue $licenseErrorCount -
PassThru
} | Format-Table
Output:
GroupName GroupId GroupLicenses TotalUserCount LicensedUserCount
LicenseErrorCount
--------- ------- ------------- -------------- ----------------- ---
--------------
Dynamics Licen... 9160c903-9f91-4597-8f79-22b6c47eafbf AAD_PREMIUM_P2 0 0
0
O365 E5 - base... 055dcca3-fb75-4398-a1b8-f8c6f4c24e65 ENTERPRISEPREMIUM 2 2
0
O365 E5 - extr... 6b14a1fe-c3a9-4786-9ee4-3a2bb54dcb8e ENTERPRISEPREMIUM 3 3
0
EMS E5 - all s... 7023a314-6148-4d7b-b33f-6c775572879a EMSPREMIUM 2 2
0
PowerBi - Lice... cf41f428-3b45-490b-b69f-a349c8a4c38e POWER_BI_STANDARD 2 2
0
O365 E3 - all ... 962f7189-59d9-4a29-983f-556ae56f19a5 ENTERPRISEPACK 2 2
0
O365 E5 - EXO 102fb8f4-bbe7-462b-83ff-2145e7cdd6ed ENTERPRISEPREMIUM 1 1
0
Access to Offi... 11151866-5419-4d93-9141-0603bbf78b42 STANDARDPACK 4 3
1
Get all groups with license errors

To find groups that contain some users for whom licenses could not be assigned:
Get-MsolGroup -HasLicenseErrorsOnly $true
Output:
ObjectId DisplayName GroupType Description

-------- ----------- --------- -----------
11151866-5419-4d93-9141-0603bbf78b42 Access to Office 365 E1 Security Users who should have E1 licenses
Get all users with license errors in a group

Given a group that contains some license related errors, you can now list all users affected by those errors. A user
can have errors from other groups, too. However, in this example we limit results only to errors relevant to the
group in question by checking the ReferencedObjectId property of each IndirectLicenseError entry on the user.
#a sample group with errors

$groupId = '11151866-5419-4d93-9141-0603bbf78b42'
#get all user members of the group

#get full information about user objects
#filter out users without license errors and users with licenense errors from other groups
Where {$_.IndirectLicenseErrors -and $_.IndirectLicenseErrors.ReferencedObjectId -eq $groupId} |
#display id, name and error detail. Note: we are filtering out license errors from other groups
Select ObjectId, `
DisplayName, `
@{Name="LicenseError";Expression={$_.IndirectLicenseErrors | Where {$_.ReferencedObjectId -eq
$groupId} | Select -ExpandProperty Error}}
Output:
ObjectId DisplayName License Error
-------- ----------- ------------
6d325baf-22b7-46fa-a2fc-a2500613ca15 Catherine Gibson MutuallyExclusiveViolation
Get all users with license errors in the entire tenant

To list all users who have license errors from one or more groups, the following script can be used. This script will
list one row per user, per license error which allows you to clearly identify the source of each error.
NOTE
This script will enumerate all users in the tenant, which might not be optimal for large tenants.
Get-MsolUser -All | Where {$_.IndirectLicenseErrors } | % {

$user = $_;
$user.IndirectLicenseErrors | % {
New-Object Object |
Add-Member -NotePropertyName UserName -NotePropertyValue $user.DisplayName -PassThru |
Add-Member -NotePropertyName UserId -NotePropertyValue $user.ObjectId -PassThru |
Add-Member -NotePropertyName GroupId -NotePropertyValue $_.ReferencedObjectId -PassThru |
Add-Member -NotePropertyName LicenseError -NotePropertyValue $_.Error -PassThru
}
}
Output:
UserName UserId GroupId LicenseError

-------- ------ ------- ------------
Anna Bergman 0d0fd16d-872d-4e87-b0fb-83c610db12bc 7946137d-b00d-4336-975e-b1b81b0666d0
MutuallyExclusiveViolation
Catherine Gibson 6d325baf-22b7-46fa-a2fc-a2500613ca15 f2503e79-0edc-4253-8bed-3e158366466b CountViolation
Catherine Gibson 6d325baf-22b7-46fa-a2fc-a2500613ca15 11151866-5419-4d93-9141-0603bbf78b42
Drew Fogarty f2af28fc-db0b-4909-873d-ddd2ab1fd58c 1ebd5028-6092-41d0-9668-129a3c471332
Here is another version of the script that searches only through groups that contain license errors. It may be more
optimized for scenarios where you expect to have few groups with problems.
Get-MsolUser -All | Where {$_.IndirectLicenseErrors } | % {

$user = $_;
$user.IndirectLicenseErrors | % {
New-Object Object |
Add-Member -NotePropertyName UserName -NotePropertyValue $user.DisplayName -PassThru |
Add-Member -NotePropertyName GroupId -NotePropertyValue $_.ReferencedObjectId -PassThru |
Add-Member -NotePropertyName LicenseError -NotePropertyValue $_.Error -PassThru
}
}
Check if user license is assigned directly or inherited from a group

For a user object it is possible to check if a particular product license is assigned from a group or if it is assigned
directly.
The two sample functions below can be used to analyze the type of assignment on an individual user:
#Returns TRUE if the user has the license assigned directly
function UserHasLicenseAssignedDirectly
{
Param([Microsoft.Online.Administration.User]$user, [string]$skuId)
foreach($license in $user.Licenses)
{
#we look for the specific license SKU in all licenses assigned to the user
if ($license.AccountSkuId -ieq $skuId)
{
#GroupsAssigningLicense contains a collection of IDs of objects assigning the license
#This could be a group object or a user object (contrary to what the name suggests)
#If the collection is empty, this means the license is assigned directly - this is the case for
users who have never been licensed via groups in the past
if ($license.GroupsAssigningLicense.Count -eq 0)
{
return $true
}
#If the collection contains the ID of the user object, this means the license is assigned directly
#Note: the license may also be assigned through one or more groups in addition to being assigned
directly
foreach ($assignmentSource in $license.GroupsAssigningLicense)
{
if ($assignmentSource -ieq $user.ObjectId)
{
return $true
}
}
return $false
}
}
return $false
}
#Returns TRUE if the user is inheriting the license from a group
function UserHasLicenseAssignedFromGroup
{
{
{
{
#If the collection contains at least one ID not matching the user ID this means that the
license is inherited from a group.
#Note: the license may also be assigned directly in addition to being inherited
if ($assignmentSource -ine $user.ObjectId)
{
return $true
}
}
return $false
}
}
return $false
}
This script executes those functions on each user in the tenant, using the SKU ID as input - in this example we are
interested in the license for Enterprise Mobility + Security, which in our tenant is represented with ID contoso:EMS:
#the license SKU we are interested in. use Msol-GetAccountSku to see a list of all identifiers in your tenant
$skuId = "contoso:EMS"
#find all users that have the SKU license assigned

Get-MsolUser -All | where {$_.isLicensed -eq $true -and $_.Licenses.AccountSKUID -eq $skuId} | select `
ObjectId, `
@{Name="SkuId";Expression={$skuId}}, `
@{Name="AssignedDirectly";Expression={(UserHasLicenseAssignedDirectly $_ $skuId)}}, `
@{Name="AssignedFromGroup";Expression={(UserHasLicenseAssignedFromGroup $_ $skuId)}}
Output:
ObjectId SkuId AssignedDirectly AssignedFromGroup

-------- ----- ---------------- -----------------
157870f6-e050-4b3c-ad5e-0f0a377c8f4d contoso:EMS True False
1f3174e2-ee9d-49e9-b917-e8d84650f895 contoso:EMS False True
240622ac-b9b8-4d50-94e2-dad19a3bf4b5 contoso:EMS True True
Remove direct licenses for users with group licenses

The purpose of this script is to remove unnecessary direct licenses from users who already inherit the same license
from a group; for example, as part of a transitioning to group-based licensing.
NOTE
It is important to first validate that the direct licenses to be removed do not enable more service functionality than the
inherited licenses. Otherwise, removing the direct license may disable access to services and data for users. Currently it is not
possible to check via PowerShell which services are enabled via inherited licenses vs direct. In the script we will specify the
minimum level of services we know are being inherited from groups and we will check against that.
#BEGIN: Helper functions used by the script
#Returns TRUE if the user has the license assigned directly

function UserHasLicenseAssignedDirectly
{
$license = GetUserLicense $user $skuId
if ($license -ne $null)

{
#If the collection is empty, this means the license is assigned directly - this is the case for users
who have never been licensed via groups in the past
if ($license.GroupsAssigningLicense.Count -eq 0)
{
return $true
}
#If the collection contains the ID of the user object, this means the license is assigned directly
#Note: the license may also be assigned through one or more groups in addition to being assigned
directly
{
if ($assignmentSource -ieq $user.ObjectId)
{
return $true
}
}
return $false
return $false
}
return $false
}
#Returns TRUE if the user is inheriting the license from a specific group
function UserHasLicenseAssignedFromThisGroup
{
Param([Microsoft.Online.Administration.User]$user, [string]$skuId, [Guid]$groupId)
if ($license -ne $null)

{
{
#If the collection contains at least one ID not matching the user ID this means that the license is
inherited from a group.
#Note: the license may also be assigned directly in addition to being inherited
if ($assignmentSource -ieq $groupId)
{
return $true
}
}
return $false
}
return $false
}
#Returns the license object corresponding to the skuId. Returns NULL if not found
function GetUserLicense
{
Param([Microsoft.Online.Administration.User]$user, [string]$skuId, [Guid]$groupId)
{
{
return $license
}
}
return $null
}
#produces a list of disabled service plan names for a set of plans we want to leave enabled
function GetDisabledPlansForSKU
{
Param([string]$skuId, [string[]]$enabledPlans)
$allPlans = Get-MsolAccountSku | where {$_.AccountSkuId -ieq $skuId} | Select -ExpandProperty ServiceStatus

| Where {$_.ProvisioningStatus -ine "PendingActivation"} | Select -ExpandProperty ServicePlan | Select -
ExpandProperty ServiceName
$disabledPlans = $allPlans | Where {$enabledPlans -inotcontains $_}
return $disabledPlans
}
function GetUnexpectedEnabledPlansForUser
{
Param([Microsoft.Online.Administration.User]$user, [string]$skuId, [string[]]$expectedDisabledPlans)
$extraPlans = @();
if($license -ne $null)

{
$userDisabledPlans = $license.ServiceStatus | where {$_.ProvisioningStatus -ieq "Disabled"} | Select -
ExpandProperty ServicePlan | Select -ExpandProperty ServiceName
$extraPlans = $expectedDisabledPlans | where {$userDisabledPlans -notcontains $_}

}
return $extraPlans
}
#END: helper functions
#BEGIN: executing the script

#the group to be processed
$groupId = "48ca647b-7e4d-41e5-aa66-40cab1e19101"
#license to be removed - Office 365 E3

$skuId = "contoso:ENTERPRISEPACK"
#minimum set of service plans we know are inherited from groups - we want to make sure that there aren't any
users who have more services enabled
#which could mean that they may lose access after we remove direct licenses
$servicePlansFromGroups = ("EXCHANGE_S_ENTERPRISE", "SHAREPOINTENTERPRISE", "OFFICESUBSCRIPTION")
$expectedDisabledPlans = GetDisabledPlansForSKU $skuId $servicePlansFromGroups
#process all members in the group

#get full info about each user in the group
Foreach {
$user = $_;
$operationResult = "";
#check if Direct license exists on the user

if (UserHasLicenseAssignedDirectly $user $skuId)
{
#check if the license is assigned from this group, as expected
if (UserHasLicenseAssignedFromThisGroup $user $skuId $groupId)
{
#check if there are any extra plans we didn't expect - we are being extra careful not to remove
unexpected services
$extraPlans = GetUnexpectedEnabledPlansForUser $user $skuId $expectedDisabledPlans
if ($extraPlans.Count -gt 0)
{
$operationResult = "User has extra plans that may be lost - license removal was skipped.
Extra plans: $extraPlans"
}
else
{
#remove the direct license from user
Set-MsolUserLicense -ObjectId $user.ObjectId -RemoveLicenses $skuId
$operationResult = "Removed direct license from user."
}
}
else
{
$operationResult = "User does not inherit this license from this group. License removal was
skipped."
}
}
else
{
$operationResult = "User has no direct license to remove. Skipping."
}
#format output
New-Object Object |
Add-Member -NotePropertyName OperationResult -NotePropertyValue $operationResult -PassThru
} | Format-Table
#END: executing the script
#END: executing the script
Output:
UserId OperationResult
------ ---------------
7c7f860f-700a-462a-826c-f50633931362 Removed direct license from user.
0ddacdd5-0364-477d-9e4b-07eb6cdbc8ea User has extra plans that may be lost - license removal was skipped. Extra
plans: SHAREPOINTWAC
aadbe4da-c4b5-4d84-800a-9400f31d7371 User has no direct license to remove. Skipping.
Next steps
To learn more about the feature set for license management through groups, see the following:
Product names and service plan identifiers for
licensing
When managing licenses in the Azure portal or the Office 365 portal, you see product names that look something
like Office 365 Enterprise E3. When you use PowerShell v1.0 cmdlets, the same product is identified using a specific
but less friendly name: ENTERPRISEPACK. When using PowerShell v2.0 cmdlets or Microsoft Graph, the same
product is identified using a GUID value: 6fd2c87f-b296-42f0-b197-1e91e994b900. The following table lists the
most commonly used Microsoft online service products and provides their various ID values:
Product Name: Used in management portals
String ID: Used by PowerShell v1.0 cmdlets when performing operations on licenses
Guid ID: GUID used by Azure AD Graph and Microsoft Graph
Service Plans Included: A list of service plans in the product that correspond to the String ID and GUID
NOTE
This information is accurate as of October 11, 2017.
PRODUCT NAME STRING ID GUID SERVICE PLANS INCLUDED
AZURE ACTIVE DIRECTORY AAD_BASIC 2b9c8e7c-319c-43a2-a2a0- AAD_BASIC (c4da7f8a-5ee2-

BASIC 48c5c6161de7 4c99-a7e1-87d2df57f6fe)
AZURE ACTIVE DIRECTORY AAD_PREMIUM 078d2b04-f1bd-4111- AAD_PREMIUM (41781fb2-

PREMIUM P1 bbd4-b4b1b354cef4 bc02-4b7c-bd55-
b576c07bb09d)
MFA_PREMIUM (8a256a2b-
b617-496d-b51b-
e76466e88db0)
AZURE INFORMATION RIGHTSMANAGEMENT c52ea49f-fe5d-4e95-93ba- RMS_S_ENTERPRISE

PROTECTION PLAN 1 1de91d380f89 (bea4c11e-220a-4e6d-
8eb8-8ea15d019f90)
RMS_S_PREMIUM
(6c57d4b6-3b23-47a5-
9bc9-69f17b4947b3)
DYNAMICS 365 CUSTOMER DYN365_ENTERPRISE_PLAN ea126fc5-a19e-42e2-a731- DYN365_ENTERPRISE_P1

ENGAGEMENT PLAN 1 da9d437bffcf (d56f3deb-50d8-465a-
ENTERPRISE EDITION bedb-f079817ccac1)
FLOW_DYN_P2 (b650d915-
9886-424b-a08d-
633cede56f57)
NBENTERPRISE (03acaee3-
9492-4f40-aed4-
bcb6b32981b6)
POWERAPPS_DYN_P2
(0b03f40b-c404-40c3-
8651-2aceb74365fa)
PROJECT_CLIENT_SUBSCRIP
TION (fafd7243-e5c1-4a3a-
9e40-495efcb1d3c3)
SHAREPOINT_PROJECT
(fe71d6c3-a2ea-4499-9778-
da042bf08063)
SHAREPOINTENTERPRISE
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
DYNAMICS 365 FOR DYN365_FINANCIALS_BUSI cc13a803-544e-4464-b4e4- DYN365_FINANCIALS_BUSI

FINANCIALS BUSINESS NESS_SKU 6d6169a138fa NESS (920656a2-7dd8-
EDITION 4c83-97b6-a356414dbd36)
FLOW_DYN_APPS
(7e6d7d78-73de-46ba-
83b1-6d25117334ba)
POWERAPPS_DYN_APPS
(874fc546-6efe-4d22-90b8-
5c4e7aa59f4b)
DYNAMICS 365 FOR SALES DYN365_ENTERPRISE_SALES 1e1a282c-9c54-43a2-9310- DYN365_ENTERPRISE_SALES

ENTERPRISE EDITION 98ef728faace (2da8e897-7791-486b-
b08f-cc63c8129df7)
FLOW_DYN_APPS
(7e6d7d78-73de-46ba-
83b1-6d25117334ba)
NBENTERPRISE (03acaee3-
9492-4f40-aed4-
bcb6b32981b6)
POWERAPPS_DYN_APPS
(874fc546-6efe-4d22-90b8-
5c4e7aa59f4b)
PROJECT_ESSENTIALS
(1259157c-8581-4875-
bca7-2ffb18c51bda)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
DYNAMICS 365 FOR TEAM DYN365_ENTERPRISE_TEAM 8e7a3d30-d97d-43ab- DYN365_Enterprise_Talent_A

MEMBERS ENTERPRISE _MEMBERS 837c-d7701cef83dc ttract_TeamMember
EDITION (643d201a-9884-45be-
962a-06ba97062e5e)
DYN365_Enterprise_Talent_
Onboard_TeamMember
(f2f49eef-4b3f-4853-809a-
a055c6103fe0)
DYN365_ENTERPRISE_TEAM
_MEMBERS (6a54b05e-4fab-
40e7-9828-428db3b336fa)
Dynamics_365_for_Operatio
ns_Team_members
(f5aa7b45-8a36-4cd1-bc37-
5d06dea98645)
Dynamics_365_for_Retail_Tea
m_members (c0454a3d-
32b5-4740-b090-
78c32f48f0ad)
Dynamics_365_for_Talent_Te
am_members (d5156635-
0704-4f66-8803-
93258f8b2678)
FLOW_DYN_TEAM
(1ec58c70-f69c-486a-8109-
4b87ce86e449)
POWERAPPS_DYN_TEAM
(52e619e2-2730-439a-
b0d3-d09ab7e8b705)
PROJECT_ESSENTIALS
(1259157c-8581-4875-
bca7-2ffb18c51bda)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
ENTERPRISE MOBILITY + EMS efccb6f7-5641-4e0e-bd10- AAD_PREMIUM (41781fb2-

SECURITY E3 b4976e1bf68e bc02-4b7c-bd55-
b576c07bb09d)
ADALLOM_S_DISCOVERY
(932ad362-64a8-4783-
9106-97849a1a30b9)
INTUNE_A (c1ec4a95-1f05-
45b3-a911-aa3fa01094f5)
b617-496d-b51b-
e76466e88db0)
RMS_S_ENTERPRISE
(bea4c11e-220a-4e6d-
8eb8-8ea15d019f90)
RMS_S_PREMIUM
(6c57d4b6-3b23-47a5-
9bc9-69f17b4947b3)
ENTERPRISE MOBILITY + EMSPREMIUM b05e124f-c7cc-45a0-a6aa- AAD_PREMIUM (41781fb2-

SECURITY E5 8cf78c946968 bc02-4b7c-bd55-
b576c07bb09d)
AAD_PREMIUM_P2
(eec0eb4f-6444-4f95-aba0-
50c24d67f998)
ADALLOM_S_STANDALONE
(2e2ddb96-6af9-4b1d-a3f0-
d6ecfd22edb2)
INTUNE_A (c1ec4a95-1f05-
45b3-a911-aa3fa01094f5)
b617-496d-b51b-
e76466e88db0)
RMS_S_ENTERPRISE
8eb8-8ea15d019f90)
RMS_S_PREMIUM
(6c57d4b6-3b23-47a5-
9bc9-69f17b4947b3)
RMS_S_PREMIUM2
(5689bec4-755d-4753-
8b61-40975025187c)
EXCHANGE ONLINE (PLAN EXCHANGESTANDARD 4b9405b0-7788-4568- EXCHANGE_S_STANDARD

1) add1-99614e613b69 (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
EXCHANGE ONLINE (PLAN EXCHANGEENTERPRISE 19ec0d23-8335-4cbd-94ac- EXCHANGE_S_ENTERPRISE

2) 6050e30712fa (efb87545-963c-4e0d-99df-
69c6916d9eb0)
EXCHANGE ONLINE EXCHANGEARCHIVE_ADDO ee02fd1b-340e-4a4b-b355- EXCHANGE_S_ARCHIVE_AD

ARCHIVING FOR EXCHANGE N 4a514e4c8943 DON (176a09a6-7ec5-
ONLINE 4039-ac02-b2791c6ba793)
EXCHANGE ONLINE EXCHANGEARCHIVE 90b5e015-709a-4b8b- EXCHANGE_S_ARCHIVE

ARCHIVING FOR EXCHANGE b08e-3200f994494c (da040e0a-b393-4bea-
SERVER bb76-928b3fa1cf5a)
EXCHANGE ONLINE EXCHANGEESSENTIALS 7fc0182e-d107-4556-8329- EXCHANGE_S_STANDARD

ESSENTIALS 7caaa511197b (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
EXCHANGE ONLINE EXCHANGE_S_ESSENTIALS e8f81a67-bd96-4074-b108- EXCHANGE_S_ESSENTIALS

ESSENTIALS cf193eb9433b (1126bef5-da20-4f07-b45e-
ad25d2581aa8)
EXCHANGE ONLINE KIOSK EXCHANGEDESKLESS 80b2d799-d2ba-4d2a- EXCHANGE_S_DESKLESS

8842-fb0d0f3a4b82 (4a82b400-a79f-41a4-
b4e2-e94f5787b113)
INTUNE INTUNE_A 061f9ace-7d42-4136-88ac- INTUNE_A (c1ec4a95-1f05-

31dc755f143f 45b3-a911-aa3fa01094f5)
MICROSOFT DYNAMICS CRMPLAN2 906af65a-2970-46d5-9b58- CRMPLAN2 (bf36ca64-

CRM ONLINE BASIC 4e9aa50f0657 95c6-4918-9275-
eb9f4ce2c04f)
FLOW_DYN_APPS
(7e6d7d78-73de-46ba-
83b1-6d25117334ba)
POWERAPPS_DYN_APPS
(874fc546-6efe-4d22-90b8-
5c4e7aa59f4b)
MICROSOFT DYNAMICS CRMSTANDARD d17b27af-3f49-4822-99f9- CRMSTANDARD (f9646fb2-

CRM ONLINE 56a661538792 e3b2-4309-95de-
PROFESSIONAL dc4833737456)
FLOW_DYN_APPS
(7e6d7d78-73de-46ba-
83b1-6d25117334ba)
MDM_SALES_COLLABORATI
ON (3413916e-ee66-4071-
be30-6f94d4adfeda)
NBPROFESSIONALFORCRM
(3e58e97c-9abe-ebab-cd5f-
d543d1529634)
POWERAPPS_DYN_APPS
(874fc546-6efe-4d22-90b8-
5c4e7aa59f4b)
MICROSOFT INTUNE A INTUNE_A 061f9ace-7d42-4136-88ac- INTUNE_A (c1ec4a95-1f05-

DIRECT 31dc755f143f 45b3-a911-aa3fa01094f5)
MS IMAGINE ACADEMY IT_ACADEMY_AD ba9a34de-4489-469d- IT_ACADEMY_AD

879c-0f0f145321cd (d736def0-1fde-43f0-a5be-
e3f8b2de6e41)
OFFICE 365 BUSINESS O365_BUSINESS cdd28e44-67e3-425e-be4c- FORMS_PLAN_E1

737fab2899d3 (159f4cd6-e380-449f-a816-
af1a9ef76344)
OFFICE_BUSINESS
(094e7854-93fc-4d55-
b2c0-3ab5369ebdc1)
ONEDRIVESTANDARD
(13696edf-5a08-49f6-8134-
03083ed8ba30)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
SWAY (a23b959c-7ce8-
4e57-9140-b90eb88a9e97)
OFFICE 365 BUSINESS SMB_BUSINESS b214fe43-f5a3-4703-beeb- FORMS_PLAN_E1

fa97188220fc (159f4cd6-e380-449f-a816-
af1a9ef76344)
OFFICE_BUSINESS
(094e7854-93fc-4d55-
b2c0-3ab5369ebdc1)
ONEDRIVESTANDARD
(13696edf-5a08-49f6-8134-
03083ed8ba30)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
OFFICE 365 BUSINESS O365_BUSINESS_ESSENTIAL 3b555118-da6a-4418-894f- EXCHANGE_S_STANDARD

ESSENTIALS S 7df1e2096870 (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
FLOW_O365_P1 (0f9b09cb-
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
MCOSTANDARD (0feaeb32-
d00e-4d66-bd5a-
43b5b83db82c)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
(c7699d2e-19aa-44de-8edf-
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
TEAMS1 (57ff2da0-773e-
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 BUSINESS SMB_BUSINESS_ESSENTIALS dab7782a-93b1-4074- EXCHANGE_S_STANDARD

ESSENTIALS 8bb1-0e61318bea0b (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
d00e-4d66-bd5a-
43b5b83db82c)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_MIDSIZE
(41bf139a-4e60-409f-9346-
a1361efc6dfb)
OFFICE 365 BUSINESS O365_BUSINESS_PREMIUM f245ecc8-75af-4f8e-b61f- EXCHANGE_S_STANDARD

PREMIUM 27d8114de5f3 (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
d00e-4d66-bd5a-
43b5b83db82c)
MICROSOFTBOOKINGS
(199a5c09-e0ca-4e37-8f7c-
b05d533e1ea2)
O365_SB_Relationship_Mana
gement (5bfe124c-bbdc-
4494-8835-f1297d457d79)
OFFICE_BUSINESS
(094e7854-93fc-4d55-
b2c0-3ab5369ebdc1)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 BUSINESS SMB_BUSINESS_PREMIUM ac5cef5d-921b-4f97-9ef3- EXCHANGE_S_STANDARD

PREMIUM c99076e5470f (9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
d00e-4d66-bd5a-
43b5b83db82c)
MICROSOFTBOOKINGS
(199a5c09-e0ca-4e37-8f7c-
b05d533e1ea2)
O365_SB_Relationship_Mana
gement (5bfe124c-bbdc-
4494-8835-f1297d457d79)
OFFICE_BUSINESS
(094e7854-93fc-4d55-
b2c0-3ab5369ebdc1)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_MIDSIZE
(41bf139a-4e60-409f-9346-
a1361efc6dfb)
OFFICE 365 ENTERPRISE E1 STANDARDPACK 18181a46-0d4e-45cd- Deskless (8c7d2df8-86f0-

891e-60aabd171b4e 4902-b2ed-a0458298f3b3)
EXCHANGE_S_STANDARD
(9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
d00e-4d66-bd5a-
43b5b83db82c)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E1
(743dd19e-1ce3-4c62-
a3ad-49ba8f63a2f6)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 ENTERPRISE E2 STANDARDWOFFPACK 6634e0ce-1a9f-428c-a498- Deskless (8c7d2df8-86f0-

f84ec7b8aa2e 4902-b2ed-a0458298f3b3)
EXCHANGE_S_STANDARD
(9aaf7827-d63c-4b61-89c3-
182f06f82e5c)
62d1-4ff4-9129-
43f4996f83f4)
FORMS_PLAN_E1
(159f4cd6-e380-449f-a816-
af1a9ef76344)
d00e-4d66-bd5a-
43b5b83db82c)
POWERAPPS_O365_P1
(92f7a6f3-b89b-4bbd-8c30-
809e6da5ad1c)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINTSTANDARD
1736da088ca1)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E1
(743dd19e-1ce3-4c62-
a3ad-49ba8f63a2f6)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 ENTERPRISE E3 ENTERPRISEPACK 6fd2c87f-b296-42f0-b197- Deskless (8c7d2df8-86f0-

1e91e994b900 4902-b2ed-a0458298f3b3)
EXCHANGE_S_ENTERPRISE
(efb87545-963c-4e0d-99df-
69c6916d9eb0)
FLOW_O365_P2 (76846ad7-
7776-4c40-a281-
a386362dd1b9)
FORMS_PLAN_E3
(2789c901-c14e-48ab-
a76a-be334d9d793a)
d00e-4d66-bd5a-
43b5b83db82c)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
POWERAPPS_O365_P2
(c68f8d98-5534-41c8-bf36-
22fa496fa792)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
RMS_S_ENTERPRISE
8eb8-8ea15d019f90)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E3
(9e700747-8b1d-45e5-
ab8d-ef187ceec156)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 ENTERPRISE E3 DEVELOPERPACK 189a915c-fe4f-4ffa-bde4- EXCHANGE_S_ENTERPRISE

DEVELOPER 85b9628d07a0 (efb87545-963c-4e0d-99df-
69c6916d9eb0)
FLOW_O365_P2 (76846ad7-
7776-4c40-a281-
a386362dd1b9)
FORMS_PLAN_E5
(e212cbc7-0961-4c40-
9825-01117710dcb1)
d00e-4d66-bd5a-
43b5b83db82c)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
POWERAPPS_O365_P2
(c68f8d98-5534-41c8-bf36-
22fa496fa792)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
SHAREPOINT_S_DEVELOPER
(a361d6e2-509e-4e25-
a8ad-950060064ef4)
SHAREPOINTWAC_DEVELOP
ER (527f7cdd-0e86-4c47-
b879-f5fd357a3ac6)
STREAM_O365_E5
(6c6042f5-6f01-4d67-b8c1-
eb99d36eed3e)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
OFFICE 365 ENTERPRISE E4 ENTERPRISEWITHSCAL 1392051d-0cb9-4b7a- Deskless (8c7d2df8-86f0-

88d5-621fee5e8711 4902-b2ed-a0458298f3b3)
(efb87545-963c-4e0d-99df-
69c6916d9eb0)
FLOW_O365_P2 (76846ad7-
7776-4c40-a281-
a386362dd1b9)
FORMS_PLAN_E3
(2789c901-c14e-48ab-
a76a-be334d9d793a)
d00e-4d66-bd5a-
43b5b83db82c)
MCOVOICECONF
(27216c54-caf8-4d0d-97e2-
517afb5c08f6)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
POWERAPPS_O365_P2
(c68f8d98-5534-41c8-bf36-
22fa496fa792)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
RMS_S_ENTERPRISE
8eb8-8ea15d019f90)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E3
(9e700747-8b1d-45e5-
ab8d-ef187ceec156)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 ENTERPRISE E5 ENTERPRISEPREMIUM c7df2760-2c81-4ef7-b578- ADALLOM_S_O365

5b5392b571df (8c098270-9dd4-4350-
9b30-ba4703f3b36b)
BI_AZURE_P2 (70d33638-
9c74-4d01-bfd3-
562de28bd4ba)
Deskless (8c7d2df8-86f0-
4902-b2ed-a0458298f3b3)
EQUIVIO_ANALYTICS
(4de31727-a228-4ec3-a5bf-
8e45b5ca48cc)
EXCHANGE_ANALYTICS
(34c0d7a0-a70f-4668-
9238-47f9fc208882)
(efb87545-963c-4e0d-99df-
69c6916d9eb0)
FLOW_O365_P3
(07699545-9485-468e-
95b6-2fca3738be01)
FORMS_PLAN_E5
(e212cbc7-0961-4c40-
9825-01117710dcb1)
LOCKBOX_ENTERPRISE
(9f431833-0334-42de-
a7dc-70aa40db46db)
MCOEV (4828c8ec-dc2e-
4779-b502-87ac9ce28ab7)
MCOMEETADV (3e26ee1f-
8a5f-4d52-aee2-
b81ce45c8f40)
d00e-4d66-bd5a-
43b5b83db82c)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
POWERAPPS_O365_P3
(9c0dab89-a30c-4117-
86e7-97bda240acd2)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
RMS_S_ENTERPRISE
8eb8-8ea15d019f90)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E5
(6c6042f5-6f01-4d67-b8c1-
eb99d36eed3e)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
THREAT_INTELLIGENCE
(8e0c0a52-6a6c-4d40-
8370-dd62790dcd70)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 ENTERPRISE E5 ENTERPRISEPREMIUM_NOPS 26d45bd9-adf1-46cd-a9e1- ADALLOM_S_O365

WITHOUT PSTN TNCONF 51e9a5524128 (8c098270-9dd4-4350-
CONFERENCING 9b30-ba4703f3b36b)
BI_AZURE_P2 (70d33638-
9c74-4d01-bfd3-
562de28bd4ba)
Deskless (8c7d2df8-86f0-
4902-b2ed-a0458298f3b3)
EQUIVIO_ANALYTICS
(4de31727-a228-4ec3-a5bf-
8e45b5ca48cc)
EXCHANGE_ANALYTICS
(34c0d7a0-a70f-4668-
9238-47f9fc208882)
(efb87545-963c-4e0d-99df-
69c6916d9eb0)
FLOW_O365_P3
(07699545-9485-468e-
95b6-2fca3738be01)
FORMS_PLAN_E5
(e212cbc7-0961-4c40-
9825-01117710dcb1)
LOCKBOX_ENTERPRISE
(9f431833-0334-42de-
a7dc-70aa40db46db)
MCOEV (4828c8ec-dc2e-
4779-b502-87ac9ce28ab7)
d00e-4d66-bd5a-
43b5b83db82c)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
POWERAPPS_O365_P3
(9c0dab89-a30c-4117-
86e7-97bda240acd2)
PROJECTWORKMANAGEME
NT (b737dad2-2f6c-4c65-
90e3-ca563267e8b9)
RMS_S_ENTERPRISE
8eb8-8ea15d019f90)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_E5
(6c6042f5-6f01-4d67-b8c1-
eb99d36eed3e)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
THREAT_INTELLIGENCE
(8e0c0a52-6a6c-4d40-
8370-dd62790dcd70)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 F1 DESKLESSPACK 4b585984-651b-448a- Deskless (8c7d2df8-86f0-
9e53-3b10f069cf7f 4902-b2ed-a0458298f3b3)
EXCHANGE_S_DESKLESS
(4a82b400-a79f-41a4-
b4e2-e94f5787b113)
FLOW_O365_S1 (bd91b1a4-
9f94-4ecf-b45b-
3a65e5c8128a)
FORMS_PLAN_K (f07046bd-
2a3c-4b96-b0be-
dea79d7cbfb8)
MCOIMP (afc06cb0-b4f4-
4473-8286-d644f70d8faf)
POWERAPPS_O365_S1
(e0287f9f-e222-4f98-9a83-
f379e249159a)
SHAREPOINTDESKLESS
(902b47e5-dcb2-4fdc-
858b-c63a90a2bdb9)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
STREAM_O365_K (3ffba0d2-
38e5-4d5e-8ec0-
98f2b05c09d9)
4e57-9140-b90eb88a9e97)
42df-b2af-ffb7a2317929)
YAMMER_ENTERPRISE
(7547a3fe-08ee-4ccb-b430-
5077c5041653)
OFFICE 365 MIDSIZE MIDSIZEPACK 04a7fb0d-32e0-4241-b4f5- EXCHANGE_S_STANDARD_M

BUSINESS 3f7618cd1162 IDMARKET (fc52cc4b-ed7d-
472d-bbe7-b081c23ecc56)
MCOSTANDARD_MIDMARK
ET (b2669e95-76ef-4e7e-
a367-002f60a39f3e)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
SHAREPOINTENTERPRISE_MI
DMARKET (6b5b6a67-fc72-
4a1f-a2b5-beecf05de761)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
YAMMER_MIDSIZE
(41bf139a-4e60-409f-9346-
a1361efc6dfb)
OFFICE 365 PROPLUS OFFICESUBSCRIPTION c2273bd0-dff7-4215-9ef5- FORMS_PLAN_E1

2c7bcfb06425 (159f4cd6-e380-449f-a816-
af1a9ef76344)
OFFICESUBSCRIPTION
(43de0ff5-c92c-492b-9116-
175376d08c38)
ONEDRIVESTANDARD
(13696edf-5a08-49f6-8134-
03083ed8ba30)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
OFFICE 365 SMALL LITEPACK bd09678e-b83c-4d3f-aaba- EXCHANGE_L_STANDARD

BUSINESS 3dad4abd128b (d42bdbd6-c335-4231-
ab3d-c8f348d5aff5)
MCOLITE (70710b6b-3ab4-
4a38-9f6d-9f169461650a)
SHAREPOINTLITE (a1f3d0a8-
84c0-4ae0-bae4-
685917b8ab48)
4e57-9140-b90eb88a9e97)
OFFICE 365 SMALL LITEPACK_P2 fc14ec4a-4169-49a4-a51e- EXCHANGE_L_STANDARD

BUSINESS PREMIUM 2c852931814b (d42bdbd6-c335-4231-
ab3d-c8f348d5aff5)
MCOLITE (70710b6b-3ab4-
4a38-9f6d-9f169461650a)
OFFICE_PRO_PLUS_SUBSCRI
PTION_SMBIZ (8ca59559-
e2ca-470b-b7dd-
afd8c0dee963)
SHAREPOINTLITE (a1f3d0a8-
84c0-4ae0-bae4-
685917b8ab48)
4e57-9140-b90eb88a9e97)
ONEDRIVE FOR BUSINESS WACONEDRIVESTANDARD e6778190-713e-4e4f-9119- FORMS_PLAN_E1

(PLAN 1) 8b8238de25df (159f4cd6-e380-449f-a816-
af1a9ef76344)
ONEDRIVESTANDARD
(13696edf-5a08-49f6-8134-
03083ed8ba30)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
ONEDRIVE FOR BUSINESS WACONEDRIVEENTERPRISE ed01faf2-1d88-4947-ae91- ONEDRIVEENTERPRISE

(PLAN 2) 45ca18703a96 (afcafa6a-d966-4462-918c-
ec0b4e0fe642)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
POWER BI FOR OFFICE 365 POWER_BI_ADDON 45bc2c81-6072-436a- BI_AZURE_P1 (2125cfd7-

ADD-ON 9b0b-3b12eefbc402 2110-4567-83c4-
c1cd5275163d)
SQL_IS_SSIM (fc0a60aa-
feee-4746-a0e3-
aecfe81a38dd)
POWER BI PRO POWER_BI_PRO f8a1db68-be16-40ed-86d5- BI_AZURE_P2 (70d33638-

cb42ce701560 9c74-4d01-bfd3-
562de28bd4ba)
PROJECT FOR OFFICE 365 PROJECTCLIENT a10d5e58-74da-4312- PROJECT_CLIENT_SUBSCRIP

95c8-76be4e5b75a0 TION (fafd7243-e5c1-4a3a-
9e40-495efcb1d3c3)
PROJECT ONLINE PROJECTESSENTIALS 776df282-9fc0-4862-99e2- FORMS_PLAN_E1

ESSENTIALS 70e561b9909e (159f4cd6-e380-449f-a816-
af1a9ef76344)
PROJECT_ESSENTIALS
(1259157c-8581-4875-
bca7-2ffb18c51bda)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
PROJECT ONLINE PREMIUM PROJECTPREMIUM 09015f9f-377f-4538-bbb5- PROJECT_CLIENT_SUBSCRIP

f75ceb09358a TION (fafd7243-e5c1-4a3a-
9e40-495efcb1d3c3)
SHAREPOINT_PROJECT
(fe71d6c3-a2ea-4499-9778-
da042bf08063)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
PROJECT ONLINE PREMIUM PROJECTONLINE_PLAN_1 2db84718-652c-47a7- FORMS_PLAN_E1

WITHOUT PROJECT CLIENT 860c-f10d8abbdae3 (159f4cd6-e380-449f-a816-
af1a9ef76344)
SHAREPOINT_PROJECT
(fe71d6c3-a2ea-4499-9778-
da042bf08063)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
PROJECT ONLINE PROJECTPROFESSIONAL 53818b1b-4a27-454b- PROJECT_CLIENT_SUBSCRIP

PROFESSIONAL 8896-0dba576410e6 TION (fafd7243-e5c1-4a3a-
9e40-495efcb1d3c3)
SHAREPOINT_PROJECT
(fe71d6c3-a2ea-4499-9778-
da042bf08063)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
PROJECT ONLINE WITH PROJECTONLINE_PLAN_2 f82a60b8-1ee3-4cfb-a4fe- FORMS_PLAN_E1

PROJECT FOR OFFICE 365 1c6a53c2656c (159f4cd6-e380-449f-a816-
af1a9ef76344)
PROJECT_CLIENT_SUBSCRIP
TION (fafd7243-e5c1-4a3a-
9e40-495efcb1d3c3)
SHAREPOINT_PROJECT
(fe71d6c3-a2ea-4499-9778-
da042bf08063)
(5dbe027f-2339-4123-
9542-606e4d348a72)
SHAREPOINTWAC
(e95bec33-7c88-4a70-
8e19-b10bd9d0c014)
4e57-9140-b90eb88a9e97)
SHAREPOINT ONLINE (PLAN SHAREPOINTSTANDARD 1fc08a02-8b3d-43b9-831e- SHAREPOINTSTANDARD

1) f76859e04e1a (c7699d2e-19aa-44de-8edf-
1736da088ca1)
SHAREPOINT ONLINE (PLAN SHAREPOINTENTERPRISE a9732ec9-17d9-494c-a51c- SHAREPOINTENTERPRISE

2) d6b45b384dcb (5dbe027f-2339-4123-
9542-606e4d348a72)
SKYPE FOR BUSINESS MCOEV e43b5b99-8dfb-405f-9987- MCOEV (4828c8ec-dc2e-

CLOUD PBX dc307f34bcbd 4779-b502-87ac9ce28ab7)
SKYPE FOR BUSINESS MCOIMP b8b749f8-a4ef-4887-9539- MCOIMP (afc06cb0-b4f4-

ONLINE (PLAN 1) c95b1eaa5db7 4473-8286-d644f70d8faf)
SKYPE FOR BUSINESS MCOSTANDARD d42c793f-6c78-4f43-92ca- MCOSTANDARD (0feaeb32-

ONLINE (PLAN 2) e8f6a02b035f d00e-4d66-bd5a-
43b5b83db82c)
SKYPE FOR BUSINESS PSTN MCOMEETADV 0c266dff-15dd-4b49-8397- MCOMEETADV (3e26ee1f-

CONFERENCING 2bb16070ed52 8a5f-4d52-aee2-
b81ce45c8f40)
SKYPE FOR BUSINESS PSTN MCOPSTN2 d3b4fe1f-9992-4930-8acb- MCOPSTN2 (5a10155d-

DOMESTIC AND ca6ec609365e f5c1-411a-a8ec-
INTERNATIONAL CALLING e99aae125390)
SKYPE FOR BUSINESS PSTN MCOPSTN1 0dab259f-bf13-4952-b7f8- MCOPSTN1 (4ed3ff63-

DOMESTIC CALLING 7db8f131b28d 69d7-4fb7-b984-
5aec7f605ca8)
VISIO PRO FOR OFFICE 365 VISIOCLIENT c5928f49-12ba-48f7-ada3- VISIO_CLIENT_SUBSCRIPTIO

0d743a3601d5 N (663a804f-1c30-4ff0-
9915-9db84f0d1cea)
WINDOWS 10 ENTERPRISE WIN10_PRO_ENT_SUB cb10e6cd-9da4-4992-867b- WIN10_PRO_ENT_SUB

E3 67546b1db821 (21b439ba-a0ca-424f-a6cc-
52f954a5b111)
Service plans that cannot be assigned at the same time

Some products contain service plans that cannot be assigned to the same user at the same time. For example, if you
have Office 365 Enterprise E1 and Office 365 Enterprise E3 in your tenant, and you try to assign both licenses to the
same user, the operation fails. This is because the E3 product contains the following service plans that conflict with
their E1 counterparts:
SharePoint Online (Plan 2) conflicts with SharePoint Online (Plan 1).
Exchange Online (Plan 2) conflicts with Exchange Online (Plan 1).
When using group-based licensing, you experience this error condition. When using PowerShell, you see the
MutuallyExclusiveViolation error.
This section lists the most common service plans that are mutually exclusive, grouped by service type. You can use
this information to plan your license deployment and avoid assignment errors.
Service: Azure Active Directory
NOTE
All service plans related to Azure Active Directory can now be assigned together, to the same user. This simplifies certain
license management scenarios, such as moving users from Azure AD Basic to Azure AD Premium P1.
Service: Dynamics CRM

The following service plans cannot be assigned together:
SERVICE PLAN NAME GUID
CRMIUR c42a56bd-9e70-4ace-be17-dc8eeae369d7
CRMPLAN1 119cf168-b6cf-41fb-b82e-7fee7bae5814
CRMPLAN2 bf36ca64-95c6-4918-9275-eb9f4ce2c04f
CRMSTANDARD f9646fb2-e3b2-4309-95de-dc4833737456
DYN365_ENTERPRISE_P1 d56f3deb-50d8-465a-bedb-f079817ccac1
DYN365_ENTERPRISE_P1_IW 056a5f80-b4e0-4983-a8be-7ad254a113c9
DYN365_ENTERPRISE_SALES 2da8e897-7791-486b-b08f-cc63c8129df7
DYN365_ENTERPRISE_TEAM_MEMBERS 6a54b05e-4fab-40e7-9828-428db3b336fa
EMPLOYEE_SELF_SERVICE ba5f0cfa-d54a-4ea0-8cf4-a7e1dc4423d8
Service: Exchange Online

EXCHANGE_B_STANDARD 90927877-dcff-4af6-b346-2332c0b15bb7
EXCHANGE_L_STANDARD d42bdbd6-c335-4231-ab3d-c8f348d5aff5
EXCHANGE_S_ARCHIVE da040e0a-b393-4bea-bb76-928b3fa1cf5a
EXCHANGE_S_DESKLESS 4a82b400-a79f-41a4-b4e2-e94f5787b113
EXCHANGE_S_ENTERPRISE efb87545-963c-4e0d-99df-69c6916d9eb0
EXCHANGE_S_ESSENTIALS 1126bef5-da20-4f07-b45e-ad25d2581aa8
EXCHANGE_S_STANDARD 9aaf7827-d63c-4b61-89c3-182f06f82e5c
EXCHANGE_S_STANDARD_MIDMARKET fc52cc4b-ed7d-472d-bbe7-b081c23ecc56
Service: Intune
INTUNE_A c1ec4a95-1f05-45b3-a911-aa3fa01094f5
INTUNE_A_VL 3e170737-c728-4eae-bbb9-3f3360f7184c
INTUNE_B 2dc63b8a-df3d-448f-b683-8655877c9360
Service: SharePoint Online

ONEDRIVEENTERPRISE afcafa6a-d966-4462-918c-ec0b4e0fe642
SHAREPOINT_S_DEVELOPER a361d6e2-509e-4e25-a8ad-950060064ef4
SHAREPOINTDESKLESS 902b47e5-dcb2-4fdc-858b-c63a90a2bdb9
SHAREPOINTENTERPRISE 5dbe027f-2339-4123-9542-606e4d348a72
SHAREPOINTENTERPRISE_EDU 63038b2c-28d0-45f6-bc36-33062963b498
SHAREPOINTENTERPRISE_MIDMARKET 6b5b6a67-fc72-4a1f-a2b5-beecf05de761
SHAREPOINTLITE a1f3d0a8-84c0-4ae0-bae4-685917b8ab48
SHAREPOINTSTANDARD c7699d2e-19aa-44de-8edf-1736da088ca1
SHAREPOINTSTANDARD_EDU 0a4983bb-d3e5-4a09-95d8-b2d0127b3df5
Service: Skype for Business

MCOIMP afc06cb0-b4f4-4473-8286-d644f70d8faf
MCOSTANDARD_MIDMARKET b2669e95-76ef-4e7e-a367-002f60a39f3e
MCOSTANDARD 0feaeb32-d00e-4d66-bd5a-43b5b83db82c
MCOLITE 70710b6b-3ab4-4a38-9f6d-9f169461650a
MCOPSTN1 4ed3ff63-69d7-4fb7-b984-5aec7f605ca8
MCOPSTN2 5a10155d-f5c1-411a-a8ec-e99aae125390
Service: Yammer
YAMMER_ENTERPRISE 7547a3fe-08ee-4ccb-b430-5077c5041653
YAMMER_EDU 2078e8df-cff6-4290-98cb-5408261a760a
YAMMER_MIDSIZE 41bf139a-4e60-409f-9346-a1361efc6dfb
Next steps
To learn more about the feature set for license management through groups, see the following:
PowerShell examples for group-based licensing in Azure AD
Configure expiration for Office 365 groups (preview)
You can now manage the lifecycle of Office 365 groups by setting expiration features for them. You can set
expiration for only Office 365 groups in Azure Active Directory (Azure AD). Once you set a group to expire:
Owners of the group are notified to renew the group as the expiration nears
Any group that is not renewed is deleted
Any Office 365 group that is deleted can be restored within 30 days by the group owners or the administrator
NOTE
Setting expiration for Office 365 groups requires an Azure AD Premium license for all members of the groups to which
expiration settings are applied.
For information on how to download and install the Azure AD PowerShell cmdlets, see Azure Active Directory
PowerShell for Graph - Public Preview Release 2.0.0.137.
Set group expiration

1. Open the Azure AD admin center with an account that is a global administrator in your Azure AD tenant.
2. Open Azure AD, select Users and groups.
3. Select Group settings and then select Expiration to open the expiration settings.
4. On the Expiration blade, you can:

Set the group lifetime in days. You could select one of the preset values, or a custom value (should be 31
days or more).
Specify an email address where the renewal and expiration notifications should be sent when a group has
no owner.
Select which Office 365 groups expire. You can enable expiration for All Office 365 groups, you can select
from among the Office 365 groups, or you select None to disable expiration for all groups.
Save your settings when you're done by selecting Save.
Email notifications such as this one are sent to the Office 365 group owners 30 days, 15 days, and 1 day prior to
expiration of the group.
The group owner can then select Renew group to renew the Office 365 group, or can select Go to group to see
the members and other details about the group.
When a group expires, the group is deleted one day after the expiration date. An email notification such as this one
is sent to the Office 365 group owners informing them about the expiration and subsequent deletion of their Office
365 group.
The group can be restored by selecting Restore group or by using PowerShell cmdlets, as described in Restore a
deleted Office 365 group in Azure Active Directory.
If the group you're restoring contains documents, SharePoint sites, or other persistent objects, it might take up to
24 hours to fully restore the group and its contents.
NOTE
When you first set up expiration, any groups that are older than the expiration interval are set to 30 days until expiration.
The first renewal notification email is sent out within a day. For example, Group A was created 400 days ago, and the
expiration interval is set to 180 days. When you apply expiration settings, Group A has 30 days before it is deleted, unless
the owner renews it.
When a dynamic group is deleted and restored, it is seen as a new group and re-populated according to the rule. This
process might take up to 24 hours.
Next steps
These articles provide additional information on Azure AD groups.
See existing groups
View or search for your user groups in Azure Active
Directory
This article explains how to view all groups in Azure Active Directory (Azure AD). One of the features of Azure AD
user management is that you can use groups to perform management tasks such as assigning licenses or
permissions to a number of users at once.
How do I see all the groups?


4. On the Users and groups - All groups blade, you can add or remove display columns, filter the list to search
for a group, or make changes to groups that you have sufficient permissions to change.
Next steps
See existing groups
Using a group to manage access to SaaS applications
Using Azure Active Directory (Azure AD) with an Azure AD Premium or Azure AD Basic license, you can use groups
to assign access to a SaaS application that's integrated with Azure AD. For example, if you want to assign access for
the marketing department to use five different SaaS applications, you can create a group that contains the users in
the marketing department, and then assign that group to these five SaaS applications that are needed by the
marketing department. This way you can save time by managing the membership of the marketing department in
one place. Users then are assigned to the application when they are added as members of the marketing group,
and have their assignments removed from the application when they are removed from the marketing group. This
capability can be used with hundreds of applications that you can add from within the Azure AD Application
Gallery.
IMPORTANT
You can use this feature only after you start an Azure AD Premium trial or purchase Azure AD Premium or Azure AD Basic
licenses. Nested group memberships are not supported for group-based assignment to applications at this time.
To assign access for a user or group to a SaaS application

1. In the Azure AD admin center, select Enterprise applications.
2. Select an application that you added from the Application Gallery to open it.
3. Select Users and groups, and then select Add user.
4. On Add Assignment, select Users and groups to open the Users and groups selection list.
5. Select as many groups or users as you want, then click or tap Select to add them to the Add Assignment list.
You can also assign a role to a user at this stage.
6. Select Assign to assign the users or groups to the selected enterprise application.
Next steps
Restore a deleted Office 365 group in Azure Active
Directory
When you delete an Office 365 group in the Azure Active Directory (Azure AD), the deleted group is retained but
not visible for 30 days from the deletion date. This is so that the group and its contents can be restored if needed.
This functionality is restricted exclusively to Office 365 groups in Azure AD. It is not available for security groups
and distribution groups.
NOTE
Don't use Remove-MsolGroup because it purges the group permanently. Always use Remove-AzureADMSGroup to delete an
O365 group.
The permissions required to restore a group can be any of the following:
ROLE PERMISSIONS
Company Administrator, Partner Tier2 support, and InTune Can restore any deleted Office 365 group
Service Admins
User Account Administrator and Partner Tier1 support Can restore any deleted Office 365 group except those
assigned to the Company Administrator role
User Can restore any deleted Office 365 group that they owned
View the deleted Office 365 groups that are available to restore
The following cmdlets can be used to view the deleted groups to verify that the one or ones you're interested in
have not yet been permanently purged. These cmdlets are part of the Azure AD PowerShell module. More
information about this module can be found in the Azure Active Directory PowerShell Version 2 article.
1. Run the following cmdlet to display all deleted Office 365 groups in your tenant that are still available to
restore.
Get-AzureADMSDeletedGroup
2. Alternately, if you know the objectID of a specific group (and you can get it from the cmdlet in step 1), run
the following cmdlet to verify that the specific deleted group has not yet been permanently purged.
Get-AzureADMSDeletedGroup –Id <objectId>
How to restore your deleted Office 365 group

Once you have verified that the group is still available to restore, restore the deleted group with one of the
following steps. If the group contains documents, SP sites, or other persistent objects, it might take up to 24 hours
to fully restore a group and its contents.
1. Run the following cmdlet to restore the group and its contents.
Restore-AzureADMSDeletedDirectoryObject –Id <objectId>
Alternatively, the following cmdlet can be run to permanently remove the deleted group.
Remove-AzureADMSDeletedDirectoryObject –Id <objectId>
How do you know this worked?

To verify that you’ve successfully restored an Office 365 group, run the Get-AzureADGroup –ObjectId <objectId>
cmdlet to display information about the group. After the restore request is completed:
The group will appear in the Left nav bar on Exchange
The plan for the group will appear in Planner
Any Sharepoint sites and all of their contents will be available
The group can be accessed from any of the Exchange endpoints and other Office 365 workloads that support
Office 365 groups
Next steps
These articles provide additional information on Azure Active Directory groups.
See existing groups
Manage the settings for a group in Azure Active
Directory
This article explains how to change the settings for a group in Azure Active Directory (Azure AD).
How do I find and change the settings?


4. On the Users and groups - All groups blade, select a group.
5. On the Group - *groupname* blade, select Properties.
6. When you finish changing properties for the group, select Save.
Next steps
See existing groups
Azure Active Directory cmdlets for configuring group
settings
This article contains instructions for using Azure Active Directory (Azure AD) PowerShell cmdlets to create and
update groups. This content applies only to Office 365 groups.
IMPORTANT
Some settings require an Azure Active Directory Premium P1 license. For more information, see the Template settings table.
For more information on how to prevent non-administrator users to create security groups, set
Set-MsolCompanySettings -UsersPermissionToCreateGroupsEnabled $False as described in Set-
MSOLCompanySettings.
Office 365 Groups settings are configured using a Settings object and a SettingsTemplate object. Initially, you don't
see any Settings objects in your directory, because your directory is configured with the default settings. To change
the default settings, you must create a new settings object using a settings template. Settings templates are
defined by Microsoft. There are several different settings templates. To configure Office 365 group settings for
your directory, you use the template named "Group.Unified". To configure Office 365 group settings on a single
group, use the template named "Group.Unified.Guest". This template is used to manage guest access to an Office
365 group.
The cmdlets are part of the Azure Active Directory PowerShell V2 module. For instructions how to download and
install the module on your computer, see the article Azure Active Directory PowerShell Version 2. You can install
the version 2 release of the module from the PowerShell gallery.
Retrieve a specific settings value

If you know the name of the setting you want to retrieve, you can use the below cmdlet to retrieve the current
settings value. In this example, we're retrieving the value for a setting named "UsageGuidelinesUrl." You can read
more about directory settings and their names further down in this article.
(Get-AzureADDirectorySetting).Values | Where-Object -Property Name -Value UsageGuidelinesUrl -EQ
Create settings at the directory level

These steps create settings at directory level, which apply to all Office 365 groups (Unified groups) in the directory.
1. In the DirectorySettings cmdlets, you must specify the ID of the SettingsTemplate you want to use. If you do
not know this ID, this cmdlet returns the list of all settings templates:
PS C:> Get-AzureADDirectorySettingTemplate
This cmdlet call returns all templates that are available:

Id DisplayName Description
-- ----------- -----------
62375ab9-6b52-47ed-826b-58e47e0e304b Group.Unified ...
08d542b9-071f-4e16-94b0-74abb372e3d9 Group.Unified.Guest Settings for a specific Unified Group
16933506-8a8d-4f0d-ad58-e1db05a5b929 Company.BuiltIn Setting templates define the different
settings that can be used for the associ...
4bc7f740-180e-4586-adb6-38b2e9024e6b Application...
898f1161-d651-43d1-805c-3b0b388a9fc2 Custom Policy Settings ...
5cf42378-d67d-4f36-ba46-e8b86229381d Password Rule Settings ...
2. To add a usage guideline URL, first you need to get the SettingsTemplate object that defines the usage
guideline URL value; that is, the Group.Unified template:
$Template = Get-AzureADDirectorySettingTemplate -Id 62375ab9-6b52-47ed-826b-58e47e0e304b
3. Next, create a new settings object based on that template:
$Setting = $template.CreateDirectorySetting()
4. Then update the usage guideline value:
$setting["UsageGuidelinesUrl"] = "<https://guideline.com>"
5. Finally, apply the settings:
New-AzureADDirectorySetting -DirectorySetting $setting
Upon successful completion, the cmdlet returns the ID of the new settings object:
Id DisplayName TemplateId Values

-- ----------- ---------- ------
c391b57d-5783-4c53-9236-cefb5c6ef323 62375ab9-6b52-47ed-826b-58e47e0e304b {class SettingValue {...
Template settings
Here are the settings defined in the Group.Unified SettingsTemplate. Unless otherwise indicated, these features
require an Azure Active Directory Premium P1 license.
SETTING DESCRIPTION
EnableGroupCreation The flag indicating whether Unified Group creation is allowed

Type: Boolean in the directory by non-admin users. This setting does not
Default: True require an Azure Active Directory Premium P1 license.
GroupCreationAllowedGroupId GUID of the security group for which the members are
Type: String allowed to create Unified Groups even when
Default: “” EnableGroupCreation == false.
SETTING DESCRIPTION
UsageGuidelinesUrl A link to the Group Usage Guidelines.

Type: String
Default: “”
ClassificationDescriptions A comma-delimited list of classification descriptions.

Type: String
Default: “”
DefaultClassification The classification that is to be used as the default classification

Type: String for a group if none was specified.
Default: “”
PrefixSuffixNamingRequirement Do not use. Not implemented.

Type: String
Default: “”
CustomBlockedWordsList Do not use. Not implemented.

Type: String
Default: “”
EnableMSStandardBlockedWords Do not use

Type: Boolean
Default: “False”
AllowGuestsToBeGroupOwner Boolean indicating whether or not a guest user can be an

Type: Boolean owner of groups.
Default: False
AllowGuestsToAccessGroups Boolean indicating whether or not a guest user can have

Type: Boolean access to Unified groups' content. This setting does not
Default: True require an Azure Active Directory Premium P1 license.
GuestUsageGuidelinesUrl The url of a link to the guest usage guidelines.

Type: String
Default: “”
AllowToAddGuests A boolean indicating whether or not is allowed to add guests

Type: Boolean to this directory.
Default: True
ClassificationList A comma-delimited list of valid classification values that can

Type: String be applied to Unified Groups.
Default: “”
Read settings at the directory level

These steps read settings at directory level, which apply to all Office groups in the directory.
1. Read all existing directory settings:
Get-AzureADDirectorySetting -All $True
This cmdlet returns a list of all directory settings:

-- ----------- ---------- ------
c391b57d-5783-4c53-9236-cefb5c6ef323 Group.Unified 62375ab9-6b52-47ed-826b-58e47e0e304b {class
SettingValue {...
2. Read all settings for a specific group:
Get-AzureADObjectSetting -TargetObjectId ab6a3887-776a-4db7-9da4-ea2b0d63c504 -TargetType Groups
3. Read all directory settings values of a specific directory settings object, using Settings Id GUID:
(Get-AzureADDirectorySetting -Id c391b57d-5783-4c53-9236-cefb5c6ef323).values
This cmdlet returns the names and values in this settings object for this specific group:
Name Value
---- -----
ClassificationDescriptions
DefaultClassification
PrefixSuffixNamingRequirement
AllowGuestsToBeGroupOwner False
AllowGuestsToAccessGroups True
GuestUsageGuidelinesUrl
GroupCreationAllowedGroupId
AllowToAddGuests True
UsageGuidelinesUrl <https://guideline.com>
ClassificationList
EnableGroupCreation True
Update settings for a specific group

1. Search for the settings template named "Groups.Unified.Guest"
Get-AzureADDirectorySettingTemplate
Id DisplayName Description
-- ----------- -----------
62375ab9-6b52-47ed-826b-58e47e0e304b Group.Unified ...
08d542b9-071f-4e16-94b0-74abb372e3d9 Group.Unified.Guest Settings for a specific Unified Group
4bc7f740-180e-4586-adb6-38b2e9024e6b Application ...
898f1161-d651-43d1-805c-3b0b388a9fc2 Custom Policy Settings ...
5cf42378-d67d-4f36-ba46-e8b86229381d Password Rule Settings ...
2. Retrieve the template object for the Groups.Unified.Guest template:

$Template = Get-AzureADDirectorySettingTemplate -Id 08d542b9-071f-4e16-94b0-74abb372e3d9
3. Create a new settings object from the template:
$Setting = $Template.CreateDirectorySetting()
4. Set the setting to the required value:
$Setting["AllowToAddGuests"]=$False
5. Create the new setting for the required group in the directory:
New-AzureADObjectSetting -TargetType Groups -TargetObjectId ab6a3887-776a-4db7-9da4-ea2b0d63c504 -

DirectorySetting $Setting

-- ----------- ---------- ------
25651479-a26e-4181-afce-ce24111b2cb5 08d542b9-071f-4e16-94b0-74abb372e3d9 {class
SettingValue {...
Update settings at the directory level

These steps update settings at directory level, which apply to all Unified groups in the directory. These examples
assume there is already a Settings object in your directory.
1. Find the existing Settings object:
Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ

-- ----------- ---------- ------
c391b57d-5783-4c53-9236-cefb5c6ef323 Group.Unified 62375ab9-6b52-47ed-826b-58e47e0e304b {class
SettingValue {...
$setting = Get-AzureADDirectorySetting –Id c391b57d-5783-4c53-9236-cefb5c6ef323
2. Update the value:
$Setting["AllowToAddGuests"] = "false"
3. Update the setting:
Set-AzureADDirectorySetting -Id c391b57d-5783-4c53-9236-cefb5c6ef323 -DirectorySetting $Setting
Remove settings at the directory level

This step removes settings at directory level, which apply to all Office groups in the directory.
Remove-AzureADDirectorySetting –Id c391b57d-5783-4c53-9236-cefb5c6ef323c
Cmdlet syntax reference

You can find more Azure Active Directory PowerShell documentation at Azure Active Directory Cmdlets.
Additional reading
Create attribute-based rules for dynamic group
membership in Azure Active Directory
In Azure Active Directory (Azure AD), you can create advanced rules to enable complex attribute-based dynamic
memberships for groups. This article details the attributes and syntax to create dynamic membership rules for
users or devices.
When any attributes of a user or device change, the system evaluates all dynamic group rules in a directory to
see if the change would trigger any group adds or removes. If a user or device satisfies a rule on a group, they
are added as a member of that group. If they no longer satisfy the rule, they are removed.
NOTE
You can set up a rule for dynamic membership on security groups or Office 365 groups.
This feature requires an Azure AD Premium P1 license for each user member added to at least one dynamic group. It is
not mandatory to actually assign licenses to users for them to be members in dynamic groups, but you do need to have
the minimum number of licenses in the tenant to cover all such users. For example: if you have a total of 1,000 unique
users in all dynamic groups in your tenant, you need to have at least 1,000 licenses for Azure AD Premium P1, or above,
to meet the license requirement.
You can create a dynamic group for devices or users, but you cannot create a rule that contains both user and device
objects.
At the moment, it is not possible to create a device group based on the owning user's attributes. Device membership rules
can only reference immediate attributes of device objects in the directory.
To create an advanced rule

1. Sign in to the Azure AD admin center with an account that is a global administrator or a user account
administrator.
3. Select All groups, and select New group.
4. On the Group blade, enter a name and description for the new group. Select a Membership type of
either Dynamic User or Dynamic Device, depending on whether you want to create a rule for users or
devices, and then select Add dynamic query. You can use the rule builder to build a simple rule, or write
an advanced rule yourself. This article contains more information about available user and device
attributes as well as examples of advanced rules.
5. After creating the rule, select Add query at the bottom of the blade.
6. Select Create on the Group blade to create the group.
TIP
Group creation may fail if the advanced rule you entered was incorrect. A notification will be displayed in the upper-right
hand corner of the portal; it contains an explanation of why the rule could not be accepted by the system. Read it carefully
to understand how you need to adjust the rule to make it valid.
Constructing the body of an advanced rule

The advanced rule that you can create for the dynamic memberships for groups is essentially a binary expression
that consists of three parts and results in a true or false outcome. The three parts are:
Left parameter
Binary operator
Right constant
A complete advanced rule looks similar to this: (leftParameter binaryOperator "RightConstant"), where the
opening and closing parenthesis are optional for the entire binary expression, double quotes are optional as well,
only required for the right constant when it is string, and the syntax for the left parameter is user.property. An
advanced rule can consist of more than one binary expressions separated by the -and, -or, and -not logical
operators.
The following are examples of a properly constructed advanced rule:
(user.department -eq "Sales") -or (user.department -eq "Marketing")

(user.department -eq "Sales") -and -not (user.jobTitle -contains "SDE")
For the complete list of supported parameters and expression rule operators, see sections below. For the
attributes used for device rules, see Using attributes to create rules for device objects.
The total length of the body of your advanced rule cannot exceed 2048 characters.
NOTE
String and regex operations are not case sensitive. You can also perform Null checks, using null as a constant, for example,
user.department -eq null. Strings containing quotes " should be escaped using 'character, for example, user.department -
eq `"Sales".
Supported expression rule operators

The following table lists all the supported expression rule operators and their syntax to be used in the body of
the advanced rule:
OPERATOR SYNTAX
Not Equals -ne
Equals -eq
Not Starts With -notStartsWith
Starts With -startsWith
Not Contains -notContains
Contains -contains
Not Match -notMatch
Match -match
In -in
Not In -notIn
Operator precedence
All Operators are listed below per precedence from lower to higher. Operators on same line are in equal
precedence:
-any -all
-or
-and
-not
-eq -ne -startsWith -notStartsWith -contains -notContains -match –notMatch -in -notIn
All operators can be used with or without the hyphen prefix. Parentheses are needed only when precedence does
not meet your requirements. For example:
user.department –eq "Marketing" –and user.country –eq "US"
is equivalent to:
(user.department –eq "Marketing") –and (user.country –eq "US")
Using the -In and -notIn operators

If you want to compare the value of a user attribute against a number of different values you can use the -In or -
notIn operators. Here is an example using the -In operator:
user.department -In [ "50001", "50002", "50003", “50005”, “50006”, “50007”, “50008”, “50016”, “50020”,
“50024”, “50038”, “50039”, “51100” ]
Note the use of the "[" and "]" at the beginning and end of the list of values. This condition evaluates to True of
the value of user.department equals one of the values in the list.
Query error remediation

The following table lists common errors and how to correct them
QUERY PARSE ERROR ERROR USAGE CORRECTED USAGE
Error: Attribute not supported. (user.invalidProperty -eq "Value") (user.department -eq "value")
Make sure the attribute is on the

supported properties list.
Error: Operator is not supported on (user.accountEnabled -contains true) (user.accountEnabled -eq true)
attribute.
The operator used is not supported for
the property type (in this example, -
contains cannot be used on type
boolean). Use the correct operators for
the property type.
Error: Query compilation error. 1. (user.department -eq "Sales") 1. Missing operator. Use -and or -or
(user.department -eq "Marketing") two join predicates
2. (user.userPrincipalName -match (user.department -eq "Sales") -or

"*@domain.ext") (user.department -eq "Marketing")
2.Error in regular expression used with

-match
(user.userPrincipalName -match
".*@domain.ext"), alternatively:
(user.userPrincipalName -match
"@domain.ext$")
Supported properties
The following are all the user properties that you can use in your advanced rule:
Properties of type boolean
Allowed operators
-eq
-ne
PROPERTIES ALLOWED VALUES USAGE
accountEnabled true false user.accountEnabled -eq true
dirSyncEnabled true false user.dirSyncEnabled -eq true
Properties of type string

Allowed operators
-eq
-ne
-notStartsWith
-StartsWith
-contains
-notContains
-match
-notMatch
-in
-notIn
city Any string value or null (user.city -eq "value")
country Any string value or null (user.country -eq "value")
companyName Any string value or null (user.companyName -eq "value")
department Any string value or null (user.department -eq "value")
displayName Any string value (user.displayName -eq "value")
employeeId Any string value (user.employeeId -eq "value")

(user.employeeId -ne null)
facsimileTelephoneNumber Any string value or null (user.facsimileTelephoneNumber -eq

"value")
givenName Any string value or null (user.givenName -eq "value")
jobTitle Any string value or null (user.jobTitle -eq "value")
mail Any string value or null (SMTP address (user.mail -eq "value")
of the user)
mailNickName Any string value (mail alias of the user) (user.mailNickName -eq "value")
mobile Any string value or null (user.mobile -eq "value")
objectId GUID of the user object (user.objectId -eq "1111111-1111-

1111-1111-111111111111")
onPremisesSecurityIdentifier On-premises security identifier (SID) (user.onPremisesSecurityIdentifier -eq

for users who were synchronized from "S-1-1-11-1111111111-1111111111-
on-premises to the cloud. 1111111111-1111111")
passwordPolicies None DisableStrongPassword (user.passwordPolicies -eq

DisablePasswordExpiration "DisableStrongPassword")
DisablePasswordExpiration,
DisableStrongPassword
physicalDeliveryOfficeName Any string value or null (user.physicalDeliveryOfficeName -eq

"value")
postalCode Any string value or null (user.postalCode -eq "value")
preferredLanguage ISO 639-1 code (user.preferredLanguage -eq "en-US")
sipProxyAddress Any string value or null (user.sipProxyAddress -eq "value")
state Any string value or null (user.state -eq "value")
streetAddress Any string value or null (user.streetAddress -eq "value")
surname Any string value or null (user.surname -eq "value")
telephoneNumber Any string value or null (user.telephoneNumber -eq "value")
usageLocation Two lettered country code (user.usageLocation -eq "US")
userPrincipalName Any string value (user.userPrincipalName -eq

"alias@domain")
userType member guest null (user.userType -eq "Member")
Properties of type string collection

Allowed operators
-contains
-notContains
otherMails Any string value (user.otherMails -contains

"alias@domain")
proxyAddresses SMTP: alias@domain smtp: (user.proxyAddresses -contains "SMTP:

alias@domain alias@domain")
Multi-value properties
Allowed operators
-any (satisfied when at least one item in the collection matches the condition)
-all (satisfied when all items in the collection match the condition)
PROPERTIES VALUES USAGE
assignedPlans Each object in the collection exposes user.assignedPlans -any

the following string properties: (assignedPlan.servicePlanId -eq
capabilityStatus, service, servicePlanId "efb87545-963c-4e0d-99df-
69c6916d9eb0" -and
assignedPlan.capabilityStatus -eq
"Enabled")
Multi-value properties are collections of objects of the same type. You can use -any and -all operators to apply a
condition to one or all of the items in the collection, respectively. For example:
assignedPlans is a multi-value property that lists all service plans assigned to the user. The below expression will
select users who have the Exchange Online (Plan 2) service plan that is also in Enabled state:
user.assignedPlans -any (assignedPlan.servicePlanId -eq "efb87545-963c-4e0d-99df-69c6916d9eb0" -and

assignedPlan.capabilityStatus -eq "Enabled")
(The Guid identifier identifies the Exchange Online (Plan 2) service plan.)
NOTE
This is useful if you want to identify all users for whom an Office 365 (or other Microsoft Online Service) capability has
been enabled, for example to target them with a certain set of policies.
The following expression will select all users who have any service plan that is associated with the Intune service
(identified by service name "SCO"):
user.assignedPlans -any (assignedPlan.service -eq "SCO" -and assignedPlan.capabilityStatus -eq "Enabled")
Use of Null values

To specify a null value in a rule, you can use the null value. Be careful not to use quotes around the word null - if
you do, it will be interpreted as a literal string value. The correct way to reference the null value is as follows:
user.mail –ne null
Extension attributes and custom attributes

Extension attributes and custom attributes are supported in dynamic membership rules.
Extension attributes are synced from on-premises Window Server AD and take the format of
"ExtensionAttributeX", where X equals 1 - 15. An example of a rule that uses an extension attribute would be
(user.extensionAttribute15 -eq "Marketing")
Custom Attributes are synced from on-premises Windows Server AD or from a connected SaaS application and
the the format of "user.extension_[GUID]__[Attribute]", where [GUID] is the unique identifier in AAD for the
application that created the attribute in AAD and [Attribute] is the name of the attribute as it was created. An
example of a rule that uses a custom attribute is
user.extension_c272a57b722d4eb29bfe327874ae79cb__OfficeNumber
The custom attribute name can be found in the directory by querying a user's attribute using Graph Explorer and
searching for the attribute name.
"Direct Reports" Rule

You can create a group containing all direct reports of a manager. When the manager's direct reports change in
the future, the group's membership will be adjusted automatically.
NOTE
1. For the rule to work, make sure the Manager ID property is set correctly on users in your tenant. You can check the
current value for a user on their Profile tab.
2. This rule only supports direct reports. It is currently not possible to create a group for a nested hierarchy, e.g. a group
that includes direct reports and their reports.
To configure the group

1. Follow steps 1-5 from section To create the advanced rule, and select a Membership type of Dynamic User.
2. On the Dynamic membership rules blade, enter the rule with the following syntax:
Direct Reports for "{obectID_of_manager}"
An example of a valid rule:
Direct Reports for "62e19b97-8b3d-4d4a-a106-4ce66896a863"
where “62e19b97-8b3d-4d4a-a106-4ce66896a863” is the objectID of the manager. The object ID can be

found on manager's Profile tab.
3. After saving the rule, all users with the specified Manager ID value will be added to the group.
Using attributes to create rules for device objects

You can also create a rule that selects device objects for membership in a group. The following device attributes
can be used.
DEVICE ATTRIBUTE VALUES EXAMPLE
accountEnabled true false (device.accountEnabled -eq true)
displayName any string value (device.displayName -eq "Rob Iphone”)
deviceOSType any string value (device.deviceOSType -eq "iPad") -or

(device.deviceOSType -eq "iPhone")
deviceOSVersion any string value (device.OSVersion -eq "9.1")
deviceCategory a valid device category name (device.deviceCategory -eq "BYOD")
deviceManufacturer any string value (device.deviceManufacturer -eq

"Samsung")
DEVICE ATTRIBUTE VALUES EXAMPLE
deviceModel any string value (device.deviceModel -eq "iPad Air")
deviceOwnership Personal, Company, Unknown (device.deviceOwnership -eq

"Company")
domainName any string value (device.domainName -eq

"contoso.com")
enrollmentProfileName Apple Device Enrollment Profile name (device.enrollmentProfileName -eq

"DEP iPhones")
isRooted true false (device.isRooted -eq true)
managementType MDM (for mobile devices) (device.managementType -eq "MDM")

PC (for computers managed by the
Intune PC agent)
organizationalUnit any string value matching the name of (device.organizationalUnit -eq "US
the organizational unit set by an on- PCs")
premises Active Directory
deviceId a valid Azure AD device ID (device.deviceId -eq "d4fe7726-5966-

431c-b3b8-cddc8fdb717d")
objectId a valid Azure AD object ID (device.objectId -eq 76ad43c9-32c5-

45e8-a272-7b58b58f596d")
Changing dynamic membership to static, and vice versa

It is possible to change how membership is managed in a group. This is useful when you want to keep the same
group name and ID in the system, so any existing references to the group are still valid; creating a new group
would require updating those references.
We are in the process of updating the Azure portal to support this functionality. In the meantime, you can use
PowerShell cmdlets as shown below.
WARNING
When changing an existing static group to a dynamic group, all existing members will be removed from the group, and
then the membership rule will be processed to add new members. If the group is used to control access to apps or
resources, the original members may lose access until the membership rule is fully processed.
It is a recommended practice to test the new membership rule beforehand to make sure that the new membership in the
group is as expected.
Using PowerShell to change membership management on a group
NOTE
To change dynamic group properties you will need to use cmdlets from the preview version of Azure AD PowerShell
Version 2. You can install the preview from here.
Here is an example of functions that switch membership management on an existing group. Note that care is
taken to correctly manipulate the GroupTypes property and preserve any values that may exist there, unrelated
to dynamic membership.
#The moniker for dynamic groups as used in the GroupTypes property of a group object
$dynamicGroupTypeString = "DynamicMembership"
function ConvertDynamicGroupToStatic
{
Param([string]$groupId)
#existing group types

[System.Collections.ArrayList]$groupTypes = (Get-AzureAdMsGroup -Id $groupId).GroupTypes
if($groupTypes -eq $null -or !$groupTypes.Contains($dynamicGroupTypeString))

{
throw "This group is already a static group. Aborting conversion.";
}
#remove the type for dynamic groups, but keep the other type values
$groupTypes.Remove($dynamicGroupTypeString)
#modify the group properties to make it a static group: i) change GroupTypes to remove the dynamic type,
ii) pause execution of the current rule
Set-AzureAdMsGroup -Id $groupId -GroupTypes $groupTypes.ToArray() -MembershipRuleProcessingState
"Paused"
}
function ConvertStaticGroupToDynamic
{
Param([string]$groupId, [string]$dynamicMembershipRule)
#existing group types

[System.Collections.ArrayList]$groupTypes = (Get-AzureAdMsGroup -Id $groupId).GroupTypes
if($groupTypes -ne $null -and $groupTypes.Contains($dynamicGroupTypeString))

{
throw "This group is already a dynamic group. Aborting conversion.";
}
#add the dynamic group type to existing types
$groupTypes.Add($dynamicGroupTypeString)
#modify the group properties to make it a static group: i) change GroupTypes to add the dynamic type,
ii) start execution of the rule, iii) set the rule
Set-AzureAdMsGroup -Id $groupId -GroupTypes $groupTypes.ToArray() -MembershipRuleProcessingState "On" -
MembershipRule $dynamicMembershipRule
}
To make a group static:
ConvertDynamicGroupToStatic "a58913b2-eee4-44f9-beb2-e381c375058f"
To make a group dynamic:
ConvertStaticGroupToDynamic "a58913b2-eee4-44f9-beb2-e381c375058f" "user.displayName -startsWith ""Peter"""
Next steps
These articles provide additional information on groups in Azure Active Directory.
See existing groups
Set up Azure Active Directory for self-service group
management
Your users can create and manage their own security groups or Office 365 groups in Azure Active Directory
(Azure AD). Users can also request security group or Office 365 group memberships, and then the owner of the
group can approve or deny membership. Day-to-day control of group membership can be delegated to the
people who understand the business context for that membership. Self-service group management features are
available only for security groups and Office 365 groups, but not for mail-enabled security groups or distribution
lists.
Self-service group management currently services two essential scenarios: delegated group management and
self-service group management.
Delegated group management An example is an administrator who is managing access to a SaaS
application that the company is using. Managing these access rights is becoming cumbersome, so this
administrator asks the business owner to create a new group. The administrator assigns access for the
application to the new group, and adds to the group all people already accessing to the application. The
business owner then can add more users, and those users are automatically provisioned to the application.
The business owner doesn't need to wait for the administrator to manage access for users. If the administrator
grants the same permission to a manager in a different business group, then that person can also manage
access for their own users. Neither the business owner nor the manager can view or manage each other’s
users. The administrator can still see all users who have access to the application and block access rights if
needed.
Self-service group management An example of this scenario is two users who both have SharePoint Online
sites that they set up independently. They want to give each other’s teams access to their sites. To accomplish
this, they can create one group in Azure AD, and in SharePoint Online each of them selects that group to
provide access to their sites. When someone wants access, they request it from the Access Panel, and after
approval they get access to both SharePoint Online sites automatically. Later, one of them decides that all
people accessing the site should also get access to a particular SaaS application. The administrator of the SaaS
application can add access rights for the application to the SharePoint Online site. From then on, any requests
that get approved gives access to the two SharePoint Online sites and also to this SaaS application.
Make a group available for user self-service

2. Select Users and groups, and then select Group settings.
3. Set Self-service group management enabled to Yes.
4. Set Users can create security groups or Users can create Office 365 groups to Yes.
When these settings are enabled, all users in your directory are allowed to create new security groups
and add members to these groups. These new groups would also show up in the Access Panel for all
other users. If the policy setting on the group allows it, other users can create requests to join these
groups.
When these settings are disabled, users can't create groups and can't change existing groups for which
they are an owner. However, they can still manage the memberships of those groups and approve
requests from other users to join their groups.
You can also use Users who can manage security groups and Users who can manage Office 365 groups to
achieve more granular access control over self-service group management for your users. When Users can
create groups is enabled, all users in your tenant are allowed to create new groups and add members to these
groups. By setting them to Some, you are restricting group management to only a limited group of users. When
this switch is set to Some, you must add users to the group SSGMSecurityGroupsUsers before they can create
new groups and add members to them. By setting Users who can use self-service for security groups and
Users who can manage Office 365 groups to All, you enable all users in your tenant to create new groups.
You can also use Group that can manage security groups or Group that can manage Office 365 groups to
specify a single group whose members can use self-service.
Next steps
Manage access to resources with Azure Active Directory groups
Integrate your on-premises identities with Azure Active Directory
Troubleshooting dynamic memberships for groups
I configured a rule on a group but no memberships get updated in the group

Verify the values for user attributes on the rule: are there users that satisfy the rule? If everything looks good,
please allow some time for the group to populate. Depending on the size of your tenant, the group may take up to
24 hours for populating for the first time or after a rule change.
I configured a rule, but now the existing members of the rule are removed
This is expected behavior. Existing members of the group are removed when a rule is enabled or changed. The
users returned from evaluation of the rule are added as members to the group.
I don’t see membership changes instantly when I add or change a rule, why not?
Dedicated membership evaluation is done periodically in an asynchronous background process. How long the
process takes is determined by the number of users in your directory and the size of the group created as a result
of the rule. Typically, directories with small numbers of users will see the group membership changes in less than a
few minutes. Directories with a large number of users can take 30 minutes or longer to populate.
Next steps
Azure Active Directory reporting
With Azure Active Directory reporting, you can gain insights into how your environment is doing.
The provided data enables you to:
Determine how your apps and services are utilized by your users
Detect potential risks affecting the health of your environment
Troubleshoot issues preventing your users from getting their work done
The reporting architecture relies on two main pillars:
Security reports
Activity reports
Security reports
The security reports in Azure Active Directory help you to protect your organization's identities.
There are two types of security reports in Azure Active Directory:
Users flagged for risk - From the users flagged for risk security report, you get an overview of user
accounts that might have been compromised.
Risky sign-ins - With the risky sign-in security report, you get an indicator for sign-in attempts that might
have been performed by someone who is not the legitimate owner of a user account.
What Azure AD license do you need to access a security report?
All editions of Azure Active Directory provide you with users flagged for risk and risky sign-ins reports.
However, the level of report granularity varies between the editions:
In the Azure Active Directory Free and Basic editions, you already get a list of users flagged for risk and
risky sign-ins.
The Azure Active Directory Premium 1 edition extends this model by also enabling you to examine some
of the underlying risk events that have been detected for each report.
The Azure Active Directory Premium 2 edition provides you with the most detailed information about
the underlying risk events and it also enables you to configure security policies that automatically respond
to configured risk levels.
Activity reports
There are two types of activity reports in Azure Active Directory:
Audit logs - The audit logs activity report provides you with access to the history of every task performed
in your tenant.
Sign-ins - With the sign-ins activity report, you can determine, who has performed the tasks reported by
the audit logs report.
The audit logs report provides you with records of system activities for compliance. Amongst others, the
provided data enables you to address common scenarios such as:
Someone in my tenant got access to an admin group. Who gave them access?
I want to know the list of users signing into a specific app since I recently onboarded the app and want to
know if it’s doing well
I want to know how many password resets are happening in my tenant
What Azure AD license do you need to access the audit logs report?
The audit logs report is available for features for which you have licenses. If you have a license for a specific
feature, you also have access to the audit log information for it.
For more details, see Comparing generally available features of the Free, Basic, and Premium editions in
Azure Active Directory features and capabilities.
The sign-ins activity report enables to to find answers to questions such as:
What is the sign-in pattern of a user?
How many users have users signed in over a week?
What’s the status of these sign-ins?
What Azure AD license do you need to access the sign-ins activity report?
To access the sign-ins activity report, your tenant must have an Azure AD Premium license associated with it.
Programmatic access
In addition to the user interface, Azure Active Directory reporting also provides you with programmatic access to
the reporting data. The data of these reports can be very useful to your applications, such as SIEM systems, audit,
and business intelligence tools. The Azure AD reporting APIs provide programmatic access to the data through a
set of REST-based APIs. You can call these APIs from a variety of programming languages and tools.
Next steps
If you want to know more about the various report types in Azure Active Directory, see:
Users flagged for risk report
Risky sign-ins report
Audit logs report
Sign-ins logs report
If you want to know more about accessing the the reporting data using the reporting API, see:
Getting started with the Azure Active Directory reporting API
Sign-in activity reports in the Azure Active Directory
portal
With Azure Active Directory (Azure AD) reporting in the Azure portal, you can get the information you need to
determine how your environment is doing.
The reporting architecture in Azure Active Directory consists of the following components:
Activity
Sign-in activities – Information about the usage of managed applications and user sign-in activities
Audit logs - System activity information about users and group management, your managed
applications and directory activities.
Security
Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by
someone who is not the legitimate owner of a user account. For more details, see Risky sign-ins.
Users flagged for risk - A risky user is an indicator for a user account that might have been
compromised. For more details, see Users flagged for risk.
This topic gives you an overview of the sign-in activities.
Pre-requisite
Who can access the data?
Users in the Security Admin or Security Reader role
Global Admins
Any user (non-admins) can access their own sign-ins
What Azure AD license do you need to access sign-in activity?
Your tenant must have an Azure AD Premium license associated with it to see the all up sign-in activity report
Signs-in activities
With the information provided by the user sign-in report, you find answers to questions such as:
How many users have signed in over a week?
Your first entry point to all sign-in activities data is Sign-ins in the Activity section of Azure Active.
An audit log has a default list view that shows:
the related user
the application the user has signed-in to
the sign-in status
the sign-in time
You can customize the list view by clicking Columns in the toolbar.
This enables you to display additional fields or remove fields that are already displayed.
By clicking an item in the list view, you get all available details about it.
Filtering sign-in activities

To narrow down the reported data to a level that works for you, you can filter the sign-ins data using the following
fields:
Time interval
User
Application
Client
Sign-in status
The time interval filter enables to you to define a timeframe for the returned data.
Possible values are:
1 month
7 days
24 hours
Custom
When you select a custom timeframe, you can configure a start time and an end time.
The user filter enables you to specify the name or the user principal name (UPN) of the user you care about.
The application filter enables you to specify the name of the application you care about.
The client filter enables you to specify information about the device you care about.
The sign-in status filter enables you to select one of the following filter:
All
Success
Failure
Sign-in activities shortcuts

In addition to Azure Active Directory, the Azure portal provides you with two additional entry points to sign-in
activities data:
Users and groups
Enterprise applications
Users and groups sign-ins activities
With the information provided by the user sign-in report, you find answers to questions such as:
How many users have users signed in over a week?
Your entry point to this data is the user sign-in graph in the Overview section under Users and groups.
The user sign-in graph shows weekly aggregations of sign ins for all users in a given time period. The default for
the time period is 30 days.
When you click on a day in the sign-in graph, you get a detailed list of the sign-in activities for this day.
Each row in the sign-in activities list gives you the detailed information about the selected sign-in such as:
Who has signed in?
What was the related UPN?
What application was the target of the sign-in?
What is the IP address of the sign-in?
What was the status of the sign-in?
The Sign-ins option gives you a complete overview of all user sign-ins.
Usage of managed applications
With an application-centric view of your sign-in data, you can answer questions such as:
Who is using my applications?
What are the top 3 applications in your organization?
I have recently rolled out an application. How is it doing?
Your entry point to this data is the top 3 applications in your organization within the last 30 days report in the
Overview section under Enterprise applications.
The app usage graph weekly aggregations of sign ins for your top 3 applications in a given time period. The
default for the time period is 30 days.
If you want to, you can set the focus on a specific application.
When you click on a day in the app usage graph, you get a detailed list of the sign-in activities.
The Sign-ins option gives you a complete overview of all sign-in events to your applications.
Next steps
If you want to know more about sign-in activity error codes, see the Sign-in activity report error codes in the Azure
Active Directory portal.
Audit activity reports in the Azure Active Directory
portal
With reporting in Azure Active Directory (Azure AD), you can get the information you need to determine how your
environment is doing.
The reporting architecture in Azure AD consists of the following components:
Activity
Audit logs - System activity information about users and group management, your managed
applications and directory activities.
Security
Users flagged for risk - A risky user is an indicator for a user account that might have been
compromised. For more details, see Users flagged for risk.
This topic gives you an overview of the audit activities.

Global Admins
Individual users (non-admins) can see their own activities
Audit logs
The audit logs in Azure Active Directory provide records of system activities for compliance.
Your first entry point to all auditing data is Audit logs in the Activity section of Azure Active Directory.
the date and time of the occurrence
the initiator / actor (who) of an activity
the activity (what)
the target
This enables you to display additional fields or remove fields that are already displayed.
By clicking an item in the list view, you get all available details about it.
Filtering audit logs

To narrow down the reported data to a level that works for you, you can filter the audit data using the following
fields:
Date range
Initiated by (Actor)
Category
Activity resource type
Activity
The date range filter enables to you to define a timeframe for the returned data.
Possible values are:
1 month
7 days
24 hours
Custom
When you select a custom timeframe, you can configure a start time and an end time.
The initiated by filter enables you to define an actor's name or its universal principal name (UPN).
The category filter enables you to select one of the following filter:
All
Core category
Core directory
Self-service password management
Self-service group management
Account provisioning- Automated password rollover
Invited users
MIM service
Identity Protection
B2C
The activity resource type filter enables you to select one of the following filters:
All
Group
Directory
User
Application
Policy
Device
Other
When you select Group as activity resource type, you get an additional filter category that enables you to also
provide a Source:
Azure AD
O365
The activity filter is based on the category and Activity resource type selection you make. You can select a specific
activity you want to see or choose all.
You can get the list of all Audit Activities using the Graph API
https://graph.windows.net/$tenantdomain/activities/auditActivityTypes?api-version=beta, where $tenantdomain =
your domain name or refer to the article audit report events.
Audit logs shortcuts
In addition to Azure Active Directory, the Azure portal provides you with two additional entry points to audit
data:
Users and groups
Enterprise applications
Users and groups audit logs
With user and group-based audit reports, you can get answers to questions such as:
What types of updates have been applied the users?
How many users were changed?
How many passwords were changed?
What has an administrator done in a directory?
What are the groups that have been added?
Are there groups with membership changes?
Have the owners of group been changed?
What licenses have been assigned to a group or a user?
If you just want to review auditing data that is related to users and groups, you can find a filtered view under
Audit logs in the Activity section of the Users and Groups. This entry point has Users and groups as
preselected Activity Resource Type.
Enterprise applications audit logs

With application-based audit reports, you can get answers to questions such as:
What are the applications that have been added or updated?
What are the applications that have been removed?
Has a service principle for an application changed?
Have the names of applications been changed?
Who gave consent to an application?
If you just want to review auditing data that is related to your applications, you can find a filtered view under Audit
logs in the Activity section of the Enterprise applications blade. This entry point has Enterprise applications
as preselected Activity Resource Type.
You can filter this view further down to just groups or just users.
Next steps
For an overview of reporting, see the Azure Active Directory reporting.
Users flagged for risk security report in the Azure
Active Directory portal
With the security reports in the Azure Active Directory (Azure AD), you can gain insights into the probability of
compromised user accounts in your environment.
Azure Active Directory detects suspicious actions that are related to your user accounts. For each detected action, a
record called risk event is created. For more information, see Azure Active Directory risk events.
The detected risk events are used to calculate:
someone who is not the legitimate owner of a user account. For more information, see Risky sign-ins.
Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.
For more information, see Users flagged for risk.
In the Azure portal, you can find the security reports on the Azure Active Directory blade in the Security section.

All editions of Azure Active Directory provide you with users flagged for risk reports.
In the Azure Active Directory Free and Basic editions, you already get a list of users flagged for risk.
The Azure Active Directory Premium 2 edition provides you with the most detailed information about all
underlying risk events and enables you to configure security policies that automatically respond to
configured risk levels.
Azure Active Directory free and basic edition

The users flagged for risk report in the Azure Active Directory free and basic editions provides you with a list of
user accounts that may have been compromised.
Selecting a user opens the related user data blade. For users that are at risk, you can review the user’s sign-in
history and reset the password if necessary.
This dialog provides you with an option to:

Download the report
Search users
Azure Active Directory premium editions

The users flagged for risk report in the Azure Active Directory premium editions provides you with:
A list of user accounts that may have been compromised
Aggregated information about the risk event types that have been detected
An option to download the report
An option to configure a user risk remediation policy
When you select a user, you get a detailed report view for this user that enables you to:
Open the All sign-ins view
Reset the user's password
Dismiss all events
Investigate reported risk events for the user.
To investigate a risk event, select one from the list to open the Details blade for this risk event. On the Details
blade, you have the option to either manually close a risk event or reactivate a manually closed risk event.
Next steps
For more information about Azure Active Directory Identity Protection, see Azure Active Directory Identity
Protection.
Risky sign-ins report in the Azure Active Directory
portal
With the security reports in Azure Active Directory (Azure AD) you can gain insights into the probability of
compromised user accounts in your environment.
Azure AD detects suspicious actions that are related to your user accounts. For each detected action, a record
called risk event is created. For more details, see Azure Active Directory risk events.
The detected risk events are used to calculate:
For more details, see Users flagged for risk.
In the Azure portal, you can find the security reports on the Azure Active Directory blade in the Security section.

All editions of Azure Active Directory provide you with risky sign-ins reports.
In the Azure Active Directory Free and Basic editions, you already get a list of risky sign-ins.
The Azure Active Directory Premium 2 edition provides you with the most detailed information about all
underlying risk events and it also enables you to configure security policies that automatically respond to
configured risk levels.
Azure Active Directory free and basic edition

The Azure Active Directory free and basic editions provide you with a list of risky sign-ins that have been detected
for your users. This report lists:
User - The name of the user that was used during the sign-in operation
IP - The IP address of the device that was used to connect to Azure Active Directory
Location - The location used to connect to Azure Active Directory
Sign-in time - The time when the sign-in was performed
Status - The status of the sign-in
Based on your investigation of the risky sign-in, you can provide feedback to Azure Active Directory in form of the
following actions:
Resolve
Mark as false positive
Ignore
Reactivate
For more details, see Closing risk events manually.

This report provides you with an option to:
Search resources
Download the report data
Azure Active Directory premium editions

The risky sign-ins report in the Azure Active Directory premium editions provides you with:
Aggregated information about the risk event types that have been detected
An option to download the report
When you select a risk event, you get a detailed report view for this risk event that enables you to:
An option to configure a user risk remediation policy
Review the detection timeline for the risk event
Review a list of users for which this risk event has been detected
Manually close risk events or reactivate a manually closed risk event.
When you select a user, you get a detailed report view for this user that enables you to:
Open the All sign-ins view
Reset the user's password
Dismiss all events
Investigate reported risk events for the user.
To investigate a risk event, select one from the list.
This opens the Details blade for this risk event. On the Details blade, you have the option to either manually close
a risk event or reactivate a manually closed risk event.
Next steps
For more information about Azure Active Directory Identity Protection, see Azure Active Directory Identity
Protection.
Azure Active Directory risk events
The vast majority of security breaches take place when attackers gain access to an environment by stealing a user’s
identity. Discovering compromised identities is no easy task. Azure Active Directory uses adaptive machine
learning algorithms and heuristics to detect suspicious actions that are related to your user accounts. Each
detected suspicious action is stored in a record called risk event.
Currently, Azure Active Directory detects six types of risk events:
Users with leaked credentials
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activity
Sign-ins from unfamiliar locations
The insight you get for a detected risk event is tied to your Azure AD subscription. With the Azure AD Premium P2
edition, you get the most detailed information about all underlying detections. With the Azure AD Premium P1
edition, detections that are not covered by your license appear as the risk event Sign-in with additional risk
detected.
This topic gives you a detailed overview of what risk events are and how you can use them to protect your Azure
AD identities.
Risk event types

The risk event type property is an identifier for the suspicious action a risk event record has been created for.
Microsoft's continuous investments into the detection process lead to:
Improvements to the detection accuracy of existing risk events
New risk event types that will be added in the future
Leaked credentials
When cybercriminals compromise valid passwords of legitimate users, the criminals often share those credentials.
This is usually done by posting them publicly on the dark web or paste sites or by trading or selling the credentials
on the black market. The Microsoft leaked credentials service acquires username / password pairs by monitoring
public and dark web sites and by working with:
Researchers
Law enforcement
Security teams at Microsoft
Other trusted sources
When the service acquires username / password pairs, they are checked against AAD users' current valid
credentials. When a match is found, it means that a user's password has been compromised, and a leaked
credentials risk event is created.
This risk event type identifies users who have successfully signed in from an IP address that has been identified as
an anonymous proxy IP address. These proxies are used by people who want to hide their device’s IP address, and
may be used for malicious intent.
This risk event type identifies two sign-ins originating from geographically distant locations, where at least one of
the locations may also be atypical for the user, given past behavior. Among several other factors, this machine
learning algorithm takes into account the time between the two sign-ins and the time it would have taken for the
user to travel from the first location to the second, indicating that a different user is using the same credentials.
The algorithm ignores obvious "false positives" contributing to the impossible travel conditions, such as VPNs and
locations regularly used by other users in the organization. The system has an initial learning period of 14 days
during which it learns a new user’s sign-in behavior.
Sign-in from unfamiliar locations
This risk event type considers past sign-in locations (IP, Latitude / Longitude and ASN) to determine new /
unfamiliar locations. The system stores information about previous locations used by a user, and considers these
“familiar” locations. The risk event is triggered when the sign-in occurs from a location that's not already in the list
of familiar locations. The system has an initial learning period of 30 days, during which it does not flag any new
locations as unfamiliar locations. The system also ignores sign-ins from familiar devices, and locations that are
geographically close to a familiar location.
This risk event type identifies sign-ins from devices infected with malware, that are known to actively communicate
with a bot server. This is determined by correlating IP addresses of the user’s device against IP addresses that were
in contact with a bot server.
This risk event type identifies IP addresses from which a high number of failed sign-in attempts were seen, across
multiple user accounts, over a short period of time. This matches traffic patterns of IP addresses used by attackers,
and is a strong indicator that accounts are either already or are about to be compromised. This is a machine
learning algorithm that ignores obvious "false-positives", such as IP addresses that are regularly used by other
users in the organization. The system has an initial learning period of 14 days where it learns the sign-in behavior
of a new user and new tenant.
Detection type
The detection type property is an indicator (Real-time or Offline) for the detection timeframe of a risk event.
Currently, most risk events are detected offline in a post-processing operation after the risk event has occurred.
The following table lists the amount of time it takes for a detection type to show up in a related report:
DETECTION TYPE REPORTING LATENCY
Real-time 5 to 10 minutes
DETECTION TYPE REPORTING LATENCY
Offline 2 to 4 hours
For the risk event types Azure Active Directory detects, the detection types are:
RISK EVENT TYPE DETECTION TYPE
Users with leaked credentials Offline
Sign-ins from anonymous IP addresses Real-time
Impossible travel to atypical locations Offline
Sign-ins from unfamiliar locations Real-time
Sign-ins from infected devices Offline
Sign-ins from IP addresses with suspicious activity Offline
Risk level
The risk level property of a risk event is an indicator (High, Medium, or Low) for the severity and the confidence of
a risk event. This property helps you to prioritize the actions you must take.
The severity of the risk event represents the strength of the signal as a predictor of identity compromise.
The confidence is an indicator for the possibility of false positives.
For example,
High: High confidence and high severity risk event. These events are strong indicators that the user’s
identity has been compromised, and any user accounts impacted should be remediated immediately.
Medium: High severity, but lower confidence risk event, or vice versa. These events are potentially risky,
and any user accounts impacted should be remediated.
Low: Low confidence and low severity risk event. This event may not require an immediate action, but when
combined with other risk events, may provide a strong indication that the identity is compromised.
Leaked credentials
Leaked credentials risk events are classified as a High, because they provide a clear indication that the user name
and password are available to an attacker.
The risk level for this risk event type is Medium because an anonymous IP address is not a strong indication of an
account compromise.
We recommend that you immediately contact the user to verify if they were using anonymous IP addresses.
Impossible travel is usually a good indicator that a hacker was able to successfully sign-in. However, false-positives
may occur when a user is traveling using a new device or using a VPN that is typically not used by other users in
the organization. Another source of false-positives is applications that incorrectly pass server IPs as client IPs,
which may give the appearance of sign-ins taking place from the data center where that application’s back-end is
hosted (often these are Microsoft datacenters, which may give the appearance of sign-ins taking place from
Microsoft owned IP addresses). As a result of these false-positives, the risk level for this risk event is Medium.
TIP
You can reduce the amount of reported false-positives for this risk event type by configuring named locations.
Sign-in from unfamiliar locations

Unfamiliar locations can provide a strong indication that an attacker is able to use a stolen identity. False-positives
may occur when a user is traveling, is trying out a new device, or is using a new VPN. As a result of these false
positives, the risk level for this event type is Medium.
This risk event identifies IP addresses, not user devices. If several devices are behind a single IP address, and only
some are controlled by a bot network, sign-ins from other devices my trigger this event unnecessarily, which is the
reason for classifying this risk event as Low.
We recommend that you contact the user and scan all the user's devices. It is also possible that a user's personal
device is infected, or as mentioned earlier, that someone else was using an infected device from the same IP
address as the user. Infected devices are often infected by malware that have not yet been identified by anti-virus
software, and may also indicate as bad user habits that may have caused the device to become infected.
For more information about how to address malware infections, see the Malware Protection Center.
We recommend that you contact the user to verify if they actually signed in from an IP address that was marked as
suspicious. The risk level for this event type is “Medium” because several devices may be behind the same IP
address, while only some may be responsible for the suspicious activity.
Next steps
Risk events are the foundation for protecting your Azure AD's identities. Azure AD can currently detect six risk
events:
RISK EVENT TYPE RISK LEVEL DETECTION TYPE
Users with leaked credentials High Offline
Sign-ins from anonymous IP addresses Medium Real-time
Impossible travel to atypical locations Medium Offline
Sign-ins from unfamiliar locations Medium Real-time

RISK EVENT TYPE RISK LEVEL DETECTION TYPE
Sign-ins from infected devices Low Offline
Sign-ins from IP addresses with Medium Offline

suspicious activity
Where can you find the risk events that have been detected in your environment? There are two places where you
review reported risk events:
Azure AD reporting - Risk events are part of Azure AD's security reports. For more details, see the users at
risk security report and the risky sign-ins security report.
Azure AD Identity Protection - Risk events are also part of Azure Active Directory Identity Protection's
reporting capabilities.
While the detection of risk events already represents an important aspect of protecting your identities, you also
have the option to either manually address them or even implement automated responses by configuring
conditional access policies. For more details, see of Azure Active Directory Identity Protection's.
Azure Active Directory reporting FAQ
This article includes answers to frequently asked questions about Azure Active Directory (Azure AD) reporting. For
more information, see Azure Active Directory reporting.
Q: I am using the https://graph.windows.net/<tenant-name>/reports/ endpoint APIs to pull Azure AD
audit and integrated application usage reports into our reporting systems programmatically. What
should I switch to?
A: Look up our API reference documentation to see how you can use the new APIs to access activity reports. This
endpoint has two reports (Audit and Sign-ins) which provide all the data you got in the old API endpoint. This new
endpoint also has a sign-ins report with the Azure AD Premium license that you can use to get app usage, device
usage, and user sign-in information.
Q: I am using the https://graph.windows.net/<tenant-name>/reports/ endpoint APIs to pull Azure AD

security reports (specific types of detections, such as leaked credentials or sign-ins from anonymous IP
addresses) into our reporting systems programmatically. What should I switch to?
A: You can use the Identity Protection risk events API to access security detections through Microsoft Graph. This
new format gives greater flexibility in how you can query data, with advanced filtering, field selection, and more,
and standardizes risk events into one type for easier integration into SIEMs and other data collection tools. Because
the data is in a different format, you can't substitute a new query for your old queries. However, the new API uses
Microsoft Graph, which is the Microsoft standard for such APIs as O365 or Azure AD. So the work required can
either extend your current MS Graph investments or help you begin your transition to this new standard platform.
Q: What is the data retention for activity logs (Audit and Sign-ins) in the Azure portal?
A: We provide 7 days of data for our free customers, or you can access data for up to 30 days by purchasing an
Azure AD Premium 1 or Premium 2 license. For more information on report retention, see Azure Active Directory
report retention policies.
Q: How long does it take until I can see the Activity data after I have completed my task?
A: Audit activity logs have a latency ranging from 15 minutes to an hour. Sign-in activity logs can take from 15
minutes to up to 2 hours for some records.
Q: Do I need to be a global admin to see the activity sign-ins to the Azure portal or to get data through
the API?
A: No. You must be a Security Reader, a Security Admin, or a Global Admin to get reporting data in the Azure
portal or through the API.
Q: Can I get Office 365 activity log information through the Azure portal?
A: Even though Office 365 activity and Azure AD activity logs share a lot of the directory resources, if you want a
full view of the Office 365 activity logs, you should go to the Office 365 Admin Center to get Office 365 Activity log
information.
Q: Which APIs do I use to get information about Office 365 Activity logs?
A: Use the Office 365 Management APIs to access the Office 365 Activity logs through an API.
Q: How many records I can download from Azure portal?
A: You can download up to 120K records from the Azure portal. The records are sorted by most recent and by
default, you get the most recent 120K records.
Q: How many records can I query through the activities API?

A: You can query up to 1 million records (if you don’t use the top operator, which sorts the record by most recent).
If you do use the “top” operator, you can query up to 500K records. You can find sample queries on how to use the
API here here.
Q: How do I get a premium license?

A: See Getting started with Azure Active Directory Premium for an answer to this question.
Q: How soon should I see activities data after getting a premium license?
A: If you already have activities data as a free license, then you can see the same data. If you don’t have any data,
then it will take one or two days.
Q: Do I see last month's data after getting an Azure AD premium license?

A: If you have recently switched to a Premium version (including a trial version), you can see data up to 7 days
initially. When data accumulates, you will see up to 30 days.
Q: There is a risk event in Identity Protection but I’m not seeing corresponding sign-in in the all sign-ins.
Is this expected?
A: Yes, Identity Protection evaluates risk for all authentication flows whether if be interactive or non-interactive.
However, all sign-ins only report shows only the interactive sign-ins.
Q: How can I download the “Users flagged for risk” report in Azure portal?
A: The option to download Users flagged for risk report will be added soon.
Q: How do I know why a sign-in or a user was flagged risky in the Azure portal?
A: Premium edition customers can learn more about the underlying risk events by clicking on the user in “Users
flagged for risk” or by clicking on the “Risky sign-ins”. Free and Basic edition customers get to see the at-risk users
and sign-ins without the underlying risk event information.
Q: How are IP addresses calculated in the sign-ins and risky sign-ins report?
A: IP addresses are issued in such a way that there is no definitive connection between an IP address and where the
computer with that address is physically located. This is complicated by factors such as mobile providers and VPNs
issuing IP addresses from central pools often very far from where the client device is actually used. Given the
above, converting IP address to a physical location is a best effort based on traces, registry data, reverse look ups
and other information.
Q: What does the risk event "Sign-in with additional risk detected" signify?
A: To give you an insight into all the risky sign-ins in your environment we show the risk event "Sign-in with
additional risk detected" for sign-ins considered risky because of detections exclusive to Azure AD Identity
Protection subscribers.
Named locations in Azure Active Directory
With named locations, you can label trusted IP address ranges in your organization. Azure Active Directory uses
named locations in the context of:
The detection of risk events to reduce the number of reported false positives.
Location-based conditional access.
This article explains, how you can configure named locations in your environment.
Entry points
You can access the named location configuration page in the Security section of the Azure Active Directory page
by clicking:
Conditional access:
In the Manage section, click Named locations.
Risky sign-ins:
In the toolbar on the top, click Add known IP address ranges.
Configuration example
To configure a named location:
1. Sign in to the Azure portal as global administrator.
2. In the left pane, click Azure Active Directory.
3. On the Azure Active Directory page, in the Security section, click Conditional access.
4. On the Conditional Access page, in the Manage section, click Named locations.
5. On the Named locations page, click New location.
6. On the New page, do the following:

a. In the Name box, type a name for your named location.
b. In the IP ranges box, type an IP range. The IP range needs to be in the Classless Inter-Domain Routing
(CIDR) format.
c. Click Create.
What you should know

Bulk updates: When you create or update named locations, for bulk updates, you can upload or download a CSV
file with the IP ranges. An upload adds the IP ranges in the file to the list instead of overwriting the list.
Limitations: You can define a maximum of 60 named locations, with one IP range assigned to each of them. If you
have just one named location configured, you can define up to 500 IP ranges for it.
Next steps
To learn more about:
Risk events, see Azure Active Directory risk events.
Conditional access, see Conditional access in Azure Active Directory.
Risky sign-ins reports, see Risky sign-ins report in the Azure Active Directory portal.
Find activity reports in the Azure portal
In this article, we describe how to find Azure Active Directory user activity reports in the Azure portal.
What's new
Reports in the Azure classic portal were separated into categories:
Security reports
Activity reports
Integrated app reports
Activity and integrated app reports
For context-based reporting in the Azure portal, existing reports are merged into a single view. A single, underlying
API provides the data to the view.
To see this view, on the Azure Active Directory blade, under ACTIVITY, select Audit logs.
The following reports are consolidated in this view:

Audit report
Password reset activity
Password reset registration activity
Self-service groups activity
Office365 Group Name Changes
Account provisioning activity
Password rollover status
Account provisioning errors
The Application Usage report has been enhanced and is included in the Sign-ins view. To see this view, on the
Azure Active Directory blade, under ACTIVITY, select Sign-ins.
The Sign-ins view includes all user sign-ins. You can use this information to get application usage information. You
also can view application usage information in the Enterprise applications overview, in the MANAGE section.
Access a specific report
Although the Azure portal offers a single view, you also can look at specific reports.
Audit logs
In response to customer feedback, in the Azure portal, you can use advanced filtering to access the data you want.
One filter you can use is an activity category, which lists the different types of activity logs in Azure AD. To narrow
results to what you are looking for, you can select a category.
For example, if you are interested only in activities related to self-service password resets, you can choose the Self-
service Password Management category. The categories you see are based on the resource you are working in.
Activity categories include:

Core Directory
Self-service Password Management
Self-service Group Management
Account Provisioning
Application usage
To view details about application usage for all apps or for a single app, under ACTIVITY, select Sign-ins. To narrow
the results, you can filter on user name or application name.
Security reports
Azure AD anomalous activity reports
Azure AD anomalous activity security reports from the Azure classic portal have been consolidated to provide you
with one, central view. This view shows all security-related risk events that Azure AD can detect and report on.
The following table lists the Azure AD anomalous activity security reports, and corresponding risk event types in the
Azure portal.
AZURE AD ANOMALOUS ACTIVITY REPORT IDENTITY PROTECTION RISK EVENT TYPE
Users with leaked credentials Leaked credentials
Irregular sign-in activity Impossible travel to atypical locations
Sign-ins from possibly infected devices Sign-ins from infected devices
Sign-ins from unknown sources Sign-ins from anonymous IP addresses
Sign-ins from IP addresses with suspicious activity Sign-ins from IP addresses with suspicious activity
- Sign-ins from unfamiliar locations
The following Azure AD anomalous activity security reports are not included as risk events in the Azure portal:
Sign-ins after multiple failures
Sign-ins from multiple geographies
These reports are still available in the Azure classic portal, but they will be deprecated at some time in the future.
For more information, see Azure Active Directory risk events.
Detected risk events
In the Azure portal, you can access reports about detected risk events on the Azure Active Directory blade, under
SECURITY. Detected risk events are tracked in the following reports:
Users at Risk
Risky Sign-ins
For more information about security reports, see:

Users at Risk security report in the Azure Active Directory portal
Risky Sign-ins report in the Azure Active Directory portal
Activity reports in the Azure classic portal vs. the Azure portal
The table in this section lists existing reports in the Azure classic portal. It also describes how you can get the same
information in the Azure portal.
To view all auditing data, on the Azure Active Directory blade, under ACTIVITY, go to Audit logs.
AZURE CLASSIC PORTAL TO FIND IN THE AZURE PORTAL
Audit logs For Activity Category, select Core Directory.
Password reset activity For Activity Category, select Self-service Password

Management.
Password reset registration activity For Activity Category, select Self-service Password
Management.
Self-service groups activity For Activity Category, select Self-service Group

Management.
Account provisioning activity For Activity Category, select Account User Provisioning.
Password rollover status For Activity Category, select Automatic App Password
Rollover.
Account provisioning errors For Activity Category, select Account User Provisioning.
Office365 Group Name Changes For Activity Category, select Self-service Password
Management. For Activity Resource Type, select Group.
For Activity Source, select O365 groups.
To view the Application Usage report, on the Azure Active Directory blade, under MANAGE, select Enterprise
Applications, and then select Sign-ins.
Next steps
How to use the Azure Active Directory Power BI
Content Pack
Understanding how your users adopt and use Azure Active Directory features is critical for you as an IT admin. It
allows you to plan your IT infrastructure and communication to increase usage and to get the most out of AAD
features. Power BI Content Pack for Azure Active Directory gives you the ability to further analyze your data to
understand how you can use this data to gather richer insights into what’s going on with their Azure Active
Directory for the various capabilities you heavily rely on. With the integration of Azure Active Directory APIs into
Power BI, you can easily download the pre-built content packs and gain insights to all the activities within your
Azure Active Directory using rich visualization experience Power BI offers. You can create your own dashboard and
share it easily with anyone in your organization.
This topic provides you with step-by-step instructions on how to install and use the content pack in your
environment.
Installation
To install the Power BI Content Pack:
1. Log into Power BI with your Power BI Account (this is the same account as your O365 or Azure AD Account).
2. At the bottom of the left navigation pane, select Get Data.
3. In the Services box, click Get.
4. Search for Azure Active Directory.

5. When prompted, type your Azure AD Tenant ID, and then click Next.
TIP
A quick way to get the Tenant ID for your Office 365 / Azure AD tenant is to sign in to the Azure AD portal, drill down
to the directory, and copy the Directory ID from the Properties page.
6. Click Sign-in.
7. Enter your username and password, and then click Sign in.
8. On the app consent dialog, click Accept.

9. When your Azure Active Directory Activity logs dashboard has been created, click it.
What can I do with this content pack?
Before we jump into what you can do with this content pack, here’s quick preview of the various reports in the
content pack. Report data goes back to the last 30 days.
Reports included in this version of Azure Active Directory logs Content Pack
App Usage and Trend report: Get insights into the apps used in your organization and which ones are being used
the most and when. You can use this report to gather insights into how an app you recently rolled out in your
organization is being used or find out which apps are popular. By doing this, you can improve usage if you see if
the app is not being used.
Sign-ins by location and users: Get insights into all the sign-ins performed using Azure Identity and gives
insights into the identity of the users. With this, you can dig deeper into individual sign-ins and answer questions
like:
From where did this user sign-ins?
Which user has the most sign-ins and where do they sign-in from?
Was the sign-in successful?
You can drill into details by clicking on a specific date or location.
Unique users per app: Get a view of all unique users using a given app. This includes only users who have
“successfully” signed into an application.
Device sign-ins: Get a view of the type of OS and browsers are being used by users in your organization with
detailed information on the users including:
User Name
IP Address
Location
Sign-in status
With this report, you can understand the various device profiles used within your organization and determine
device policies based on what’s used
SSPR Funnel: Get an understanding on how password resets are being done in your organization. Get a peek into
how many password resets were attempted through the SSPR tool and how many of them were successful. Dig
deeper into the Password resets failure using the SSPR funnel and understand why certain failures occurred. This
report gives a deeper understanding of how the SSPR tool is used within your organization so you can make the
right decisions.
Customizing Azure AD Activity content pack

Change Visualization: You can change a report visualization by clicking Edit Report and select the visualization
you want.
Include additional fields: You can add a field to the report or remove it by selecting the visual to which you want
to add/remove the field. In the example below, I am adding “sign-in status” field to the table view.
Pin visualizations to your dashboard: You can customize your dashboard and include your own visualizations to
the report and pin it to the dashboard. In the example below, I added a new filter called “Sign-in Status” and
included it in the report. I also changed the visualization from bar chart to a line chart and can pin this new visual to
the dashboard.
Sharing your dashboard: Once you have created the content you want, you can share the dashboard with the
users in your organization. Please remember that once you share the report, they can see the fields you have
selected in the report.
Scheduling a daily refresh of your Power BI report

To schedule a daily refresh of your Power BI report, go to Datasets > Settings > Schedule Refresh and set it as
shown below.
Updating to newer version of content pack
If you want to update your content pack to get a newer version:
Download the new content pack and set it up as per instructions listed in this article.
Once you have set it up, go to Data Source > Settings > Data source credentials and re-enter your
credentials as shown below
As soon as the new version of the content pack is working, you can remove the old version if needed by deleting
the underlying reports and datasets associated with that content pack.
Still having issues?

Check out our troubleshooting guide. For general help with Power BI, check out these help articles.
Next steps
Azure Active Directory report retention policies
This topic provides you with answers to the most common questions in conjunction with the data retention for the
different activity reports in Azure Active Directory.
Q: How can you get the collection of activity data started?
A:
AZURE AD EDITION COLLECTION START
Azure AD Premium P1 When you sign-up for a subscription

Azure AD Premium P2
Azure AD Free The first time you open the Azure Active Directory blade or
use the reporting APIs
Q: When is your activity data available in the Azure portal?

A:
Immediately - If you have already been working with reports in the Azure portal
Within 2 hours - If you haven’t turned reporting on in the Azure portal
Q: How can you get the collection of security signals started?

A: For security signals, the collection process starts when you opt-in to use the Identity Protection Center.
Q: For how long is the collected data stored?

A:
Activity reports
REPORT AZURE AD FREE AZURE AD PREMIUM P1 AZURE AD PREMIUM P2
Directory Audit 7 days 30 days 30 days
Sign-in Activity N/A 30 days 30 days
Azure MFA Usage 30 days 30 days 30 days
Security Signals
REPORT AZURE AD FREE AZURE AD PREMIUM P1 AZURE AD PREMIUM P2
Users at risk 7 days 30 days 90 days
Risky sign-ins 7 days 30 days 90 days

Azure Active Directory reporting latencies
With reporting in the Azure Active Directory, you get all the information you need to determine how your
environment is doing. The amount of time it takes for reporting data to show up in the Azure portal is also known
as latency.
This topic lists the latency information for the all reporting categories in the Azure portal.
Activity reports
There are two areas of activity reporting:
Audit logs - System activity information about users and group management, your managed applications and
directory activities
The following table lists the latency information for activity reports.
REPORT MINIMUM AVERAGE REMARKS
Audit logs 30 minutes 1 hour In some instances, it can

take up to 2 hours for audit
activity data to show up.
Sign-ins 15 minutes 2 hours In some instances, it can

take up to 24 hours for sign-
in activity data to show up.
This includes sign-ins activity
data coming from legacy
office applications.
Security reports
There are two areas of security reporting:
someone who is not the legitimate owner of a user account.
The following table lists the latency information for security reports.
REPORT MINIMUM AVERAGE MAXIMUM
Users at risk 5 minutes 15 minutes 2 hours
Risky sign-ins 5 minutes 15 minutes 2 hours
Risk events
Azure Active Directory uses adaptive machine learning algorithms and heuristics to detect suspicious actions that
are related to your user accounts. Each detected suspicious action is stored in a record called risk event.
The following table lists the latency information for risk events.
REPORT MINIMUM AVERAGE MAXIMUM
Sign-ins from anonymous IP 5 minutes 15 Minutes 2 hours

addresses
Sign-ins from unfamiliar 5 minutes 15 Minutes 2 hours

locations
Users with leaked credentials 2 hours 4 hours 8 hours
Impossible travel to atypical 5 minutes 1 hour 8 hours

locations
Sign-ins from infected 2 hours 4 hours 8 hours

devices
Sign-ins from IP addresses 2 hours 4 hours 8 hours

with suspicious activity
Next steps
If you want to know more about the activity reports in the Azure portal, see:
Sign-in activity reports in the Azure Active Directory portal
Audit activity reports in the Azure Active Directory portal
If you want to know more about the security reports in the Azure portal, see:
Users at risk security report in the Azure Active Directory portal
Risky sign-ins report in the Azure Active Directory portal
If you want to know more about risk events, see Azure Active Directory risk events.
Azure Active Directory Reporting Notifications
What reports generate email notifications

At this time, only the Irregular Sign in Activity report triggers email notifications.
What is an "Irregular Sign in"?

Irregular sign-ins are those that have been identified by our machine learning algorithms, on the basis of an
"impossible travel" condition combined with an anomalous sign-in location and device. This may indicate that a
hacker has been trying to sign in using this account.
Who receives the email notifications?

The email is sent to all global admins who have been assigned an Active Directory Premium license. To ensure it is
delivered, we send it to the admins Alternate Email Address as well. Admins should include aad-alerts-
noreply@mail.windowsazure.com in their safe senders list so they don’t miss the email.
How often are these emails sent?

The email is sent if 10 new irregular sign-in activities occur in the last 30 days, or since the last email was sent,
whichever is less.
How do I access the report mentioned in the email?

When you click on the link, you will be redirected to the report page within the Azure portal. In order to access the
report, you need to be both:
An admin or co-admin of your Azure subscription
A global administrator in the directory, and assigned an Active Directory Premium license. For more information,
see Azure Active Directory editions.
Can I turn off these emails?

Yes, to turn off notifications related to anomalous sign-ins within the Azure portal, click Configure, and then select
Disabled under the Notifications section.
What's next
Curious about what security, audit, and activity reports are available? Check out Azure AD Security, Audit, and
Activity Reports
Getting started with Azure Active Directory Premium
Add company branding to your Sign In and Access Panel pages
Sign-in activity report error codes in the Azure Active
Directory portal
With the information provided by the user sign-ins report, you find answers to questions such as:
Who has signed-in using Azure Active Directory?
Which apps were signed into?
Which sign-ins were failures and if so why?
This topic lists the error codes and the related descriptions.
How can I display failed sign-ins?

Your first entry point to all sign-in activities data is Sign-ins in the Activity section of Azure Active.
In your sign-ins report, you can display all failed sign-ins by selecting Failure as Sign-in status.
Clicking an item in the displayed list, opens the Activity Details: Sign-ins blade. This view provides you with all
the details that Azure Active Directory tracks about sign-ins, including the sign-in error code and a failure
reason.
As an alternative to using the Azure portal to access the sign-ins data, you can also use the reporting API.
The following section provides you with a complete overview of all possible errors and the related descriptions.
Error codes
ERROR DESCRIPTION
50001 The service principal named X was not found in the tenant
named Y. This can happen if the application has not been
installed by the administrator of the tenant. Or Resource
principal was not found in the directory or is invalid.
50008 SAML assertion are missing or misconfigured in the token.
50011 The reply address is missing, misconfigured or does not match

reply addresses configured for the application.
50012 User reported fraud during Multi-Factor authentication.
50053 Account is locked because user tried to sign in too many times
with an incorrect user ID or password.
50054 Old password is used for authentication.
50055 Invalid password, entered expired password.
50057 User account is disabled.

ERROR DESCRIPTION
50058 No information about user's identity is found among provided

credentials or User was not found in tenant or A silent sign-in
request was sent but no user is signed in or Service was
unable to authenticate the user.
50074 User did not pass the MFA challenge.
50079 User needs to enroll for second factor authentication.
50126 Invalid username or password or Invalid on-premise username

or password.
50131 Used in various conditional access errors. E.g Bad Windows

device state, request blocked due to suspicious activity, access
policy and security policy decisions.
50133 Session is invalid due to expiration or recent password change.
50144 User's Active Directory password has expired.
65001 Application X doesn't have permission to access application Y

or the permission has been revoked. Or The user or
administrator has not consented to use the application with ID
X. Send an interactive authorization request for this user and
resource. Or The user or administrator has not consented to
use the application with ID X. Send an authorization request to
your tenant admin to act on behalf of the App : Y for Resource
: Z.
65005 The application required resource access list does not contain
applications discoverable by the resource or The client
application has requested access to resource which was not
specified in its required resource access list or Graph service
returned bad request or resource not found.
70001 The application named X was not found in the tenant named
Y. This can happen if the application has not been installed by
the administrator of the tenant or consented to by any user in
the tenant. You might have sent your authentication request
to the wrong tenant.
80001 Authentication Agent unable to connect to Active Directory.
80002 Authentication Agent's password validation request timed out.
80003 Invalid response received by Authentication Agent.
80004 Incorrect User Principal Name (UPN) used in sign-in request.
80005 Authentication Agent: Error occurred.
80007 Authentication Agent unable to validate user's password.
80010 Authentication Agent unable to decrypt password.

ERROR DESCRIPTION
80011 Authentication Agent unable to retrieve decryption key.
81001 User's Kerberos ticket is too large.
81002 Unable to validate user's Kerberos ticket.
81004 Kerberos authentication attempt failed.
81010 Seamless SSO failed because the user's Kerberos ticket has
expired or is invalid.
81011 Unable to find user object based on information in the user's

Kerberos ticket.
81012 The user trying to sign in to Azure AD is different from the

user signed into the device.
81013 Unable to find user object based on information in the user's

Kerberos ticket.
90014 Used in various cases when an expected field is not present in

the credential.
90093 Graph returned with forbidden error code for the request.
Next steps
For more details, see the Sign-in activity reports in the Azure Active Directory portal.
Reference for multi-factor authentication reporting in
the Azure portal
With Azure Active Directory (Azure AD) reporting in the Azure portal, you can get the information you need to
determine how your environment is doing.
The sign-in activity reports provide you with information about the usage of managed applications and user sign-in
activities, which includes information about the multi-factor authentication (MFA) usage.
The MFA data gives you insights into how MFA is working in your organization. It enables you to answer questions
like:
Was the sign-in challenged with MFA?
How did the user complete MFA?
Why was the user unable to complete MFA?
By aggregating the all sign-in data, you can have a better understanding of the MFA experience within your
organization. The data helps you to answer questions like:
How many users are challenged for MFA?
How many users are unable to complete the MFA challenge?
What are the common MFA issues end users are running into?
This data is available through the Azure portal and the reporting API.
Data structure
The sign-in activity reports for MFA give you access to the following information:
MFA required: Whether MFA is required for the sign-in or not. MFA can be required due to per-user MFA,
conditional access or other reasons. Possible values are Yes or No .
MFA authentication method: The authentication method the user used to complete MFA. Possible values are:
Text message
Mobile app notification
Phone call (Authentication phone)
Mobile app verification code
Phone call (Office phone)
Phone call (Alternate authentication phone)
MFA authentication detail: Scrubbed version of the phone number, for example: +X XXXXXXXX64.
MFA Result: More information on whether MFA was satisfied or denied:
If MFA was satisfied, this column provides more information about how MFA was satisfied.
If MFA was denied, this column would provide the reason for denial. Possible values are Satisfied or
Denied .
The following section lists possible string values for the MFA result field.
Status strings
This section lists the possible values for MFA result status string.
Satisfied status strings
Azure Multi-Factor Authentication
completed in the cloud
has expired due to the policies configured on tenant
registration prompted
satisfied by claim in the token
satisfied by claim provided by external provider
satisfied by strong authentication
skipped as flow exercised was Windows broker logon flow
skipped as flow exercised was Windows broker logon flow
skipped due to app password
skipped due to location
skipped due to registered device
skipped due to remembered device
successfully completed
Redirected to external provider for multi-factor authentication
Denied status strings
Azure Multi-Factor Authentication denied;
authentication in-progress
duplicate authentication attempt
entered incorrect code too many times
invalid authentication
invalid mobile app verification code
misconfiguration
phone call went to voicemail
phone number has an invalid format
service error
unable to reach the user’s phone
unable to send the mobile app notification to the device
unable to send the mobile app notification
user declined the authentication
user did not respond to mobile app notification
user does not have any verification methods registered
user entered incorrect code
user entered incorrect PIN
user hung up the phone call without succeeding the authentication
user is blocked
user never entered the verification code
user not found
verification code already used once
Next steps
For more information, see Azure Active Directory reporting.
I can’t find some actions that I performed in the
Azure Active Directory activity log
Symptoms
I performed some actions in the Azure portal and expected to see the audit logs for those actions in the
Activity logs > Audit Logs blade, but I can’t find them.
Cause
Actions don’t appear immediately in the Activity Audit log. It can take anywhere from 15 minutes to an hour to see
the audit logs in the portal from the time the operation is performed.
Resolution
Wait for 15 minutes to an hour and see if the actions appear in the log. If you still don’t see them, please raise a
support ticket with us and we will look into it.
Next steps
See the Azure Active Directory reporting FAQ.
I can’t find any data in the Azure Active Directory
activity logs I have downloaded
Symptoms
I downloaded the activity logs (audit or sign-ins) and I don’t see all the records for the time I chose. Why?
Cause
When you download activity logs in the Azure portal, we limit the scale to 120K records, sorted by most recent.
Resolution
You can leverage Azure AD Reporting APIs to fetch up to a million records at any given point. Our recommended
approach is to run a script on a scheduled basis that calls the reporting APIs to fetch records in an incremental
fashion over a period of time (e.g., daily or weekly).
Next steps
See the Azure Active Directory reporting FAQ.
Troubleshooting Azure Active Directory Activity logs
content pack errors
When working with the Power BI Content Pack for Azure Active Directory Preview, it is possible that you run into
the following errors:
Refresh failed
Failed to update data source credentials
Importing of data is taking too long
This topic provides you with information about the possible causes and how to fix these errors.
Refresh failed
How this error is surfaced: Email from Power BI or failed status in the refresh history.
CAUSE HOW TO FIX
Refresh failure errors can be caused when the credentials of In Power BI, locate the dataset corresponding to the Azure
the users connecting to the content pack have been reset but Active Directory Activity logs dashboard (Azure Active
not updated in the connection settings of the of the content Directory Activity logs), choose schedule refresh, and then
pack. enter your Azure AD credentials.
A refresh can fail due to data issues in the underlying content File a support ticket. For more details, see How to get support
pack. for Azure Active Directory.
Failed to update data source credentials

How this error is surfaced: In Power BI, when you are connecting to the Azure Active Directory Activity logs
(preview) content pack.
CAUSE HOW TO FIX
The connecting user is neither a global admin nor a security Use an account that is either a global admin or a security
reader or a security admin. reader or a security admin to access the content packs.
Your tenant is not a Premium tenant or doesn't have at least File a support ticket. For more details, see How to get support
one user with Premium license File. for Azure Active Directory.
Importing of data is taking too long

How this error is surfaced: In Power BI, once you have connected your content pack, the data import process
starts to prepare your dashboard for Azure Active Directory Activity log. You see the message: “Importing data...”
CAUSE HOW TO FIX

CAUSE HOW TO FIX
Depending on the size of your tenant, this step could take Just be patient. If the message does not change to showing
anywhere from a few mins to 30 minutes. your dashboard within an hour, please file a support ticket. For
more details, see How to get support for Azure Active
Directory.
Next steps
To install the Power BI Content Pack for Azure Active Directory Preview, click here.
Getting started with the Azure Active Directory
reporting API
Azure Active Directory provides you with a variety of reports. The data of these reports can be very useful to your
applications, such as SIEM systems, audit, and business intelligence tools. The Azure AD reporting APIs provide
programmatic access to the data through a set of REST-based APIs. You can call these APIs from a variety of
programming languages and tools.
This article provides you with the information you need to get started with the Azure AD reporting APIs. In the next
section, you find more details about using the audit and sign-in APIs.
For frequently asked questions,read our FAQ. For issues, please file a support ticket
Learning map
1. Prepare - Before you can test your API samples, you need to complete the prerequisites to access the Azure AD
reporting API.
2. Explore - Get a first impression of the reporting APIs:
Using the samples for the audit API
Using the samples for the sign-in activity report API
3. Customize - Create your own solution:
Using the audit API reference
Using the sign-in activity report API reference
Next Steps
If you are curious to see all available Azure AD Graph API endpoints, use this link:
https://graph.windows.net/tenant-name/activities/$metadata?api-version=beta.
Azure Active Directory audit API reference
This topic is part of a collection of topics about the Azure Active Directory reporting API.
Azure AD reporting provides you with an API that enables you to access audit data using code or related tools. The
scope of this topic is to provide you with reference information about the audit API.
See:
Audit logs for more conceptual information
Getting started with the Azure Active Directory Reporting API for more information about the reporting API.
For:
Frequently asked questions, read our FAQ
Issues, please file a support ticket

Global Admins
Any app that has authorization to access the API (app authorization can be setup only based on Global Admin’s
permission)
Prerequisites
In order to access this report through the Reporting API, you must have:
An Azure Active Directory Free or better edition
Completed the prerequisites to access the Azure AD reporting API.
Accessing the API

You can either access this API through the Graph Explorer or programmatically using, for example, PowerShell. In
order for PowerShell to correctly interpret the OData filter syntax used in AAD Graph REST calls, you must use the
backtick (aka: grave accent) character to “escape” the $ character. The backtick character serves as PowerShell’s
escape character, allowing PowerShell to do a literal interpretation of the $ character, and avoid confusing it as a
PowerShell variable name (ie: $filter).
The focus of this topic is on the Graph Explorer. For a PowerShell example, see this PowerShell script.
API Endpoint
You can access this API using the following URI:
https://graph.windows.net/contoso.com/activities/audit?api-version=beta
There is no limit on the number of records returned by the Azure AD audit API (using OData pagination). For
retention limits on reporting data, check out Reporting Retention Policies.
This call returns the data in batches. Each batch has a maximum of 1000 records.
To get the next batch of records, use the Next link. Get the skiptoken information from the first set of returned
records. The skip token will be at the end of the result set.
https://graph.windows.net/contoso.com/activities/audit?api-version=beta&%24skiptoken=-1339686058
Supported filters
You can narrow down the number of records that are returned by an API call in form of a filter.
For sign-in API related data, the following filters are supported:
$top=<number of records to be returned> - to limit the number of returned records. This is an expensive
operation. You should not use this filter if you want to return thousands of objects.
$filter=<your filter statement> - to specify, on the basis of supported filter fields, the type of records you
care about
Supported filter fields and operators

To specify the type of records you care about, you can build a filter statement that can contain either one or a
combination of the following filter fields:
activityDate - defines a date or date range
category - defines the category you want to filter on.
activityStatus - defines the status of an activity
activityType - defines the type of an activity
activity - defines the activity as string
actor/name - defines the actor in form of the actor's name
actor/objectid - defines the actor in form of the actor's ID
actor/upn - defines the actor in form of the actor's user principle name (UPN)
target/name - defines the target in form of the actor's name
target/objectid - defines the target in form of the target's ID
target/upn - defines the actor in form of the actor's user principle name (UPN)
activityDate
Supported operators: eq, ge, le, gt, lt
Example:
$filter=tdomain + 'activities/audit?api-version=beta&`$filter=activityDate gt ' + $7daysago
Notes:
datetime should be in UTC format
category
Supported values:
CATEGORY VALUE
Core Directory Directory

CATEGORY VALUE
Self-service Password Management SSPR
Self-service Group Management SSGM
Account Provisioning Sync
Automated Password Rollover Automated Password Rollover
Identity Protection IdentityProtection
Invited Users Invited Users
MIM Service MIM Service
Supported operators: eq
Example:
$filter=category eq 'SSPR'
activityStatus
Supported values:
ACTIVITY STATUS VALUE
Success 0
Failure -1
Example:
$filter=activityStatus eq -1
activityType
Example:
$filter=activityType eq 'User'
Notes:
case-sensitive
activity
Supported operators: eq, contains, startsWith
Example:
$filter=activity eq 'Add application' or contains(activity, 'Application') or startsWith(activity, 'Add')
Notes:
case-sensitive
actor/name
Example:
$filter=actor/name eq 'test' or contains(actor/name, 'test') or startswith(actor/name, 'test')
Notes:
case-insensitive
actor/objectId
Example:
$filter=actor/objectId eq 'e8096343-86a2-4384-b43a-ebfdb17600ba'
target/name
Example:
$filter=targets/any(t: t/name eq 'some name')
Notes:
Case-insensitive
target/upn
Supported operators: eq, startsWith
Example:
$filter=targets/any(t:
startswith(t/Microsoft.ActiveDirectory.DataService.PublicApi.Model.Reporting.AuditLog.TargetResourceUserEntity/
userPrincipalName,'abc'))
Notes:
Case-insensitive
You need to add the full namespace when querying
Microsoft.ActiveDirectory.DataService.PublicApi.Model.Reporting.AuditLog.TargetResourceUserEntity
target/objectId
Example:
$filter=targets/any(t: t/objectId eq 'e8096343-86a2-4384-b43a-ebfdb17600ba')
actor/upn
Supported operators: eq, startsWith
Example:
$filter=startswith(actor/Microsoft.ActiveDirectory.DataService.PublicApi.Model.Reporting.AuditLog.ActorUserEnti
ty/userPrincipalName,'abc')
Notes:
Case-insensitive
You need to add the full namespace when querying
Microsoft.ActiveDirectory.DataService.PublicApi.Model.Reporting.AuditLog.ActorUserEntity
Next Steps
Do you want to see examples for filtered system activities? Check out the Azure Active Directory audit API
samples.
Do you want to know more about the Azure AD reporting API? See Getting started with the Azure Active
Directory Reporting API.
Azure Active Directory sign-in activity report API
reference
Azure AD reporting provides you with an API that enables you to access sign-in activity report data using code or
related tools. The scope of this topic is to provide you with reference information about the sign-in activity report
API.
See:
Sign-in activities for more conceptual information
Who can access the API data?

Users and Service Principals in the Security Admin or Security Reader role
Global Admins
Any app that has authorization to access the API (app authorization can be setup only based on Global Admin’s
permission)
To configure access for an application to access security APIs such as signin events, use the following PowerShell to
add the applications Service Principal into the Security Reader role
Connect-MsolService
$servicePrincipal = Get-MsolServicePrincipal -AppPrincipalId "<app client id>"
$role = Get-MsolRole | ? Name -eq "Security Reader"
Add-MsolRoleMember -RoleObjectId $role.ObjectId -RoleMemberType ServicePrincipal -RoleMemberObjectId
$servicePrincipal.ObjectId
Prerequisites
To access this report through the reporting API, you must have:
An Azure Active Directory Premium P1 or P2 edition
Completed the prerequisites to access the Azure AD reporting API.
Accessing the API

You can either access this API through the Graph Explorer or programmatically using, for example, PowerShell. In
order for PowerShell to correctly interpret the OData filter syntax used in AAD Graph REST calls, you must use the
backtick (aka: grave accent) character to “escape” the $ character. The backtick character serves as PowerShell’s
escape character, allowing PowerShell to do a literal interpretation of the $ character, and avoid confusing it as a
PowerShell variable name (ie: $filter).
The focus of this topic is on the Graph Explorer. For a PowerShell example, see this PowerShell script.
API Endpoint
You can access this API using the following base URI:
https://graph.windows.net/contoso.com/activities/signinEvents?api-version=beta
Due to the volume of data, this API has a limit of one million returned records.
This call returns the data in batches. Each batch has a maximum of 1000 records.
To get the next batch of records, use the Next link. Get the skiptoken information from the first set of returned
records. The skip token will be at the end of the result set.
https://graph.windows.net/$tenantdomain/activities/signinEvents?api-version=beta&%24skiptoken=-1339686058
Supported filters
You can narrow down the number of records that are returned by an API call in form of a filter.
For sign-in API related data, the following filters are supported:
$top=<number of records to be returned> - to limit the number of returned records. This is an expensive
operation. You should not use this filter if you want to return thousands of objects.
$filter=<your filter statement> - to specify, on the basis of supported filter fields, the type of records you
care about
Supported filter fields and operators

To specify the type of records you care about, you can build a filter statement that can contain either one or a
combination of the following filter fields:
signinDateTime - defines a date or date range
userId - defines a specific user based the user's ID.
userPrincipalName - defines a specific user based the user's user principal name (UPN)
appId - defines a specific app based the app's ID
appDisplayName - defines a specific app based the app's display name
loginStatus - defines the status of the logins (success / failure)
NOTE
When using Graph Explorer, you the need to use the correct case for each letter is your filter fields.
To narrow down the scope of the returned data, you can build combinations of the supported filters and filter fields.
For example, the following statement returns the top 10 records between July 1st 2016 and July 6th 2016:
https://graph.windows.net/contoso.com/activities/signinEvents?api-
version=beta&$top=10&$filter=signinDateTime+ge+2016-07-01T17:05:21Z+and+signinDateTime+le+2016-07-07T00:00:00Z
signinDateTime
Supported operators: eq, ge, le, gt, lt
Example:
Using a specific date
$filter=signinDateTime+eq+2016-04-25T23:59:00Z
Using a date range
$filter=signinDateTime+ge+2016-07-01T17:05:21Z+and+signinDateTime+le+2016-07-07T17:05:21Z
Notes:
The datetime parameter should be in the UTC format
userId
Example:
$filter=userId+eq+’00000000-0000-0000-0000-000000000000’
Notes:
The value of userId is a string value
userPrincipalName
Example:
$filter=userPrincipalName+eq+'audrey.oliver@wingtiptoysonline.com'
Notes:
The value of userPrincipalName is a string value
appId
Example:
$filter=appId+eq+’00000000-0000-0000-0000-000000000000’
Notes:
The value of appId is a string value
appDisplayName
Example:
$filter=appDisplayName+eq+'Azure+Portal'
Notes:
The value of appDisplayName is a string value
loginStatus
Example:
$filter=loginStatus+eq+'1'
Notes:
There are two options for the loginStatus: 0 - success, 1 - failure
Next steps
Do you want to see examples for filtered sign-in activities? Check out the Azure Active Directory sign-in activity
report API samples.
Do you want to know more about the Azure AD reporting API? See Getting started with the Azure Active
Directory Reporting API.
Prerequisites to access the Azure AD reporting API
The Azure AD reporting APIs provide you with programmatic access to the data through a set of REST-based APIs.
You can call these APIs from a variety of programming languages and tools.
The reporting API uses OAuth to authorize access to the web APIs.
To get access to the reporting data through the API, you need to have one of the following roles assigned:
Security Reader
Security Admin
Global Admin
To prepare your access to the reporting API, you must:
1. Register an application
2. Grant permissions
3. Gather configuration settings
For questions, issues or feedback, please file a support ticket.
Register an Azure Active Directory application

You need to register an app even if you are accessing the reporting API using a script. This gives you an
Application ID, which is required for an authorization call and it enables your code to receive tokens.
To configure your directory to access the Azure AD reporting API, you must sign in to the Azure portal with an
Azure administrator account that is also a member of the Global Administrator directory role in your Azure AD
tenant.
IMPORTANT
Applications running under credentials with "admin" privileges like this can be very powerful, so please be sure to keep the
application's ID/secret credentials secure.
To register an Azure Active Directory application:

1. In the Azure portal, on the left navigation pane, click Azure Active Directory.
2. On the Azure Active Directory blade, click App registrations.
3. On the App registrations blade, in the toolbar on the top, click New application registration.
4. On the Create blade, perform the following steps:

a. In the Name textbox, type Reporting API application .
b. As Application type, select Web app / API.
c. In the Sign-on URL textbox, type https://localhost .
d. Click Create.
Grant permissions
The objective of this step is to grant your application Read directory data permissions to the Windows Azure
Active Directory API.
To grant your application permission to use the API:

1. On the App registrations blade, in the apps list, click Reporting API application.
2. On the Reporting API application blade, in the toolbar on the top, click Settings.
3. On the Settings blade, click Required permissions.
4. On the Required permissions blade, in the API list, click Windows Azure Active Directory.
5. On the Enable Access blade, select Read directory data.
6. In the toolbar on the top, click Save.
7. Click Grant Permissions, and then click Yes.
Gather configuration settings

This section shows you how to get the following settings from your directory:
Domain name
Client ID
Client secret
You need these values when configuring calls to the reporting API.
Get your domain name
To get your domain name:
2. On the Azure Active Directory blade, click Custom domain names.
3. Copy your domain name from the list of domains.

Get your application's client ID
To get your application's client ID:
3. On the Reporting API application blade, at the Application ID, click Click to copy.
Get your application's client secret

To get your application's client secret, you need to create a new key and save its value upon saving the new key
because it is not possible to retrieve this value later anymore.
To get your application's client secret:
3. On the Reporting API application blade, in the toolbar on the top, click Settings.
4. On the Settings blade, in the APIR Access section, click Keys.
5. On the Keys blade, perform the following steps:

a. In the Description textbox, type Reporting API .
b. As Expires, select In 2 years.
c. Click Save.
d. Copy the key value.
Next Steps
Would you like to access the data from the Azure AD reporting API in a programmatic manner? Check out
Getting started with the Azure Active Directory Reporting API.
If you would like to find out more about Azure Active Directory reporting, see the Azure Active Directory
Reporting Guide.
Azure Active Directory reporting audit API samples
Azure AD reporting provides you with an API that enables you to access audit data using code or related tools. The
scope of this topic is to provide you with sample code for the audit API.
See:
For questions, issues or feedback, please contact AAD Reporting Help.
Prerequisites
Before you can use the samples in this topic, you need to complete the prerequisites to access the Azure AD
reporting API.
Known issue
App Auth will not work if your tenant is in the EU region. Please use User Auth for accessing the Audit API as a
workaround until we fix the issue.
PowerShell script
# This script will require registration of a Web Application in Azure Active Directory (see
https://azure.microsoft.com/documentation/articles/active-directory-reporting-api-getting-started/)
# Constants
$ClientID = "your-client-application-id-here" # Insert your application's Client ID, a Globally
Unique ID (registered by Global Admin)
$ClientSecret = "your-client-application-secret-here" # Insert your application's Client Key/Secret string
$loginURL = "https://login.microsoftonline.com" # AAD Instance; for example
https://login.microsoftonline.com
$tenantdomain = "your-tenant-domain.onmicrosoft.com" # AAD Tenant; for example, contoso.onmicrosoft.com
$resource = "https://graph.windows.net" # Azure AD Graph API resource URI
$7daysago = "{0:s}" -f (get-date).AddDays(-7) + "Z" # Use 'AddMinutes(-5)' to decrement minutes, for
example
Write-Output "Searching for events starting $7daysago"
# Create HTTP header, get an OAuth2 access token based on client id, secret and tenant domain
$body =
@{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body
$body
# Parse audit report items, save output to file(s): auditX.json, where X = 0 thru n for number of nextLink
pages
if ($oauth.access_token -ne $null) {
$i=0
$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
$url = 'https://graph.windows.net/' + $tenantdomain + '/activities/audit?api-
version=beta&$filter=activityDate gt ' + $7daysago
# loop through each query page (1 through n)

Do{
# display each event on the console window
Write-Output "Fetching data using Uri: $url"
$myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {
Write-Output ($event | ConvertTo-Json)
}
# save the query page to an output file

Write-Output "Save the output to a file audit$i.json"
$myReport.Content | Out-File -FilePath audit$i.json -Force
$url = ($myReport.Content | ConvertFrom-Json).'@odata.nextLink'
$i = $i+1
} while($url -ne $null)
} else {
Write-Host "ERROR: No Access Token"
}
Write-Host "Press any key to continue ..."

$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
Executing the PowerShell script

Once you finish editing the script, run it and verify that the expected data from the Audit logs report is returned.
The script returns output from the audit report in JSON format. It also creates an audit.json file with the same
output. You can experiment by modifying the script to return data from other reports, and comment out the output
formats that you do not need.
Bash script
#!/bin/bash
# Author: Ken Hoff (kenhoff@microsoft.com)

# Date: 2015.08.20
# NOTE: This script requires jq (https://stedolan.github.io/jq/)
CLIENT_ID="your-application-client-id-here" # Should be a ~35 character string insert your info here

CLIENT_SECRET="your-application-client-secret-here" # Should be a ~44 character string insert your info here
LOGIN_URL="https://login.microsoftonline.com"
TENANT_DOMAIN="your-directory-name-here.onmicrosoft.com" # For example, contoso.onmicrosoft.com
TOKEN_INFO=$(curl -s --data-urlencode "grant_type=client_credentials" --data-urlencode "client_id=$CLIENT_ID"

--data-urlencode "client_secret=$CLIENT_SECRET" "$LOGIN_URL/$TENANT_DOMAIN/oauth2/token?api-version=1.0")
TOKEN_TYPE=$(echo $TOKEN_INFO | ./jq-win64.exe -r '.token_type')

ACCESS_TOKEN=$(echo $TOKEN_INFO | ./jq-win64.exe -r '.access_token')
# get yesterday's date
YESTERDAY=$(date --date='1 day ago' +'%Y-%m-%d')
URL="https://graph.windows.net/$TENANT_DOMAIN/activities/audit?api-
version=beta&$filter=activityDate%20gt%20$YESTERDAY"
REPORT=$(curl -s --header "Authorization: $TOKEN_TYPE $ACCESS_TOKEN" $URL)
echo $REPORT | ./jq-win64.exe -r '.value' | ./jq-win64.exe -r ".[]"
Python script
# Author: Michael McLaughlin (michmcla@microsoft.com)
# Date: January 20, 2016
# This requires the Python Requests module: http://docs.python-requests.org
import requests
import datetime
import sys
client_id = 'your-application-client-id-here'
client_secret = 'your-application-client-secret-here'
login_url = 'https://login.microsoftonline.com/'
tenant_domain = 'your-directory-name-here.onmicrosoft.com'
# Get an OAuth access token

bodyvals = {'client_id': client_id,
'client_secret': client_secret,
'grant_type': 'client_credentials'}
request_url = login_url + tenant_domain + '/oauth2/token?api-version=1.0'

token_response = requests.post(request_url, data=bodyvals)
access_token = token_response.json().get('access_token')
token_type = token_response.json().get('token_type')
if access_token is None or token_type is None:

print "ERROR: Couldn't get access token"
sys.exit(1)
# Use the access token to make the API request

yesterday = datetime.date.strftime(datetime.date.today() - datetime.timedelta(days=1), '%Y-%m-%d')
header_params = {'Authorization': token_type + ' ' + access_token}

request_string = 'https://graph.windows.net/' + tenant_domain + '/activities/audit?api-
version=beta&$filter=activityDate%20gt%20' + yesterday
response = requests.get(request_string, headers = header_params)
if response.status_code is 200:
print response.content
else:
print 'ERROR: API request failed'
Next steps
Would you like to customize the samples in this topic? Check out the Azure Active Directory audit API reference.
If you want to see a complete overview of using the Azure Active Directory reporting API, see Getting started
with the Azure Active Directory reporting API.
Reporting Guide.
Azure Active Directory sign-in activity report API
samples
Azure AD reporting provides you with an API that enables you to access sign-in activity data using code or related
tools.
The scope of this topic is to provide you with sample code for the sign-in activity API.
See:
Prerequisites
Before you can use the samples in this topic, you need to complete the prerequisites to access the Azure AD
reporting API.
PowerShell script
# This script will require the Web Application and permissions setup in Azure Active Directory
$ClientID = "<clientId>" # Should be a ~35 character string insert your info here
$ClientSecret = "<clientSecret>" # Should be a ~44 character string insert your info here
$loginURL = "https://login.microsoftonline.com/"
$tenantdomain = "<tenantDomain>"
$ daterange # For example, contoso.onmicrosoft.com
$7daysago = "{0:s}" -f (get-date).AddDays(-7) + "Z"

# or, AddMinutes(-5)
Write-Output $7daysago
# Get an Oauth 2 access token based on client id, secret and tenant domain
$body =

$body

$url = "https://graph.windows.net/$tenantdomain/activities/signinEvents?api-
version=beta&`$filter=signinDateTime ge $7daysago"
$i=0
Do{
Write-Output "Fetching data using Uri: $url"
Write-Output "Save the output to a file SigninActivities$i.json"
Write-Output "---------------------------------------------"
$myReport.Content | Out-File -FilePath SigninActivities$i.json -Force
$url = ($myReport.Content | ConvertFrom-Json).'@odata.nextLink'
$i = $i+1
} while($url -ne $null)
} else {

}
Executing the script

Once you finish editing the script, run it and verify that the expected data from the Audit logs report is returned.
The script returns output from the sign-in report in JSON format. It also creates an SigninActivities.json file with
the same output. You can experiment by modifying the script to return data from other reports, and comment out
the output formats that you do not need.
Next Steps
Would you like to customize the samples in this topic? Check out the Azure Active Directory sign-in activity API
reference.
If you want to see a complete overview of using the Azure Active Directory reporting API, see Getting started
with the Azure Active Directory reporting API.
Reporting Guide.
Get data using the Azure AD Reporting API with
certificates
This article discusses how to use the Azure AD Reporting API with certificate credentials to get data from directories
without user intervention.
Use the Azure AD Reporting API

Azure AD Reporting API requires that you complete the following steps:
Install prerequisites
Set the certificate in your app
Get an access token
Use the access token to call the Graph API
For information about source code, see Leverage Report API Module.
Install prerequisites
You will need to have Azure AD PowerShell V2 and AzureADUtils module installed.
1. Download and install Azure AD Powershell V2, following the instructions at Azure Active Directory PowerShell.
2. Download the Azure AD Utils module from AzureAD/azure-activedirectory-powershell. This module provides
several utility cmdlets including:
The latest version of ADAL using Nuget
Access tokens from user, application keys, and certificates using ADAL
Graph API handling paged results
To install the Azure AD Utils module:
1. Create a directory to save the utilities module (for example, c:\azureAD) and download the module from GitHub.
2. Open a PowerShell session, and go to the directory you just created.
3. Import the module, and install it in the PowerShell module path using the Install-AzureADUtilsModule cmdlet.
The session should look similar to this screen:
Set the certificate in your app

1. If you already have an app, get its Object ID from the Azure Portal.
2. Open a PowerShell session and connect to Azure AD using the Connect-AzureAD cmdlet.
3. Use the New-AzureADApplicationCertificateCredential cmdlet from AzureADUtils to add a certificate

credential to it.
NOTE
You need to provide the application Object ID that you captured earlier, as well as the certificate object (get this using the
Cert: drive).
Get an access token
To get an access token, use the Get-AzureADGraphAPIAccessTokenFromCert cmdlet from AzureADUtils.
NOTE
You need to use the Application ID instead of the Object ID that you used in the last section.
Use the access token to call the Graph API

Now you can create the script. Below is an example using the Invoke-AzureADGraphAPIQuery cmdlet from the
AzureADUtils. This cmdlet handles multi-paged results, and then sends those results to the PowerShell pipeline.
You are now ready to export to a CSV and save to a SIEM system. You can also wrap your script in a scheduled task
to get Azure AD data from your tenant periodically without having to store application keys in the source code.
Next steps
The fundamentals of Azure identity management
Azure AD self-service password reset for the IT
professional
With Azure Active Directory (Azure AD) self-service password reset (SSPR), users can reset their passwords on their
own when and where they need to. At the same time, administrators can control how a user's password gets reset.
Users no longer need to call a help desk just to reset their password. Azure AD SSPR includes:
Self-service password change: The user knows their password but wants to change it to something new.
Self-service password reset: The user is unable to sign in and wants to reset their password by using one or
more of the following validated authentication methods:
Send a text message to a validated mobile phone.
Make a phone call to a validated mobile or office phone.
Send an email to a validated secondary email account.
Answer their security questions.
Self-service account unlock: The user is unable to sign in with their password and has been locked out. The
user wants to unlock their account without administrator intervention by using their authentication methods.
Why choose Azure AD SSPR

Azure AD SSPR helps you to:
Reduce costs as help desk assisted password resets typically account for 20% of an IT organization’s support
calls.
Improve end-user experiences and reduce help desk volume by giving end users the power to resolve
their own password problems. There is no need to call a help desk or open a support request.
Drive mobility as users can reset their passwords from wherever they are.
Maintain control of the security policy. Administrators can continue to enforce the policies they have today.
If you're ready, you can get started with Azure AD SSPR by using our quick start guidance. You can quickly give
your users to ability to reset their own passwords.
Azure AD SSPR availability

Azure AD SSPR is available in three tiers depending on your subscription:
Azure AD Free: Cloud-only administrators can reset their own passwords.
Azure AD Basic or any paid Office 365 subscription: Cloud-only users can reset their own passwords.
Azure AD Premium: Any user or administrator, including cloud-only, federated, or password synchronized
users, can reset their own passwords. On-premises passwords require password writeback to be enabled.
Azure AD pricing, SLA, updates, and roadmap

More details about licensing, pricing, and future plans can be found on the following sites:
Azure AD pricing details
Office 365 pricing
Azure Service Level Agreements
Service Level Agreement for Microsoft Online Services
Azure updates
Azure roadmap
Next steps
Are you ready to get started with SSPR? Set up Azure AD self-service password reset.
Plan a successful SSPR deployment to your users by using the guidance found in our rollout guide.
Reset or change your password.
Register for self-service password reset.
Reset your work or school password
If you forgot your password, never received one from your company support, have been locked out of your
account, or want to change it, we can help. If you know your password and just need to change it, continue to
the Change my password section.
NOTE
If you're trying to get back in to your personal account like Xbox, hotmail.com, or outlook.com, try the suggestions in the
When you can't sign in to your Microsoft account article.
Reset or unlock my password for a work or school account

You might be unable to access your Azure Active Directory (Azure AD) account because of one of the following
reasons:
Your password is not working and you want to reset it.
You know your password, but your account is locked out and you want to unlock it.
Use the following steps to access Azure AD self-service password reset (SSPR) and get back in to your account.
1. From any work or school Sign-in page, select the Can't access your account? link, and then select
Work or school account or go directly to the Password reset page.
2. Enter your work or school User ID, prove you aren't a robot by entering the characters you see on the
screen, and then select Next.
NOTE
If your IT staff has not enabled this functionality, a "Contact your administrator" link appears so your IT staff can
help via email or a web portal of their own.
If you need to unlock your account, at this point select the option I know my password, but still can't sign in.
3. Depending on how your IT staff has configured SSPR you should see one or more of the following
authentication methods. Either you or your IT staff should have populated some of this information by
following the steps in the Register for self-service password reset article.
Email my alternate email
Text my mobile phone
Call my mobile phone
Call my office phone
Answer my security questions
Choose an option, provide the correct responses, and then select Next.
4. Your IT staff might need more verification, and you might have to repeat step 3 with a different choice.
5. On the Choose a new password page, enter a new password, confirm your password, and then select
Finish. Your work or school password might have certain requirements that you need to adhere to. We
suggest that choose a password that's 8 to 16 characters long and includes uppercase and lowercase
characters, a number, and a special character.
6. When you see the message Your password has been reset, you can sign in with your new password.
You should now be able to access your account. If you can't access your account, you should contact your
organization's IT staff for further help.
You might receive a confirmation email that comes from an account like "Microsoft on behalf of <your
organization>." If you get an email like this one and you did not use self-service password reset to regain access
to your account, contact your organization's IT staff.
Change my password
If you know your password already and want to change it, use the following steps.
Change your password from the Office 365 portal
Use this method if you normally access your applications through the Office portal:
1. Sign in to your Office 365 account with your existing password.
2. Select your profile on the upper-right side, and then select View account.
3. Select Security & privacy > Password.
4. Enter your old password, set and confirm your new password, and then select Submit.
Change your password from the Azure Access Panel
Use this method if you normally access your applications from the Azure Access Panel (MyApps):
1. Sign in to the Azure Access Panel with your existing password.
2. Select your profile on the upper-right side, and then select Profile.
3. Select Change password.
4. Enter your old password, set and confirm your new password, and then select Submit.
Reset password at sign-in

If your administrator has enabled the functionality, you can now see a link to Reset password at your Windows
10 Fall Creators Update sign-in screen.
Select the Reset password link to open up the SSPR experience at the sign-in screen so that you can reset your
password without having to sign in to access the normal web-based experience.
1. Confirm your user ID and select Next.
2. Select and confirm a contact method for verification. Your IT staff might need more verification, and you
might have to repeat this step with a different choice.
3. On the Create a new password page, enter a new password, confirm your password, and then select
Next. We suggest that your password is 8-16 characters long and consists of uppercase and lowercase
letters, numbers, and special characters.
4. When you see the message Your password has been reset, select Finish.
You should now be able to access your account. If not, contact your organization's IT staff for further help.
Common problems and their solutions

Here are some common error cases and their solutions:
ERROR CASE WHAT ERROR DO YOU SEE? SOLUTION
I see an error when I try to change my Unfortunately, your password contains Choose a password that is more
password. a word, phrase, or pattern that makes difficult to guess.
your password easily guessable. Please
try again with a different password.
I get a "Please contact your Please contact your administrator. You're seeing this message because
administrator" page after entering my your IT staff manages your password
user ID We've detected that your user account in your on-premises environment. You
password is not managed by can't reset your password from the
Microsoft. As a result, we are unable to "Can't access your account" link.
automatically reset your password.
To reset your password, contact your
You need to contact your IT staff for IT staff directly for help, and let them
further assistance. know you want to reset your
password so they can enable this
feature for you.
I get a "Your account is not enabled Your account is not enabled for You're seeing this message because
for password reset" error after password reset. your IT staff has not enabled password
entering my user ID reset for your organization from the
We're sorry, but your IT staff has not "Can't access your account" link, or
set up your account to use this service. hasn't licensed you to use the feature.
If you'd like, we can contact an To reset your password, select the

administrator in your organization to "contact an administrator link" to send
reset your password for you. an email to your company's IT staff,
and let them know you want to reset
your password so they can enable this
feature for you.
I get a "We could not verify your We could not verify your account. You're seeing this message because
account" error after entering my user you're enabled for password reset, but
ID If you'd like, we can contact an you have not registered to use the
administrator in your organization to service. To register for password reset,
reset your password for you. go to http://aka.ms/ssprsetup after
you have regained access to your
account.
To reset your password, select the

"contact an administrator" link to send
an email to your company's IT staff.
Next steps
How to register to use self-service password reset
Password reset registration page
Password reset portal
Can't sign in to your Microsoft account
A multi-tiered approach to Azure AD password
security
This article discusses some best practices you can follow as a user or as an administrator to protect your Azure
Active Directory (Azure AD) or Microsoft Account.
NOTE
Are you here because you're having problems signing in? If so, here's how you can change and reset your own
password.
Azure AD administrators can reset user passwords using the guidance in the article Reset the password for a user in Azure
Active Directory.
Password requirements
Azure AD incorporates the following common approaches to securing passwords:
Password length requirements
Password complexity requirements
Regular and periodic password expiration
For information about password reset in Azure Active Directory, see the topic Azure AD self-service password reset
for the IT professional.
Azure AD password protections

Azure AD and the Microsoft Account System use industry proven approaches to ensure secure protection of user
and administrator passwords including:
Dynamically banned passwords
Smart Password Lockout
For information about password management based on current research, see the whitepaper Password Guidance.
Dynamically banned passwords
Azure AD and Microsoft Accounts safeguard password protection by dynamically banning commonly used
passwords. The Azure AD Identity Protection team routinely analyzes banned password lists, preventing users from
selecting commonly used passwords. This service is available to Azure AD and the Microsoft Account Service
customers.
When creating passwords, it is important for administrators to encourage users to choose password phrases that
include a unique combination of letters, numbers, characters, or words. This approach helps to make user
passwords nearly impossible to be compromised but easier for users to remember.
Password breaches
Microsoft is always working to stay one step ahead of cyber-criminals.
The Azure AD Identity Protection team continually analyzes passwords that are commonly used. Cyber-criminals
also use similar strategies to inform their attacks, such as building a rainbow table for cracking password hashes.
Microsoft continually analyzes data breaches to maintain a dynamically updated banned password list, which
ensures that vulnerable passwords are banned before they become a real threat to Azure AD customers. For more
information about our current security efforts, see the Microsoft Security Intelligence Report.
Smart Password Lockout
When Azure AD detects a potential cyber-criminal trying to hack into a user password, we lock the user account
with Smart Password Lockout. Azure AD is designed to determine the risk associated with specific login sessions.
Then using the most up-to-date security data, we apply lockout semantics to stop cyber threats.
If a user is locked out of Azure AD, their screen looks similar to the one that follows:
For other Microsoft accounts, their screen looks similar to the one that follows:
For information about password reset in Azure Active Directory, see the topic Azure AD self-service password reset
for the IT professional.
NOTE
If you are an Azure AD administrator, you may want to use Windows Hello to avoid having your users create traditional
passwords altogether.
Next steps
How to update your own password
The fundamentals of Azure identity management
Report on password reset activity
IMPORTANT
Are you here because you can't sign in? If so, see Reset your work or school password.
As an end user, you can reset your password or unlock your account by yourself if you use Azure Active
Directory (Azure AD) self-service password reset (SSPR). Before you can use this functionality, you have to
register your authentication methods or confirm the predefined authentication methods that your administrator
has populated.
Register or confirm authentication data with SSPR

1. Open the web browser on your device and go to the password reset registration page.
2. Enter your username and the password that your administrator provided.
3. Depending on how your IT staff has configured things, one or more of the following options are available for
you to configure and verify. If your administrator has your permission to use your information, they can
populate some of the information for you.
Office phone: Only your administrator can set this option.
Authentication Phone: Set this option to another phone number that you have access to. An example
is a cell phone that can receive a text or a call.
Authentication Email: Set this option to an alternate email address that you can access without using
the password you want to reset.
Security Questions: Your administrator has approved this list of questions for you to answer. You
can't use the same question or answer more than once.
4. Provide and verify the information that your administrator requires. If more than one option is available,
we suggest that you register multiple methods. This gives you flexibility when one of the methods isn't
available. An example is when you're traveling and you're unable to access your office phone.
5. Select finish. You can now use SSPR when you need to in the future.
If you enter data for Authentication Phone or Authentication Email, it's not visible in the global directory.
The only people who can see this data are you and your administrators. Only you can see the answers to your
security questions.
Your administrators might require you to confirm your authentication methods after a period of time to make
sure you still have the appropriate methods registered.
Common problems and their solutions

Here are some common error cases and their solutions:
I get a "please contact your Please contact your administrator. You're seeing this message because
administrator" page after entering my your IT staff manages your password in
user ID We've detected that your user account your on-premises environment and
password is not managed by does not allow you to reset your
Microsoft. As a result, we are unable to password from the Can't access your
automatically reset your password. account link.
Contact your IT staff for any further To reset your password, contact your
assistance. IT staff directly for help. Let them know
you want to reset your password so
they can enable this feature for you.
I get a "your account is not enabled for Your account is not enabled for You're seeing this message because
password reset" error after entering password reset. your IT staff has not enabled password
my user ID reset for your organization from the
We're sorry, but your IT staff has not Can't access your account link or
set up your account for use with this hasn't licensed you to use the feature.
service.
If you'd like, we can contact an contact an administrator link. An
administrator in your organization to email will be sent to your company's IT
reset your password for you. staff. The email lets them know you
want to reset your password, so they
can enable this feature for you.
I get a "we could not verify your We could not verify your account. You're seeing this message because
account" error after entering my user you're enabled for password reset, but
ID If you'd like, we can contact an you haven't registered to use the
administrator in your organization to service. To register for password reset,
reset your password for you. go to the password reset registration
page after you have regained access to
your account.

contact an administrator link to send
an email to your company's IT staff.
Next steps
Change your password by using self-service password reset
Password reset registration page
Password reset portal
When you can't sign in to your Microsoft account
Self-service password reset in Azure AD deep dive
How does self-service password reset (SSPR) work? What does that option mean in the interface? Continue
reading to find out more about Azure Active Directory (Azure AD) SSPR.
How does the password reset portal work?

When a user goes to the password reset portal, a workflow is kicked off to determine:
How should the page be localized?
Is the user account valid?
What organization does the user belong to?
Where is the user’s password managed?
Is the user licensed to use the feature?
Read through the following steps to learn about the logic behind the password reset page:
1. The user selects the Can't access your account link or goes directly to https://aka.ms/sspr.
Based on the browser locale, the experience is rendered in the appropriate language. The password
reset experience is localized into the same languages that Office 365 supports.
2. The user enters a user ID and passes a captcha.
3. Azure AD verifies that the user is able to use this feature by doing the following checks:
Checks that the user has this feature enabled and has an Azure AD license assigned.
If the user does not have this feature enabled or have a license assigned, the user is asked to
contact their administrator to reset their password.
Checks that the user has the right challenge data defined on their account in accordance with
administrator policy.
If the policy requires only one challenge, then it ensures that the user has the appropriate data
defined for at least one of the challenges enabled by the administrator policy.
If the user challenge is not configured, then the user is advised to contact their
administrator to reset their password.
If the policy requires two challenges, then it ensures that the user has the appropriate data
defined for at least two of the challenges enabled by the administrator policy.
If the user challenge is not configured, then the user is advised to contact their
administrator to reset their password.
Checks to see if the user’s password is managed on-premises (federated or password hash
synchronized).
If writeback is deployed and the user’s password is managed on-premises, then the user is
allowed to proceed to authenticate and reset their password.
If writeback is not deployed and the user’s password is managed on-premises, then the user is
asked to contact their administrator to reset their password.
4. If it's determined that the user is able to successfully reset their password, then the user is guided through the
reset process.
Authentication methods
If SSPR is enabled, you must select at least one of the following options for the authentication methods.
Sometimes you hear these options referred to as "gates." We highly recommend that you choose at least two
authentication methods so that your users have more flexibility.
Email
Mobile phone
Office phone
Security questions
What fields are used in the directory for the authentication data?
Office phone: Corresponds to the office phone.
Users are unable to set this field themselves. It must be defined by an administrator.
Mobile phone: Corresponds to either the authentication phone (not publicly visible) or the mobile phone
(publicly visible).
The service looks for the authentication phone first, and then falls back to the mobile phone if the
authentication phone is not present.
Alternate email address: Corresponds to either the authentication email (not publicly visible) or the alternate
email.
The service looks for the authentication email first, and then fails back to the alternate email.
By default, only the cloud attributes office phone and mobile phone are synchronized to your cloud directory from
your on-premises directory for authentication data.
Users can only reset their password if they have data present in the authentication methods that the administrator
has enabled and requires.
If users don't want their mobile phone number to be visible in the directory, but they still want to use it for
password reset, administrators should not populate it in the directory. Users should then populate their
Authentication Phone attribute via the password reset registration portal. Administrators can see this
information in the user's profile, but it's not published elsewhere.
The number of authentication methods required
This option determines the minimum number of the available authentication methods or gates a user must go
through to reset or unlock their password. It can be set to either one or two.
Users can choose to supply more authentication methods if the administrator enables that authentication method.
If a user does not have the minimum required methods registered, they see an error page that directs them to
request that an administrator reset their password.
Change authentication methods
If you start with a policy that has only one required authentication method for reset or unlock registered and you
change that to two methods, what happens?
NUMBER OF METHODS REGISTERED NUMBER OF METHODS REQUIRED RESULT
1 or more 1 Able to reset or unlock
1 2 Unable to reset or unlock
2 or more 2 Able to reset or unlock
If you change the types of authentication methods that a user can use, you might inadvertently stop users from
being able to use SSPR if they don't have the minimum amount of data available.
Example:
1. The original policy is configured with two authentication methods required. It uses only the office phone
number and the security questions.
2. The administrator changes the policy to no longer use the security questions, but allows the use of a mobile
phone and an alternate email.
3. Users without the mobile phone and alternate email fields populated can't reset their passwords.
How secure are my security questions?
If you use security questions, we recommend using them in conjunction with another method. Security questions
can be less secure than other methods because some people might know the answers to another user's
questions.
NOTE
Security questions are stored privately and securely on a user object in the directory and can only be answered by users
during registration. There is no way for an administrator to read or modify a user's questions or answers.
Security question localization

All the predefined questions that follow are localized into the full set of Office 365 languages and are based on
the user's browser locale:
In what city did you meet your first spouse/partner?
In what city did your parents meet?
In what city does your nearest sibling live?
In what city was your father born?
In what city was your first job?
In what city was your mother born?
What city were you in on New Year's 2000?
What is the last name of your favorite teacher in high school?
What is the name of a college you applied to but didn't attend?
What is the name of the place in which you held your first wedding reception?
What is your father's middle name?
What is your favorite food?
What is your maternal grandmother's first and last name?
What is your mother's middle name?
What is your oldest sibling's birthday month and year? (e.g. November 1985)
What is your oldest sibling's middle name?
What is your paternal grandfather's first and last name?
What is your youngest sibling's middle name?
What school did you attend for sixth grade?
What was the first and last name of your childhood best friend?
What was the first and last name of your first significant other?
What was the last name of your favorite grade school teacher?
What was the make and model of your first car or motorcycle?
What was the name of the first school you attended?
What was the name of the hospital in which you were born?
What was the name of the street of your first childhood home?
What was the name of your childhood hero?
What was the name of your favorite stuffed animal?
What was the name of your first pet?
What was your childhood nickname?
What was your favorite sport in high school?
What was your first job?
What were the last four digits of your childhood telephone number?
When you were young, what did you want to be when you grew up?
Who is the most famous person you have ever met?
Custom security questions
Custom security questions are not localized for different locales. All custom questions are displayed in the same
language as they are entered in the administrative user interface, even if the user's browser locale is different. If
you need localized questions, you should use the predefined questions.
The maximum length of a custom security question is 200 characters.
Security question requirements
The minimum answer character limit is three characters.
The maximum answer character limit is 40 characters.
Users can't answer the same question more than one time.
Users can't provide the same answer to more than one question.
Any character set can be used to define the questions and the answers, including Unicode characters.
The number of questions defined must be greater than or equal to the number of questions that were required
to register.
Registration
Require users to register when they sign in
To enable this option, a user who is enabled for password reset has to complete the password reset registration if
they sign in to applications by using Azure AD. This includes the following:
Office 365
Azure portal
Access Panel
Federated applications
Custom applications by using Azure AD
When requiring registration is disabled, users can still manually register their contact information. They can either
visit http://aka.ms/ssprsetup or select the Register for password reset link under the Profile tab in the Access
Panel.
NOTE
Users can dismiss the password reset registration portal by selecting cancel or by closing the window. But they are
prompted to register each time they sign in until they complete their registration.
This doesn't break the user's connection if they are already signed in.
Set the number of days before users are asked to reconfirm their authentication information
This option determines the period of time between setting and reconfirming authentication information and is
available only if you enable the Require users to register when signing in option.
Valid values are 0 to 730 days, with "0" meaning users are never asked to reconfirm their authentication
information.
Notifications
Notify users on password resets
If this option is set to Yes, then the user who is resetting their password receives an email notifying them that
their password has been changed. The email is sent via the SSPR portal to their primary and alternate email
addresses that are on file in Azure AD. No one else is notified of this reset event.
Notify all admins when other admins reset their passwords
If this option is set to Yes, then all administrators receive an email to their primary email address on file in Azure
AD. The email notifies them that another administrator has changed their password by using SSPR.
Example: There are four administrators in an environment. Administrator A resets their password by using SSPR.
Administrators B, C, and D receive an email that alerts them of the password reset.
On-premises integration
If you install, configure, and enable Azure AD Connect, you have the following additional options for on-premises
integrations. If these options are grayed out, then writeback has not been properly configured. For more
information, see Configuring password writeback.
This page provides you a quick status of the on-premises writeback client one of the following messages are
displayed based on the current configuration:
Your On-premises writeback client is up and running.
Azure AD is online and is connected to your on-premises writeback client. However, it looks like the installed
version of Azure AD Connect is out-of-date. Consider Upgrading Azure AD Connect to ensure that you have
the latest connectivity features and important bug fixes.
Unfortunately, we can’t check your on-premises writeback client status because the installed version of Azure
AD Connect is out-of-date. Upgrade Azure AD Connect to be able to check your connection status.
Unfortunately, it looks like we can't connect to your on-premises writeback client right now. Troubleshoot
Azure AD Connect to restore the connection.
Unfortunately, we can't connect to your on-premises writeback client because password writeback has not
been properly configured. Configure password writeback to restore the connection.
Unfortunately, it looks like we can't connect to your on-premises writeback client right now. This may be due
to temporary issues on our end. If the problem persists, Troubleshoot Azure AD Connect to restore the
connection.
Write back passwords to your on-premises directory
This control determines whether password writeback is enabled for this directory. If writeback is on, it indicates
the status of the on-premises writeback service. This is useful if you want to temporarily disable password
writeback without having to reconfigure Azure AD Connect.
If the switch is set to Yes, then writeback is enabled, and federated and password hash synchronized users are
able to reset their passwords.
If the switch is set to No, then writeback is disabled, and federated and password hash synchronized users are
not able to reset their passwords.
Allow users to unlock accounts without resetting their password
This control designates whether users who visit the password reset portal should be given the option to unlock
their on-premises Active Directory accounts without having to reset their password. By default, Azure AD unlocks
accounts when it performs a password reset. You use this setting to separate those two operations.
If set to Yes, then users are given the option to reset their password and unlock the account, or to unlock their
account without having to reset the password.
If set to No, then users are only be able to perform a combined password reset and account unlock operation.
How does password reset work for B2B users?

Password reset and change are fully supported on all business-to-business (B2B) configurations. B2B user
password reset is supported in the following three cases:
Users from a partner organization with an existing Azure AD tenant: If the organization you're
partnering with has an existing Azure AD tenant, we respect whatever password reset policies are enabled on
that tenant. For password reset to work, the partner organization just needs to make sure that Azure AD SSPR
is enabled. There is no additional charge for Office 365 customers, and it can be enabled by following the steps
in our Get started with password management guide.
Users who sign up through self-service sign-up: If the organization you're partnering with used the self-
service sign-up feature to get into a tenant, we let them reset the password with the email they registered.
B2B users: Any new B2B users created by using the new Azure AD B2B capabilities will also be able to reset
their passwords with the email they registered during the invite process.
To test this scenario, go to http://passwordreset.microsoftonline.com with one of these partner users. If they have
an alternate email or authentication email defined, password reset works as expected.
NOTE
Microsoft accounts that have been granted guest access to your Azure AD tenant, such as those from Hotmail.com,
Outlook.com, or other personal email addresses, are not able to use Azure AD SSPR. They need to reset their password by
using the information found in the When you can't sign in to your Microsoft account article.
Next steps
The following articles provide additional information regarding password reset through Azure AD:
How to successfully roll out self-service password
reset
To ensure a smooth rollout of the Azure Active directory (Azure AD) self-service password reset (SSPR)
functionality, most customers complete the following steps:
1. Enable password reset in your directory.
2. Configure on-premises Active Directory permissions for password writeback.
3. Configure password writeback to write passwords from Azure AD back to your on-premises directory.
4. Assign and verify the required licenses.
5. Determine if you want to do a gradual rollout. If you want to roll out SSPR gradually, you can limit access to a
group of users so you can pilot the program with a specific group. To roll out to a specific group, set the Self
Service Password Reset Enabled switch to Selected and select the security group you want to be able use
password reset.
6. Populate the authentication data needed for your users to register, such as their office phone, mobile phone,
and alternate email address.
7. Customize the Azure AD sign-in experience to include your company branding.
8. Teach your users how to use SSPR. Send them instructions to show them how to register and how to reset
their passwords.
9. Determine when you want to enforce registration. You can choose to enforce registration at any point. You
can also require users to reconfirm their authentication information after a certain period of time.
10. Use the reporting capability. Over time, you can review the users registration and usage with the reporting
capability that Azure AD provides.
11. Enable password reset. When you're ready, enable password reset for all users by setting the Self Service
Password Reset Enabled switch to All.
NOTE
Changing this option from a selected group to everyone does not invalidate existing authentication data that a
user has registered as part of a test group. Users who are configured and have valid authentication data registered
continue to function.
12. Enable Windows 10 users to reset their password at the login screen.
IMPORTANT
Test SSPR with a user, rather than an administrator, as Microsoft enforces strong authentication requirements for
Azure administrator accounts. For more information regarding the administrator password policy, see our
password policy article.
Email-based rollout
Many customers find that the easiest way to get users to use SSPR is with an email campaign that includes
simple-to-use instructions. We have created three simple emails that you can use as templates to help in your
rollout:
Coming soon: An email template that you use in the weeks or days before the rollout to let users know they
need to do something.
Available now: An email template that you use the day of the program launch to drive users to register and
confirm their authentication data. If users register now, they have SSPR available when they need it.
Sign-up reminder: An email template for a few days to a few weeks after deployment to remind users to
register and confirm their authentication data.
Create your own password portal

Many customers choose to host a webpage and create a root DNS entry, like https://passwords.contoso.com.
They populate this page with links to the following information:
Azure AD password reset portal - https://aka.ms/sspr
Azure AD password reset registration portal - http://aka.ms/ssprsetup
Azure AD password change portal - https://account.activedirectory.windowsazure.com/ChangePassword.aspx
Other organization-specific information
In any email communications or fliers you send out you can include a branded, memorable URL that users can
go to when they need to use the services. For your benefit, we have created a sample password reset page that
you can use and customize to your organization’s needs.
Use enforced registration

If you want your users to register for password reset, you can require that they register when they sign in
through Azure AD. You can enable this option from your directory’s Password reset pane by enabling the
Require Users to Register when Signing in option on the Registration tab.
Administrators can require users to re-register after a specific period of time. They can set the Number of days
before users are asked to reconfirm their authentication information option to 0 to 730 days.
After you enable this option, when users sign in they see a message that says their administrator has required
them to verify their authentication information.
Populate authentication data

You should populate the authentication data for your users. That way users don't need to register for password
reset before they are able to use SSPR. As long as users have provided the authentication data that meets the
password reset policy you have defined, they are able to reset their passwords.
Disable self-service password reset

It's easy to disable self-service password reset. Open your Azure AD tenant and go to Password Reset >
Properties, and then select None under Self Service Password Reset Enabled.
Next steps
Azure AD password reset from the login screen
You have already deployed Azure AD self-service password reset (SSPR) but your users still call the helpdesk when
they forget their passwords. They call the helpdesk because they can't get to a web browser to access SSPR.
With the new Windows 10 Fall Creators Update, users with Azure AD joined devices can see a “Reset password”
link on their login screen. When they click this link, they are brought to the same self-service password reset (SSPR)
experience they are familiar with.
To enable users to reset their Azure AD password from the Windows 10 login screen, the following requirements
need to be met:
Windows 10, version 1709, or newer client that is Azure AD joined.
Azure AD self-service password reset must be enabled.
Configure and deploy the setting to enable the Reset password link via one of the following methods:
Intune device configuration profile
Registry key
Configure Reset password link using Intune

Create a device configuration policy in Intune
1. Log in to the Azure portal and click on Intune.
2. Create a new device configuration profile by going to Device configuration > Profiles > Create Profile
Provide a meaningful name for the profile
Optionally provide a meaningful description of the profile
Platform Windows 10 and later
Profile type Custom
3. Configure Settings
Add the following OMA-URI Setting to enable the Reset password link
Provide a meaningful name to explain what the setting is doing
Optionally provide a meaningful description of the setting
OMA-URI set to ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset
Data type set to Integer
Value set to 1
Click OK
Click OK
4. Click Create
Assign a device configuration policy in Intune
Create a group to apply device configuration policy to
1. Log in to the Azure portal and click on Azure Active Directory.
2. Browse to Users and groups > All groups > New group
3. Provide a name for the group and under Membership type choose Assigned
Under Members, choose the Azure AD joined Windows 10 devices that you want to apply the policy to.
Click Select
4. Click Create
More information on creating groups can be found in the article Manage access to resources with Azure Active
Directory groups.
Assign device configuration policy to device group
1. Log in to the Azure portal and click on Intune.
2. Find the device configuration profile created previously by going to Device configuration > Profiles > Click
on the profile created earlier
3. Assign the profile to a group of devices
Click on Assignments > under Include > Select groups to include
Select the group created previously and click Select
Click on Save
You have now created and assigned a device configuration policy to enable the Reset password link on the logon
screen using Intune.
Configure Reset password link using the registry

We recommend using this method only to test the setting change.
1. Log in to the Azure AD joined device using administrative credentials
2. Run regedit as an administrator
3. Set the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount
"AllowPasswordReset"=dword:00000001
What do users see

Now that the policy is configured and assigned, what changes for the user? How do they know that they can reset
their password at the logon screen?
When users attempt to log in, they now see a Reset password link that opens the self-service password reset
experience at the logon screen. This functionality allows users to reset their password without having to use
another device to access a web browser.
Your users will find guidance for using this feature in Reset your work or school password
Common issues
When testing this functionality using Hyper-V, the "Reset password" link does not appear.
Go to the VM you are using to test click on View and then uncheck Enhanced session.
When testing this functionality using Remote Desktop, the "Reset password" link does not appear
Password reset is not currently supported from a Remote Desktop.
Next steps
The following links provide additional information regarding password reset using Azure AD
How do I deploy SSPR?
How do I enable PIN reset from the login screen?
More information about MDM authentication policies
Password policies and restrictions in Azure Active
Directory
This article describes the password policies and complexity requirements associated with user accounts stored in
your Azure Active Directory (Azure AD) tenant.
Administrator password policy differences

Microsoft enforces a strong default two-gate password reset policy for any Azure administrator role.
With a two-gate policy, administrators don't have the ability to use security questions.
A two-gate policy requires two pieces of authentication data, such as an email address and a phone number. A
two-gate policy applies in the following circumstances:
All the following Azure administrator roles are affected:
Helpdesk administrator
Service support administrator
Billing administrator
Exchange service administrator
Lync service administrator
User account administrator
Directory writers
Global administrator or company administrator
SharePoint service administrator
Compliance administrator
Application administrator
Security administrator
Privileged role administrator
Microsoft Intune service administrator
Application proxy service administrator
CRM service administrator
Power BI service administrator
If 30 days have elapsed in a trial subscription
or
A vanity domain is present, such as contoso.com
or
Azure AD Connect is synchronizing identities from your on-premises directory
Exceptions
A one-gate policy requires one piece of authentication data, such as an email address or phone number. A one-
gate policy applies in the following circumstances:
It's within the first 30 days of a trial subscription
or
A vanity domain isn't present (*.onmicrosoft.com)
and
Azure AD Connect isn't synchronizing identities
UserPrincipalName policies that apply to all user accounts

Every user account that needs to sign in to Azure AD must have a unique user principal name (UPN) attribute
value associated with their account. The following table outlines the polices that apply to both on-premises Active
Directory user accounts that are synchronized to the cloud and to cloud-only user accounts:
PROPERTY USERPRINCIPALNAME REQUIREMENTS
Characters allowed A–Z

a-z
0–9
.-_!#^~
Characters not allowed Any "@" character that's not separating the username
from the domain.</li> <li>Can't contain a period
character "." immediately preceding the "@" symbol
Length constraints The total length must not exceed 113 characters
There can be up to 64 characters before the "@"
symbol</li><li>There can be up to 48 characters
after the "@" symbol
Password policies that only apply to cloud user accounts

The following table describes the available password policy settings that can be applied to user accounts that are
created and managed in Azure AD:
PROPERTY REQUIREMENTS
Characters allowed A–Z

a-z
0–9
@#$%^&*-_!+=[]{}|\:‘,.?/`~“();
Characters not allowed Unicode characters.

Spaces.
Strong passwords only: Can't contain a dot character
"." immediately preceding the "@" symbol.
PROPERTY REQUIREMENTS
Password restrictions A minimum of 8 characters and a maximum of 16

characters.
Strong passwords only: Requires three out of four of
the following:
Lowercase characters.
Uppercase characters.
Numbers (0-9).
Symbols (see the previous password
restrictions).
Password expiry duration Default value: 90 days.

The value is configurable by using the
Set-MsolPasswordPolicy cmdlet from the Azure
Active Directory Module for Windows PowerShell.
Password expiry notification Default value: 14 days (before password expires).

The value is configurable by using the
Set-MsolPasswordPolicy cmdlet.
Password expiry Default value: false days (indicates that password

expiry is enabled).
The value can be configured for individual user
accounts by using the Set-MsolUser cmdlet.
Password change history The last password can't be used again when the user changes
a password.
Password reset history The last password can be used again when the user resets a
forgotten password.
Account lockout After 10 unsuccessful sign-in attempts with the wrong

password, the user is locked out for one minute. Further
incorrect sign-in attempts lock out the user for increasing
durations of time.
Set password expiration policies in Azure AD

A global administrator for a Microsoft cloud service can use the Microsoft Azure AD Module for Windows
PowerShell to set user passwords not to expire. You can also use Windows PowerShell cmdlets to remove the
never-expires configuration or to see which user passwords are set to never expire.
This guidance applies to other providers, such as Intune and Office 365, which also rely on Azure AD for identity
and directory services. Password expiration is the only part of the policy that can be changed.
NOTE
Only passwords for user accounts that are not synchronized through directory synchronization can be configured to not
expire. For more information about directory synchronization, see Connect AD with Azure AD.
Set or check the password policies by using PowerShell

To get started, you need to download and install the Azure AD PowerShell module. After you have it installed, you
can use the following steps to configure each field.
How to check the expiration policy for a password
1. Connect to Windows PowerShell by using your company administrator credentials.
2. Execute one of the following commands:
To see if a single user’s password is set to never expire, run the following cmdlet by using the UPN (for
example, aprilr@contoso.onmicrosoft.com) or the user ID of the user you want to check:
Get-MSOLUser -UserPrincipalName <user ID> | Select PasswordNeverExpires
To see the Password never expires setting for all users, run the following cmdlet:
Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires
Set a password to expire

To set the password of one user so that the password expires, run the following cmdlet by using the
UPN or the user ID of the user:
Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $false
To set the passwords of all users in the organization so that they expire, use the following cmdlet:
Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $false
Set a password to never expire

To set the password of one user to never expire, run the following cmdlet by using the UPN or the user
ID of the user: Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $true
To set the passwords of all the users in an organization to never expire, run the following cmdlet:
Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true
WARNING
Passwords set to -PasswordNeverExpires $true still age based on the pwdLastSet attribute. If you set the user
passwords to never expire and then 90+ days go by, the passwords expire. Based on the pwdLastSet attribute, if
you change the expiration to -PasswordNeverExpires $false , all passwords that have a pwdLastSet older than
90 days require the user to change them the next time they sign in. This change can affect a large number of users.
Next steps
The following articles provide additional information about password reset through Azure AD:
Customize the Azure AD functionality for self-service
password reset
IT professionals who want to deploy self-service password reset (SSPR) in Azure Active directory (Azure AD) can
customize the experience to match their users' needs.
Customize the "Contact your administrator" link

Even if SSPR is not enabled, users still have a "Contact your administrator" link on the password reset portal. If a
user selects this link, it either:
Emails your administrators and asks them for assistance in changing the user's password.
Sends your users to a URL that you specify for assistance.
We recommend that you set this contact to something like an email address or website that your users already use
for support questions.
The contact email is sent to the following recipients in the following order:
1. If the password administrator role is assigned, administrators with this role are notified.
2. If no password administrators are assigned, then administrators with the user administrator role are notified.
3. If neither of the previous roles are assigned, then the global administrators are notified.
In all cases, a maximum of 100 recipients are notified.
To find out more about the different administrator roles and how to assign them, see Assigning administrator roles
in Azure Active Directory.
Disable "Contact your administrator" emails
If your organization does not want to notify administrators about password reset requests, you can enable the
following configuration:
Enable self-service password reset for all end users. This option is under Password Reset > Properties.
If you don't want users to reset their own passwords, you can scope access to an empty group. We don't
recommend this option.
Customize the helpdesk link to provide a web URL or mailto: address that users can use to get assistance. This
option is under Password Reset > Customization > Custom helpdesk email or URL.
Customize the AD FS sign-in page for SSPR

Active Directory Federation Services (AD FS) administrators can add a link to their sign-in page by using the
guidance found in the Add sign-in page description article.
To add a link to the AD FS sign-in page, use the following command on your AD FS server. Users can use this page
to enter the SSPR workflow.
Set-ADFSGlobalWebContent -SigninPageDescriptionText "<p><A
href=’https://passwordreset.microsoftonline.com’>Can’t access your account?</A></p>"
Customize the sign-in page and access panel look and feel
You can customize the sign-in page. You can add a logo that appears along with the image that fits your company
branding.
The graphics you choose are shown in the following circumstances:
After a user enters their username
If the user accesses the customized URL:
By passing the whr parameter to the password reset page, like "https://login.microsoftonline.com/?
whr=contoso.com"
By passing the username parameter to the password reset page, like "https://login.microsoftonline.com/?
username=admin@contoso.com"
Graphics details
Use the following settings to change the visual characteristics of the sign-in page. Go to Azure Active Directory >
Company branding > Edit company branding:
The sign-in page image should be a .png or .jpg file, 1420 x 1200 pixels, and no larger than 500 KB. For the best
results, we recommend that you keep it around 200 KB.
The sign-in page background color is used on high-latency connections and must be in RGB hexadecimal
format.
The banner image should be a .png or .jpg file, 60 x 280 pixels, and be no larger than 10 KB.
The square logo (normal and dark theme) should be a .png or .jpg file, 240 x 240 (resizable) pixels, and no larger
than 10 KB.
Sign-in text options
Use the following settings to add text to the sign-in page that's relevant to your organization. Go to Azure Active
Directory > Company branding > Edit company branding:
User name hint: Replaces the example text of someone@example.com with something more appropriate for
your users. We recommended that you leave the default hint when you support internal and external users.
Sign-in page text: Can be a maximum of 256 characters in length. This text appears anywhere your users
sign in online and in the Azure AD Workplace Join experience on Windows 10. Use this text for the terms of
use, instructions, and tips for your users.
IMPORTANT
Anyone can see your sign-in page, so don't provide any sensitive information here.
The "Keep me signed in disabled" setting

With the Keep me signed in disabled option, users can remain signed in when they close and reopen their
browser window. This option does not impact the session lifetime. Go to Azure Active Directory > Company
branding > Edit company branding.
Some features of SharePoint Online and Office 2010 have a dependency on users' ability to select this check box. If
you hide this option, users can get additional and unexpected sign-in prompts.
Directory name
You can change the directory name attribute under Azure Active Directory > Properties. You can show a
friendly organization name that is seen in the portal and in the automated communications. This option is the most
visible in automated emails in the forms that follow:
The friendly name in the email, for example “Microsoft on behalf of CONTOSO demo”
The subject line in the email, for example “CONTOSO demo account email verification code”
Next steps
Deploy password reset without requiring end-user
registration
To deploy Azure Active Directory (Azure AD) self-service password reset (SSPR), authentication data needs to be
present. Some organizations have their users enter their authentication data themselves. But many organizations
prefer to synchronize with data that already exists in Active Directory. The synced data is made available to Azure
AD and SSPR without requiring user interaction if you:
Properly format the data in your on-premises directory.
Configure Azure AD Connect by using the express settings.
To work properly, phone numbers must be in the format +CountryCode PhoneNumber, for example, +1
4255551234.
NOTE
Password reset does not support phone extensions. Even in the +1 4255551234X12345 format, extensions are removed
before the call is placed.
Fields populated
If you use the default settings in Azure AD Connect, the following mappings are made:
AZURE AD AUTHENTICATION CONTACT

ON-PREMISES ACTIVE DIRECTORY AZURE AD INFO
telephoneNumber Office phone Alternate phone
mobile Mobile phone Phone
Security questions and answers

The security questions and answers are stored securely in your Azure AD tenant and are only accessible to users
via the SSPR registration portal. Administrators can't see or modify the contents of another users' questions and
answers.
What happens when a user registers
When a user registers, the registration page sets the following fields:
Authentication Phone
Authentication Email
Security Questions and Answers
If you have provided a value for Mobile phone or Alternate email, users can immediately use those values to
reset their passwords, even if they haven't registered for the service. In addition, users see those values when
they register for the first time, and they can modify them if they want to. After they register successfully, these
values will be persisted in the Authentication Phone and Authentication Email fields, respectively.
Set and read the authentication data through PowerShell
The following fields can be set through PowerShell:
Alternate email
Mobile phone
Office phone: Can only be set if you're not synchronizing with an on-premises directory
Use PowerShell version 1
To get started, you need to download and install the Azure AD PowerShell module. After you have it installed,
you can use the steps that follow to configure each field.
Set the authentication data with PowerShell version 1
Connect-MsolService
Set-MsolUser -UserPrincipalName user@domain.com -AlternateEmailAddresses @("email@domain.com")

Set-MsolUser -UserPrincipalName user@domain.com -MobilePhone "+1 1234567890"
Set-MsolUser -UserPrincipalName user@domain.com -PhoneNumber "+1 1234567890"
Set-MsolUser -UserPrincipalName user@domain.com -AlternateEmailAddresses @("email@domain.com") -MobilePhone

"+1 1234567890" -PhoneNumber "+1 1234567890"
Read the authentication data with PowerShell version 1
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select AlternateEmailAddresses

Get-MsolUser -UserPrincipalName user@domain.com | select MobilePhone
Get-MsolUser -UserPrincipalName user@domain.com | select PhoneNumber
Get-MsolUser | select DisplayName,UserPrincipalName,AlternateEmailAddresses,MobilePhone,PhoneNumber |

Format-Table
Read the Authentication Phone and Authentication Email options

To read the Authentication Phone and Authentication Email when you use PowerShell version 1, use the
following commands:
Connect-MsolService
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
PhoneNumber
Get-MsolUser -UserPrincipalName user@domain.com | select -Expand StrongAuthenticationUserDetails | select
Email
Use PowerShell version 2

To get started, you need to download and install the Azure AD version 2 PowerShell module. After you have it
installed, you can use the steps that follow to configure each field.
To quickly install from recent versions of PowerShell that support Install-Module, run the following commands.
(The first line checks to see if the module is already installed.)
Get-Module AzureADPreview
Install-Module AzureADPreview
Connect-AzureAD
Set the authentication data with PowerShell version 2

Connect-AzureAD
Set-AzureADUser -ObjectId user@domain.com -OtherMails @("email@domain.com")

Set-AzureADUser -ObjectId user@domain.com -Mobile "+1 2345678901"
Set-AzureADUser -ObjectId user@domain.com -TelephoneNumber "+1 1234567890"
Set-AzureADUser -ObjectId user@domain.com -OtherMails @("emails@domain.com") -Mobile "+1 1234567890" -

TelephoneNumber "+1 1234567890"
Read the authentication data with PowerShell version 2
Connect-AzureAD
Get-AzureADUser -ObjectID user@domain.com | select otherMails

Get-AzureADUser -ObjectID user@domain.com | select Mobile
Get-AzureADUser -ObjectID user@domain.com | select TelephoneNumber
Get-AzureADUser | select DisplayName,UserPrincipalName,otherMails,Mobile,TelephoneNumber | Format-Table
Next steps
Reporting options for Azure AD password
management
After deployment, many organizations want to know how or if self-service password reset (SSPR) is really being
used. The reporting feature that Azure Active Directory (Azure AD) provides helps you answer questions by using
prebuilt reports. If you're appropriately licensed, you can also create custom queries.
The following questions can be answered by the reports that exist in the Azure portal:
NOTE
You must be a global administrator, and you must opt-in for this data to be gathered on behalf of your organization. To
opt in, you must visit the Reporting tab or the audit logs at least once. Until then, data is not collected for your
organization.
How many people have registered for password reset?

Who has registered for password reset?
What data are people registering?
How many people reset their passwords in the last seven days?
What are the most common methods that users or admins use to reset their passwords?
What are common problems users or admins face when attempting to use password reset?
What admins are resetting their own passwords frequently?
Is there any suspicious activity going on with password reset?
Power BI content pack
If you're a Power BI user, there is a content pack for Azure AD that includes easy-to-use reporting for SSPR. For
more information on how to use and deploy the content pack, see How to use the Azure Active Directory Power
BI content pack. With the content pack, you can create your own dashboards and share them with others in your
organization.
How to view password management reports in the Azure portal

In the Azure portal experience, we have improved the way that you can view password reset and password reset
registration activity. Use the following the steps to find the password reset and password reset registration
events:
1. Browse to the Azure portal.
2. Select All services in the left pane.
3. Search for Azure Active Directory in the list of services and select it.
5. Select Audit Logs from the Users and groups menu. This shows you all of the audit events that occurred
against all the users in your directory. You can filter this view to see all the password-related events.
6. To filter this view to see only the password-reset-related events, select the Filter button at the top of the pane.
7. From the Filter menu, select the Category drop-down list, and change it to the Self-service Password
Management category type.
8. Optionally, further filter the list by choosing the specific Activity you're interested in.
How to retrieve password management events from the Azure AD

Reports and Events API
The Azure AD Reports and Events API supports the retrieval of all the information included in password reset and
password reset registration reports. By using this API, you can download individual password reset and
password reset registration events and integrate them with the reporting technology of your choice.
IMPORTANT
Currently, the Azure AD Reports and Events API retrieves up to 75,000 individual events of the SsprActivityEvent and
SsprRegistrationActivityEvent types. The API spans the last 30 days.
If you need to retrieve or store data beyond this window, we suggest persisting it in an external database by using the API
to query the deltas that result. We recommend that you begin to retrieve this data when you start using SSPR in your
organization. Persist it externally, and then continue to track the deltas from that point forward.
How to get started with the reporting API

To access this data, you need to write a small application or script to retrieve it from our servers. For more
information, see Get started with the Azure AD reporting API.
After you have a working script, you'll want to examine the password reset and registration events that you can
retrieve to meet your scenarios:
SsprActivityEvent: Lists the columns available for password reset events.
SsprRegistrationActivityEvent: Lists the columns available for password reset registration events.
Description of the report columns in the Azure portal

The following list explains each of the report columns in the Azure portal in detail:
User: The user who attempted a password reset registration operation.
Role: The role of the user in the directory.
Date and Time: The date and time of the attempt.
Data Registered: The authentication data that the user provided during password reset registration.
Description of the report values in the Azure portal

The following table describes the different values that are you can set for each column in the Azure portal:
COLUMN PERMITTED VALUES AND THEIR MEANINGS
Data registered Alternate email: The user used an alternate email or

authentication email to authenticate.
Office phone: The user used an office phone to
authenticate.
Mobile phone: The user used a mobile phone or
authentication phone to authenticate.
Security questions: The user used security questions to
authenticate.
Any combination of the previous methods, for
example, alternate email + mobile phone: Occurs
when a two-gate policy is specified and shows which two
methods the user used to authentication their password
reset request.
Self-Service Password Management activity types

The following activity types appear in the Self-Service Password Management audit event category:
Blocked from self-service password reset: Indicates that a user tried to reset a password, use a specific gate, or
validate a phone number more than five total times in 24 hours.
Change password (self-service): Indicates that a user performed a voluntary, or forced (due to expiry)
password change.
Reset password (by admin): Indicates that an administrator performed a password reset on behalf of a user
from the Azure portal.
Reset password (self-service): Indicates that a user successfully reset their password from the Azure AD
password reset portal.
Self-service password reset flow activity progress: Indicates each specific step a user proceeds through, such
as passing a specific password reset authentication gate, as part of the password reset process.
Unlock user account (self-service): Indicates that a user successfully unlocked their Active Directory account
without resetting their password from the Azure AD password reset portal by using the Active Directory
feature of account unlock without reset.
User registered for self-service password reset: Indicates that a user has registered all the required
information to be able to reset their password in accordance with the currently specified tenant password
reset policy.
Activity type: Blocked from self-service password reset
The following list explains this activity in detail:
Activity description: Indicates that a user tried to reset a password, use a specific gate, or validate a phone
number more than five total times in 24 hours.
Activity actor: The user who was throttled from performing additional reset operations. The user can be an
end user or an administrator.
Activity target: The user who was throttled from performing additional reset operations. The user can be an
Activity status:
Success: Indicates that a user was throttled from performing any additional resets, attempting any
additional authentication methods, or validating any additional phone numbers for the next 24 hours.
Activity status failure reason: Not applicable.
Activity type: Change password (self-service )
Activity description: Indicates that a user performed a voluntary, or forced (due to expiry) password change.
Activity actor: The user who changed their password. The user can be an end user or an administrator.
Activity target: The user who changed their password. The user can be an end user or an administrator.
Activity statuses:
Success: Indicates that a user successfully changed their password.
Failure: Indicates that a user failed to change their password. You can select the row to see the Activity
status reason category to learn more about why the failure occurred.
Activity status failure reason:
FuzzyPolicyViolationInvalidPassword: The user selected a password that was automatically banned
because the Microsoft Banned Password Detection capabilities found it to be too common or especially
weak.
Activity type: Reset password (by admin)
Activity description: Indicates that an administrator performed a password reset on behalf of a user from
the Azure portal.
Activity actor: The administrator who performed the password reset on behalf of another end user or
administrator. Must be either a global administrator, password administrator, user administrator, or helpdesk
administrator.
Activity target: The user whose password was reset. The user can be an end user or a different
administrator.
Activity statuses:
Success: Indicates that an admin successfully reset a user's password.
Failure: Indicates that an admin failed to change a user's password. You can select the row to see the
Activity status reason category to learn more about why the failure occurred.
Activity type: Reset password (self-service )
Activity description: Indicates that a user successfully reset their password from the Azure AD password
reset portal.
Activity actor: The user who reset their password. The user can be an end user or an administrator.
Activity target: The user who reset their password. The user can be an end user or an administrator.
Activity statuses:
Success: Indicates that a user successfully reset their own password.
Failure: Indicates that a user failed to reset their own password. You can select the row to see the
Activity status failure reason:
FuzzyPolicyViolationInvalidPassword: The admin selected a password that was automatically banned
because the Microsoft Banned Password Detection capabilities found it to be too common or especially
weak.
Activity type: Self serve password reset flow activity progress
Activity description: Indicates each specific step a user proceeds through (such as passing a specific
password reset authentication gate) as part of the password reset process.
Activity actor: The user who performed part of the password reset flow. The user can be an end user or an
administrator.
Activity target: The user who performed part of the password reset flow. The user can be an end user or an
administrator.
Activity statuses:
Success: Indicates that a user successfully completed a specific step of the password reset flow.
Failure: Indicates that a specific step of the password reset flow failed. You can select the row to see the
Activity status reasons: See the following table for all the permissible reset activity status reasons.
Activity type: Unlock a user account (self-service )
Activity description: Indicates that a user successfully unlocked their Active Directory account without
resetting their password from the Azure AD password reset portal by using the Active Directory feature of
account unlock without reset.
Activity actor: The user who unlocked their account without resetting their password. The user can be an
Activity target: The user who unlocked their account without resetting their password. The user can be an
Allowed activity statuses:
Success: Indicates that a user successfully unlocked their own account.
Failure: Indicates that a user failed to unlock their account. You can select the row to see the Activity
status reason category to learn more about why the failure occurred.
Activity type: User registered for self-service password reset
Activity description: Indicates that a user has registered all the required information to be able to reset their
password in accordance with the currently specified tenant password reset policy.
Activity actor: The user who registered for password reset. The user can be an end user or an administrator.
Activity target: The user who registered for password reset. The user can be an end user or an administrator.
Allowed activity statuses:
Success: Indicates that a user successfully registered for password reset in accordance with the current
policy.
Failure: Indicates that a user failed to register for password reset. You can select the row to see the
NOTE
Failure doesn't mean a user is unable to reset their own password. It means that they didn't finish the
registration process. If there is unverified data on their account that's correct, such as a phone number
that's not validated, even though they have not verified this phone number, they can still use it to reset
their password. For more information, see What happens when a user registers?.
Next steps
Reset the password for a user in Azure Active
Directory
Administrators may need to reset a user's password in cases where they forgot, were locked out, or other
scenarios. The steps that follow guide you through resetting a user's password.
How to reset the password for a user

1. Sign in to the Azure AD Admin Center with an account that has directory permissions to reset user passwords.
2. Select Azure Active Directory > Users and groups > All users.
3. Select the user you would like to reset the password for.
4. For the selected user, select Reset password.
5. On Reset password, select Reset password.

6. A temporary password is displayed that you can then provide to the user. The user will be asked to then
change their password the next time they logon.
NOTE
This temporary password does not have an expiration time so it will be valid until they log in and are then are forced
to change it.
Next steps
Add a user
Assign administrator roles to a user
Delete a user in Azure AD
Licensing requirements for Azure AD self-service
password reset
In order for Azure Active Directory (Azure AD) password reset to function, you must have at least one license
assigned in your organization. We don't enforce per-user licensing on the password reset experience. To
maintain compliance with your Microsoft licensing agreement, you need to assign licenses to any users that use
premium features.
Cloud-only users: Office 365 any paid SKU, or Azure AD Basic
Cloud or on-premises users: Azure AD Premium P1 or P2, Enterprise Mobility + Security (EMS), or Microsoft
365
Licenses required for password writeback

To use password writeback, you must have one of the following licenses assigned on your tenant:
Azure AD Premium P1
Azure AD Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 (Plan E3)
Microsoft 365 (Plan E5)
WARNING
Standalone Office 365 licensing plans don't support password writeback and require that you have one of the preceding
plans for this functionality to work.
Additional licensing information, including costs, can be found on the following pages:
Azure Active Directory pricing site
Azure Active Directory features and capabilities
Microsoft 365 Enterprise
Enable group or user-based licensing

Azure AD now supports group-based licensing. Administrators can assign licenses in bulk to a group of users,
rather than assigning them one at a time. For more information, see Assign, verify, and resolve problems with
licenses.
Some Microsoft services are not available in all locations. Before a license can be assigned to a user, the
administrator must specify the Usage location property on the user. Assignment of licenses can be done under
the User > Profile > Settings section in the Azure portal. When you use group license assignment, any users
without a usage location specified inherit the location of the directory.
Next steps
Password writeback overview
With password writeback, you can configure Azure Active Directory (Azure AD) to write passwords back to your
on-premises Active Directory. Password writeback removes the need to set up and manage a complicated on-
premises self-service password reset (SSPR) solution, and it provides a convenient cloud-based way for your
users to reset their on-premises passwords wherever they are. Password writeback is a component of Azure
Active Directory Connect that can be enabled and used by current subscribers of Premium Azure Active
Directory editions.
Password writeback provides the following features:
Provides zero-delay feedback: Password writeback is a synchronous operation. Your users are notified
immediately if their password did not meet the policy or could not be reset or changed for any reason.
Supports password resets for users that use Active Directory Federation Services (AD FS) or other
federation technologies: With password writeback, as long as the federated user accounts are
synchronized into your Azure AD tenant, they are able to manage their on-premises Active Directory
passwords from the cloud.
Supports password resets for users that use password hash sync: When the password reset service
detects that a synchronized user account is enabled for password hash sync, we reset both this account’s on-
premises and cloud password simultaneously.
Supports password changes from the access panel and Office 365: When federated or password
synchronized users come to change their expired or non-expired passwords, we write those passwords back
to your local Active Directory environment.
Supports passwords writeback when an admin resets them from the Azure portal: Whenever an
admin resets a user’s password in the Azure portal, if that user is federated or password synchronized, we’ll
set the password the admin selects in local Active Directory as well. This functionality is currently not
supported in the Office admin portal.
Enforces your on-premises Active Directory password policies: When a user resets their password, we
make sure that it meets your on-premises Active Directory policy before we commit it to that directory. This
review includes checking the history, complexity, age, password filters, and any other password restrictions
that you have defined in local Active Directory.
Doesn’t require any inbound firewall rules: Password writeback uses an Azure Service Bus relay as an
underlying communication channel. You don't have to open any inbound ports on your firewall for this
feature to work.
Is not supported for user accounts that exist within protected groups in on-premises Active
Directory: For more information about protected groups, see Protected accounts and groups in Active
Directory.
How password writeback works

When a federated or password hash synchronized user comes to reset or change their password in the cloud,
the following occurs:
1. We check to see what type of password the user has. If we see that the password is managed on-premises:
We check if the writeback service is up and running. If it's up and running, we let the user proceed.
If the writeback service is not up, we tell the user that their password can't be reset right now.
2. Next, the user passes the appropriate authentication gates and reaches the Reset password page.
3. The user selects a new password and confirms it.
4. When the user selects Submit, we encrypt the plaintext password with a symmetric key that was created
during the writeback setup process.
5. After encrypting the password, we include it in a payload that gets sent over an HTTPS channel to your
tenant-specific service bus relay (that we also set up for you during the writeback setup process). This relay is
protected by a randomly generated password that only your on-premises installation knows.
6. After the message reaches the service bus, the password-reset endpoint automatically wakes up and sees
that it has a reset request pending.
7. The service then looks for the user by using the cloud anchor attribute. For this lookup to succeed:
The user object must exist in the Active Directory connector space.
The user object must be linked to the corresponding metaverse (MV) object.
The user object must be linked to the corresponding Azure Active Directory connector object.
The link from the Active Directory connector object to the MV must have the synchronization rule
Microsoft.InfromADUserAccountEnabled.xxx on the link.
When the call comes in from the cloud, the synchronization engine uses the cloudAnchor
attribute to look up the Azure Active Directory connector space object. It then follows the link back
to the MV object, and then follows the link back to the Active Directory object. Because there can be
multiple Active Directory objects (multi-forest) for the same user, the sync engine relies on the
Microsoft.InfromADUserAccountEnabled.xxx link to pick the correct one.
NOTE
As a result of this logic, for password writeback to work Azure AD Connect must be able to communicate
with the primary domain controller (PDC) emulator. If you need to enable this manually, you can connect
Azure AD Connect to the PDC emulator. Right-click the properties of the Active Directory synchronization
connector, then select configure directory partitions. From there, look for the domain controller
connection settings section and select the box titled only use preferred domain controllers. Even if
the preferred domain controller is not a PDC emulator, Azure AD Connect attempts to connect to the PDC
for password writeback.
8. After the user account is found, we attempt to reset the password directly in the appropriate Active
Directory forest.
9. If the password set operation is successful, we tell the user their password has been changed.
NOTE
If the user's password is synchronized to Azure AD by using password synchronization, there is a chance that the
on-premises password policy is weaker than the cloud password policy. In this case, we still enforce whatever the
on-premises policy is, and instead use password hash synchronization to synchronize the hash of that password.
This policy ensures that your on-premises policy is enforced in the cloud, no matter if you use password
synchronization or federation to provide single sign-on.
10. If the password set operation fails, we return an error to the user and let them try again. The operation
might fail because:
The service was down.
The password they selected did not meet the organization's policies.
We might not find the user in local Active Directory.
We have a specific message for many of these cases and tell the user what they can do to resolve the
problem.
Configure password writeback
We recommend that you use the auto-update feature of Azure AD Connect if you want to use password
writeback.
DirSync and Azure AD Sync are no longer supported as a way to enable password writeback. For more
information to help with your transition, see Upgrade from DirSync and Azure AD Sync.
The following steps assume you have already configured Azure AD Connect in your environment by using the
Express or Custom settings.
1. To configure and enable password writeback, sign in to your Azure AD Connect server and start the Azure
AD Connect configuration wizard.
2. On the Welcome page, select Configure.
3. On the Additional tasks page, select Customize synchronization options, and then select Next.
4. On the Connect to Azure AD page, enter a global administrator credential, and then select Next.
5. On the Connect directories and Domain/OU filtering pages, select Next.
6. On the Optional features page, select the box next to Password writeback and select Next.
7. On the Ready to configure page, select Configure and wait for the process to finish.
8. When you see the configuration finish, select Exit.
For common troubleshooting tasks related to password writeback, see the section Troubleshoot password
writeback in our troubleshooting article.
Active Directory permissions

The account specified in the Azure AD Connect utility must have the following items set if you want to be in
scope for SSPR:
Reset password
Change password
Write permissions on lockoutTime
Write permissions on pwdLastSet
Extended rights on either:
The root object of each domain in that forest
The user organizational units (OUs) you want to be in scope for SSPR
If you're not sure what account the described account refers to, open the Azure Active Directory Connect
configuration UI and select the View current configuration option. The account that you need to add
permission to is listed under Synchronized Directories.
If you set these permissions, the MA service account for each forest can manage passwords on behalf of the user
accounts within that forest.
IMPORTANT
If you neglect to assign these permissions, then, even though writeback appears to be configured correctly, users will
encounter errors when they attempt to manage their on-premises passwords from the cloud.
NOTE
It might take up to an hour or more for these permissions to replicate to all the objects in your directory.
To set up the appropriate permissions for password writeback to occur, complete the following steps:
1. Open Active Directory Users and Computers with an account that has the appropriate domain administration
permissions.
2. From the View menu, make sure Advanced features is turned on.
3. In the left panel, right-click the object that represents the root of the domain and select Properties >
Security > Advanced.
4. From the Permissions tab, select Add.
5. Pick the account that permissions are being applied to (from the Azure AD Connect setup).
6. In the Applies to drop-down list, select Descendent user objects.
7. Under Permissions, select the boxes for the following:
Reset password
Change password
Write lockoutTime
Write pwdLastSet
8. Select Apply/OK to apply the changes and exit any open dialog boxes.
Licensing requirements for password writeback

For information about licensing, see Licenses required for password writeback or the following sites:
Azure Active Directory pricing site
Microsoft 365 Enterprise
On-premises authentication modes that are supported for password writeback
Password writeback support for the following user password types:
Cloud-only users: Password writeback does not apply in this situation, because there is no on-premises
password.
Password-synchronized users: Password writeback is supported.
Federated users: Password writeback is supported.
Pass-through Authentication users: Password writeback is supported.
User and admin operations that are supported for password writeback
Passwords are written back in all the following situations:
Supported end-user operations
Any end-user self-service voluntary change password operation
Any end-user self-service force change password operation, for example, password expiration
Any end-user self-service password reset that originates from the password reset portal
Supported administrator operations
Any administrator self-service voluntary change password operation
Any administrator self-service force change password operation, for example, password expiration
Any administrator self-service password reset that originates from the password reset portal
Any administrator-initiated end-user password reset from the Azure portal
User and admin operations that are not supported for password writeback
Passwords are not written back in any of the following situations:
Unsupported end-user operations
Any end user resetting their own password by using PowerShell version 1, version 2, or the Azure AD
Graph API
Unsupported administrator operations
Any administrator-initiated end-user password reset from the Office management portal
Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the
Azure AD Graph API
We are working to remove these limitations, but we don't have a specific timeline we can share yet.
Password writeback security model

Password writeback is a highly secure service. To ensure your information is protected, we enable a four-tiered
security model that's described as follows:
Tenant-specific service-bus relay
When you set up the service, we set up a tenant-specific service bus relay that's protected by a
randomly generated strong password that Microsoft never has access to.
Locked down, cryptographically strong, password encryption key
After the service bus relay is created, we create a strong symmetric key that we use to encrypt the
password as it comes over the wire. This key only lives in your company's secret store in the cloud,
which is heavily locked down and audited, just like any other password in the directory.
Industry standard Transport Layer Security (TLS)
1. When a password reset or change operation occurs in the cloud, we take the plaintext password and
encrypt it with your public key.
2. We place that into an HTTPS message that is sent over an encrypted channel by using Microsoft SSL
certs to your service bus relay.
3. After the message arrives in the service bus, your on-premises agent wakes up and authenticates to
the service bus by using the strong password that was previously generated.
4. The on-premises agent picks up the encrypted message and decrypts it by using the private key we
generated.
5. The on-premises agent attempts to set the password through the AD DS SetPassword API. This step is
what allows us to enforce your Active Directory on-premises password policy (such as the complexity,
age, history, and filters) in the cloud.
Message expiration policies
If the message sits in service bus because your on-premises service is down, it times out and is
removed after several minutes. The time-out and removal of the message increases security even
further.
Password writeback encryption details
After a user submits a password reset, the reset request goes through several encryption steps before it arrives
in your on-premises environment. These encryption steps ensure maximum service reliability and security. They
are described as follows:
Step 1: Password encryption with 2048-bit RSA Key: After a user submits a password to be written back
to on-premises, the submitted password itself is encrypted with a 2048-bit RSA key.
Step 2: Package-level encryption with AES-GCM: The entire package, the password plus the required
metadata, is encrypted by using AES-GCM. This encryption prevents anyone with direct access to the
underlying ServiceBus channel from viewing or tampering with the contents.
Step 3: All communication occurs over TLS/SSL: All the communication with ServiceBus happens in an
SSL/TLS channel. This encryption secures the contents from unauthorized third parties.
Automatic key rollover every six months: Every six months, or every time password writeback is disabled
and then re-enabled on Azure AD Connect. We automatically roll over all keys to ensure maximum service
security and safety.
Password writeback bandwidth usage
Password writeback is a low-bandwidth service that only sends requests back to the on-premises agent under
the following circumstances:
Two messages are sent when the feature is enabled or disabled through Azure AD Connect.
One message is sent once every five minutes as a service heartbeat for as long as the service is running.
Two messages are sent each time a new password is submitted:
The first message is a request to perform the operation.
The second message contains the result of the operation, and is sent in the following circumstances:
Each time a new password is submitted during a user self-service password reset.
Each time a new password is submitted during a user password change operation.
Each time a new password is submitted during an admin-initiated user password reset (only
from the Azure admin portals).
Message size and bandwidth considerations
The size of each of the message described previously is typically under 1 KB. Even under extreme loads, the
password writeback service itself is consuming a few kilobits per second of bandwidth. Because each message is
sent in real time, only when required by a password update operation, and because the message size is so small,
the bandwidth usage of the writeback capability is too small to have a measurable impact.
Next steps
Troubleshoot self-service password reset
Are you having a problem with Azure Active Directory (Azure AD) self-service password reset (SSPR)? The
information that follows can help you to get things working again.
Troubleshoot self-service password reset errors that a user might see

ERROR DETAILS TECHNICAL DETAILS
TenantSSPRFlagDisabled = 9 We’re sorry, you can't reset your SSPR_0009: We've detected that
password at this time because your password reset has not been enabled
administrator has disabled password by your administrator. Please contact
reset for your organization. There is no your admin and ask them to enable
further action you can take to resolve password reset for your organization.
this situation. Please contact your
admin and ask them to enable this
feature. To learn more, see Help, I
forgot my Azure AD password.
WritebackNotEnabled = 10 We’re sorry, you can't reset your SSPR_0010: We've detected that
password at this time because your password writeback has not been
administrator has not enabled a enabled. Please contact your admin
necessary service for your organization. and ask them to enable password
There is no further action you can take writeback.
to resolve this situation. Please contact
your admin and ask them to check
your organization’s configuration. To
learn more about this necessary
service, see Configuring password
writeback.
SsprNotEnabledInUserPolicy = 11 We’re sorry, you can't reset your SSPR_0011: Your organization has not
password at this time because your defined a password reset policy. Please
administrator has not configured contact your admin and ask them to
password reset for your organization. define a password reset policy.
There is no further action you can take
to resolve this situation. Contact your
admin and ask them to configure
password reset. To learn more about
password reset configuration, see
Quick start: Azure AD self-service
password reset.
UserNotLicensed = 12 We’re sorry, you can't reset your SSPR_0012: Your organization does
password at this time because required not have the required licenses
licenses are missing from your necessary to perform password reset.
organization. There is no further action Please contact your admin and ask
you can take to resolve this situation. them to review the license
Please contact your admin and ask assignments.
them to check your license assignment.
To learn more about licensing, see
Licensing requirements for Azure AD
self-service password reset.
ERROR DETAILS TECHNICAL DETAILS
UserNotMemberOfScopedAccessGrou We’re sorry, you can't reset your SSPR_0012: You are not a member of a
p = 13 password at this time because your group enabled for password reset.
administrator has not configured your Contact your admin and request to be
account to use password reset. There is added to the group.
no further action you can take to
resolve this situation. Please contact
your admin and ask them to configure
your account for password reset. To
learn more about account
configuration for password reset, see
Roll out password reset for users.
UserNotProperlyConfigured = 14 We’re sorry, you can't reset your SSPR_0014: Additional security info is
password at this time because needed to reset your password. To
necessary information is missing from proceed, contact your admin and ask
your account. There is no further them to reset your password. After you
action you can take to resolve this have access to your account, you can
situation. Please contact you admin register additional security info at
and ask them to reset your password https://aka.ms/ssprsetup. Your admin
for you. After you have access to your can add additional security info to your
account again, you need to register the account by following the steps in Set
necessary information. To register and read authentication data for
information, follow the steps in the password reset.
article.
OnPremisesAdminActionRequired = 29 We’re sorry, we can't reset your SSPR_0029: We are unable to reset
password at this time because of a your password due to an error in your
problem with your organization’s on-premises configuration. Please
password reset configuration. There is contact your admin and ask them to
no further action you can take to investigate.
resolve this situation. Please contact
your admin and ask them to
investigate. To learn more about the
potential problem, see Troubleshoot
password writeback.
OnPremisesConnectivityError = 30 We’re sorry, we can't reset your SSPR_0030: We can't reset your
password at this time because of password due to a poor connection
connectivity issues to your with your on-premises environment.
organization. There is no action to take Contact your admin and ask them to
right now, but the problem might be investigate.
resolved if you try again later. If the
problem persists, please contact your
admin and ask them to investigate. To
learn more about connectivity issues,
see Troubleshoot password writeback
connectivity.
Troubleshoot the password reset configuration in the Azure portal

ERROR SOLUTION
ERROR SOLUTION
I don't see the Password reset section under Azure AD in This can happen if you don't have an Azure AD Premium or
the Azure portal. Basic license assigned to the administrator performing the
operation.
Assign a license to the administrator account in question.

You can follow the steps in the Assign, verify, and resolve
problems with licenses article.
I don't see a particular configuration option. Many elements of the UI are hidden until they are needed.
Try enabling all the options you want to see.
I don't see the On-premises integration tab. This option only becomes visible if you have downloaded
Azure AD Connect and have configured password writeback.
For more information, see Getting started with Azure AD
Connect by using the express settings.
Troubleshoot password reset reporting

ERROR SOLUTION
I don’t see any password management activity types in the This can happen if you don't have an Azure AD Premium or
Self-Service Password Management audit event category. Basic license assigned to the administrator performing the
operation.
You can resolve this problem by assigning a license to the

administrator account in question. Follow the steps in the
Assign, verify, and resolve problems with licenses article.
User registrations show multiple times. Currently, when a user registers, we log each individual piece
of data that's registered as a separate event.
If you want to aggregate this data and have greater flexibility

in how you can view it, you can download the report and
open the data as a pivot table in Excel.
Troubleshoot the password reset registration portal

ERROR SOLUTION
The directory is not enabled for password reset. Your Switch the Self-service password reset enabled flag to
administrator has not enabled you to use this feature. Selected or All and then select Save.
The user does not have an Azure AD Premium or Basic This can happen if you don't have an Azure AD Premium or
license assigned. Your administrator has not enabled you Basic license assigned to the administrator performing the
to use this feature. operation.
You can resolve this problem by assigning a license to the

There is an error processing the request. This can be caused by many issues, but generally this error is
caused by either a service outage or a configuration issue. If
you see this error and it affects your business, contact
Microsoft support for additional assistance.
Troubleshoot the password reset portal
ERROR SOLUTION
The directory is not enabled for password reset. Switch the Self-service password reset enabled flag to
Selected or All and then select Save.
The user does not have an Azure AD Premium or Basic This can happen if you don't have an Azure AD Premium or
license assigned. Basic license assigned to the administrator performing the
operation.
You can resolve this problem if you assign a license to the

The directory is enabled for password reset, but the user has Before proceeding, ensure that user has properly formed
missing or malformed authentication information. contact data on file in the directory. For more information,
see Data used by Azure AD self-service password reset.
The directory is enabled for password reset, but the user has Before proceeding, ensure that the user has at least two
only one piece of contact data on file when the policy is set properly configured contact methods. An example is having
to require two verification methods. both a mobile phone number and an office phone number.
The directory is enabled for password reset and the user is This can be the result of a temporary service error or if there
properly configured, but the user is unable to be contacted. is incorrect contact data that we can't properly detect.
If the user waits 10 seconds, "try again" and "contact your

administrator” links appear. If the user selects "try again," it
retries the call. If the user selects “contact your
administrator,” it sends a form email to their administrators
requesting a password reset to be performed for that user
account.
The user never receives the password reset SMS or phone This can be the result of a malformed phone number in the
call. directory. Make sure the phone number is in the format
“+ccc xxxyyyzzzzXeeee”.
Password reset does not support extensions, even if you

specify one in the directory. The extensions are stripped
before the call is dispatched. Use a number without an
extension or integrate the extension into the phone number
in your private branch exchange (PBX).
The user never receives the password reset email. The most common cause for this problem is that the
message is rejected by a spam filter. Check your spam, junk,
or deleted items folder for the email.
Also ensure that you're checking the correct email account

for the message.
I have set a password reset policy, but when an admin Microsoft manages and controls the administrator password
account uses password reset, that policy isn't applied. reset policy to ensure the highest level of security.
ERROR SOLUTION
The user is prevented from attempting a password reset too We implement an automatic throttling mechanism to block
many times in a day. users from attempting to reset their passwords too many
times in a short period of time. Throttling occurs when:
The user attempts to validate a phone number 5
times in one hour.
The user attempts to use the security questions gate
5 times in one hour.
The user attempts to reset a password for the same
user account 5 times in one hour.
To fix this problem, instruct the user to wait 24 hours after
the last attempt. The user can then reset their password.
The user sees an error when validating their phone number. This error occurs when the phone number entered does not
match the phone number on file. Make sure the user is
entering the complete phone number, including the area and
country code, when they attempt to use a phone-based
method for password reset.
There is an error processing the request. This can be caused by many issues, but generally this error is
caused by either a service outage or a configuration issue. If
you see this error and it affects your business, contact
Microsoft support for additional assistance.
Troubleshoot password writeback

ERROR SOLUTION
The password reset service does not start on-premises. Error When password writeback is enabled, the sync engine calls
6800 appears in the Azure AD Connect machine’s application the writeback library to perform the configuration
event log. (onboarding) by communicating to the cloud onboarding
service. Any errors encountered during onboarding or while
After onboarding, federated or password-hash-synchronized starting the Windows Communication Foundation (WCF)
users can't reset their passwords. endpoint for password writeback results in errors in the
event log in your Azure AD Connect machine.
During restart of the Azure AD Sync (ADSync) service, if

writeback was configured, the WCF endpoint starts up. But, if
the startup of the endpoint fails, we will log event 6800 and
let the sync service start up. The presence of this event
means that the password writeback endpoint did not start
up. Event log details for this event 6800, along with event
log entries generate by the PasswordResetService
component, indicate why you can't start up the endpoint.
Review these event log errors and try to restart the Azure AD
Connect if password writeback still isn’t working. If the
problem persists, try to disable and then re-enable password
writeback.
When a user attempts to reset a password or unlock an Find the Active Directory account for Azure AD Connect and
account with password writeback enabled, the operation fails. reset the password so that it contains no more than 127
characters. Then open the Synchronization Service from
In addition, you see an event in the Azure AD Connect event the Start menu. Browse to Connectors and find the Active
log that contains: “Synchronization Engine returned an error Directory Connector. Select it and then select Properties.
hr=800700CE, message=The filename or extension is too Browse to the Credentials page and enter the new
long” after the unlock operation occurs. password. Select OK to close the page.
ERROR SOLUTION
At the last step of the Azure AD Connect installation process, This error occurs in the following two cases:
you see an error indicating that password writeback couldn't You have specified an incorrect password for the
be configured. global administrator account specified at the
beginning of the Azure AD Connect installation
The Azure AD Connect application event log contains error process.
32009 with the text “Error getting auth token.” You have attempted to use a federated user for the
global administrator account specified at the
beginning of the Azure AD Connect installation
process.
To fix this problem, ensure that you're not using a federated
account for the global administrator you specified at the
beginning of the installation process. Also ensure that the
password specified is correct.
The Azure AD Connect machine event log contains error Your on-premises environment isn't able to connect to the
32002 that is thrown by running PasswordResetService. Azure Service Bus endpoint in the cloud. This error is
normally caused by a firewall rule blocking an outbound
The error reads: “Error Connecting to ServiceBus. The token connection to a particular port or web address. See
provider was unable to provide a security token.” Connectivity prerequisites for more info. After you have
updated these rules, reboot the Azure AD Connect machine
and password writeback should start working again.
After working for some time, federated or password-hash- In some rare cases, the password writeback service can fail to
synchronized users can't reset their passwords. restart when Azure AD Connect has restarted. In these cases,
first, check whether password writeback appears to be
enabled on-premises. You can check by using either the
Azure AD Connect wizard or PowerShell (See the previous
HowTos section). If the feature appears to be enabled, try
enabling or disabling the feature again either through the UI
or PowerShell. If this doesn’t work, try a complete uninstall
and reinstall of Azure AD Connect.
Federated or password-hash-synchronized users who If you see these errors in your event log, confirm that the
attempt to reset their passwords see an error after Active Directory Management Agent (ADMA) account that
attempting to submit their password. The error indicates that was specified in the wizard at the time of configuration has
there was a service problem. the necessary permissions for password writeback.
In addition to this problem, during password reset Note that after this permission is given, it can take up to one
operations, you might see an error that the management hour for the permissions to trickle down via the sdprop
agent was denied access in your on-premises event logs. background task on the domain controller (DC).
For password reset to work, the permission needs to be

stamped on the security descriptor of the user object whose
password is being reset. Until this permission shows up on
the user object, password reset continues to fail with an
access denied message.
ERROR SOLUTION
Federated or password-hash-synchronized users who This error usually indicates that the sync engine is unable to
attempt to reset their passwords, see an error after they find either the user object in the Azure AD connector space
submit their password. The error indicates that there was a or the linked metaverse (MV) or Azure AD connector space
service problem. object.
In addition to this problem, during password reset To troubleshoot this problem, make sure that the user is
operations, you might see an error in your event logs from indeed synchronized from on-premises to Azure AD via the
the Azure AD Connect service indicating an “Object could current instance of Azure AD Connect and inspect the state
not be found” error. of the objects in the connector spaces and MV. Confirm that
the Active Directory Certificate Services (AD CS) object is
connected to the MV object via the
“Microsoft.InfromADUserAccountEnabled.xxx” rule.
Federated or password-hash-synchronized users who This indicates that the sync engine detected that the MV
attempt to reset their passwords see an error after they object is connected to more than one AD CS object via
submit their password. The error indicates that there was a “Microsoft.InfromADUserAccountEnabled.xxx”. This means
service problem. that the user has an enabled account in more than one
forest. Note that this scenario isn't supported for password
In addition to this problem, during password reset writeback.
operations, you might see an error in your event logs from
the Azure AD Connect service that indicates that there is a
“Multiple matches found” error.
Password operations fail with a configuration error. The This error occurs if the Azure AD Connect configuration is
application event log contains Azure AD Connect error 6329 changed to add a new Active Directory forest (or to remove
with the text "0x8023061f (The operation failed because and re-add an existing forest) after the password writeback
password synchronization is not enabled on this feature has already been enabled. Password operations for
Management Agent)". users in these recently added forests fail. To fix the problem,
disable and then re-enable the password writeback feature
after the forest configuration changes have been completed.
Password writeback event-log error codes

A best practice when you troubleshoot problems with password writeback is to inspect the application event log
on your Azure AD Connect machine. This event log contains events from two sources of interest for password
writeback. The PasswordResetService source describes operations and problems related to the operation of
password writeback. The ADSync source describes operations and problems related to setting passwords in your
Active Directory environment.
If the source of the event is ADSync
CODE NAME OR MESSAGE DESCRIPTION
6329 BAIL: MMS(4924) 0x80230619: “A This event occurs when the password
restriction prevents the password from writeback service attempts to set a
being changed to the current one password on your local directory that
specified.” does not meet the password age,
history, complexity, or filtering
requirements of the domain.
If you have a minimum password age

and have recently changed the
password within that window of time,
you're not able to change the
password again until it reaches the
specified age in your domain. For
testing purposes, the minimum age
should be set to 0.
If you have password history

requirements enabled, then you must
select a password that has not been
used in the last N times, where N is the
password history setting. If you do
select a password that has been used
in the last N times, then you see a
failure in this case. For testing
purposes, the password history should
be set to 0.
If you have password complexity

requirements, all of them are enforced
when the user attempts to change or
reset a password.
If you have password filters enabled

and a user selects a password that
does not meet the filtering criteria,
then the reset or change operation
fails.
6329 MMS(3040): admaexport.cpp(2837): This problem occurs if

The server does not contain the LDAP LDAP_SERVER_POLICY_HINTS_OID
password policy control. control (1.2.840.113556.1.4.2066) isn't
enabled on the DCs. To use the
password writeback feature, you must
enable the control. To do so, the DCs
must be on Windows Server 2008
(with the latest SP) or later. If your DCs
are on 2008 (pre-R2), then you must
also apply hotfix KB2386717.
HR 8023042 Synchronization Engine returned an This error occurs when the same user
error hr=80230402, message=An ID is enabled in multiple domains. An
attempt to get an object failed because example is if you're syncing account
there are duplicated entries with the and resource forests and have the
same anchor. same user ID present and enabled in
each forest.
This error can also occur if you use a

non-unique anchor attribute, like an
alias or UPN, and two users share that
same anchor attribute.
To resolve this problem, ensure that

you don't have any duplicated users
within your domains and that you use
a unique anchor attribute for each
user.
If the source of the event is PasswordResetService

31001 PasswordResetStart This event indicates that the on-

premises service detected a password
reset request for a federated or
password-hash-synchronized user that
originates from the cloud. This event is
the first event in every password-reset
writeback operation.
31002 PasswordResetSuccess This event indicates that a user

selected a new password during a
password-reset operation. We
determined that this password meets
corporate password requirements. The
password has been successfully written
back to the local Active Directory
environment.
31003 PasswordResetFail This event indicates that a user

selected a password and the password
arrived successfully to the on-premises
environment. But when we attempted
to set the password in the local Active
Directory environment, a failure
occurred. This failure can happen for
several reasons:
The user’s password does not
meet the age, history,
complexity, or filter
requirements for the domain.
To resolve this problem, create
a new password.
The ADMA service account
does not have the appropriate
permissions to set the new
password on the user account
in question.
The user’s account is in a
protected group, such as
domain or enterprise admin
group, which disallows
password set operations.
31004 OnboardingEventStart This event occurs if you enable

password writeback with Azure AD
Connect and we have started
onboarding your organization to the
password writeback web service.
31005 OnboardingEventSuccess This event indicates that the

onboarding process was successful and
that the password writeback capability
is ready to use.
31006 ChangePasswordStart This event indicates that the on-

premises service detected a password
change request for a federated or
password-hash-synchronized user that
originates from the cloud. This event is
the first event in every password-
change writeback operation.
31007 ChangePasswordSuccess This event indicates that a user

selected a new password during a
password change operation, we
determined that the password meets
corporate password requirements, and
that the password has been
successfully written back to the local
Active Directory environment.
31008 ChangePasswordFail This event indicates that a user

selected a password and that the
password arrived successfully to the
on-premises environment, but when
we attempted to set the password in
the local Active Directory environment,
a failure occurred. This failure can
happen for several reasons:
To resolve this problem, create
a new password.
in question.
domain or enterprise admins,
which disallows password set
operations.
31009 ResetUserPasswordByAdminStart The on-premises service detected a

password reset request for a federated
or password-hash-synchronized user
originating from the administrator on
behalf of a user. This event is the first
event in every password-reset
writeback operation that is initiated by
an administrator.
31010 ResetUserPasswordByAdminSuccess The admin selected a new password

during an admin-initiated password-
reset operation. We determined that
this password meets corporate
password requirements. The password
has been successfully written back to
the local Active Directory environment.
31011 ResetUserPasswordByAdminFail The admin selected a password on

behalf of a user. The password arrived
successfully to the on-premises
environment. But when we attempted
to set the password in the local Active
Directory environment, a failure
occurred. This failure can happen for
several reasons:
Try a new password to resolve
this problem.
in question.
domain or enterprise admins,
which disallows password set
operations.
31012 OffboardingEventStart This event occurs if you disable

password writeback with Azure AD
Connect and indicates that we started
offboarding your organization to the
password writeback web service.
31013 OffboardingEventSuccess This event indicates that the

offboarding process was successful and
that password writeback capability has
been successfully disabled.
31014 OffboardingEventFail This event indicates that the

offboarding process was not successful.
This might be due to a permissions
error on the cloud or on-premises
administrator account specified during
configuration. The error can also occur
if you're attempting to use a federated
cloud global administrator when
disabling password writeback. To fix
this problem, check your administrative
permissions and ensure that you're not
using a federated account while
configuring the password writeback
capability.
31015 WriteBackServiceStarted This event indicates that the password

writeback service has started
successfully. It is ready to accept
password management requests from
the cloud.
31016 WriteBackServiceStopped This event indicates that the password

writeback service has stopped. Any
password management requests from
the cloud will not be successful.
31017 AuthTokenSuccess This event indicates that we

successfully retrieved an authorization
token for the global admin specified
during Azure AD Connect setup to
start the offboarding or onboarding
process.
31018 KeyPairCreationSuccess This event indicates that we

successfully created the password
encryption key. This key is used to
encrypt passwords from the cloud to
be sent to your on-premises
environment.
32000 UnknownError This event indicates an unknown error

occurred during a password
management operation. Look at the
exception text in the event for more
details. If you're having problems, try
disabling and then re-enabling
password writeback. If this does not
help, include a copy of your event log
along with the tracking ID specified
insider to your support engineer.
32001 ServiceError This event indicates there was an error

connecting to the cloud password reset
service. This error generally occurs
when the on-premises service was
unable to connect to the password-
reset web service.
32002 ServiceBusError This event indicates there was an error

connecting to your tenant’s Service Bus
instance. This can happen if you're
blocking outbound connections in your
on-premises environment. Check your
firewall to ensure that you allow
connections over TCP 443 and to
https://ssprsbprodncu-
sb.accesscontrol.windows.net/, and
then try again. If you're still having
problems, try disabling and then re-
enabling password writeback.
32003 InPutValidationError This event indicates that the input

passed to our web service API was
invalid. Try the operation again.
32004 DecryptionError This event indicates that there was an

error decrypting the password that
arrived from the cloud. This might be
due to a decryption key mismatch
between the cloud service and your
on-premises environment. To resolve
this problem, disable and then re-
enable password writeback in your on-
premises environment.
32005 ConfigurationError During onboarding, we save tenant-

specific information in a configuration
file in your on-premises environment.
This event indicates that there was an
error saving this file or that when the
service was started, there was an error
reading the file. To fix this problem, try
password writeback to force a rewrite
of the configuration file.
32007 OnBoardingConfigUpdateError During onboarding, we send data from

the cloud to the on-premises
password-reset service. That data is
then written to an in-memory file
before it is sent to the sync service to
be stored securely on disk. This event
indicates that there is a problem with
writing or updating that data in
memory. To fix this problem, try
password writeback to force a rewrite
of this configuration file.
32008 ValidationError This event indicates we received an

invalid response from the password-
reset web service. To fix this problem,
try disabling and then re-enabling
password writeback.
32009 AuthTokenError This event indicates that we couldn't

get an authorization token for the
global administrator account specified
during Azure AD Connect setup. This
error can be caused by a bad username
or password specified for the global
admin account. This error can also
occur if the global admin account
specified is federated. To fix this
problem, rerun the configuration with
the correct username and password
and ensure that the administrator is a
managed (cloud-only or password-
synchronized) account.
32010 CryptoError This event indicates there was an error

generating the password encryption
key or decrypting a password that
arrives from the cloud service. This
error likely indicates a problem with
your environment. Look at the details
of your event log to learn more about
how to resolve this problem. You can
also try disabling and then re-enabling
the password writeback service.
32011 OnBoardingServiceError This event indicates that the on-

premises service couldn't properly
communicate with the password-reset
web service to initiate the onboarding
process. This can happen as a result of
a firewall rule or if there is a problem
getting an authentication token for
your tenant. To fix this problem, ensure
that you're not blocking outbound
connections over TCP 443 and TCP
9350-9354 or to
sb.accesscontrol.windows.net/. Also
ensure that the Azure AD admin
account you're using to onboard isn't
federated.
32013 OffBoardingError This event indicates that the on-

premises service couldn't properly
communicate with the password-reset
web service to initiate the offboarding
process. This can happen as a result of
a firewall rule or if there is a problem
getting an authorization token for your
tenant. To fix this problem, ensure that
you're not blocking outbound
connections over 443 or to
sb.accesscontrol.windows.net/, and that
the Azure Active Directory admin
account you're using to offboard isn't
federated.
32014 ServiceBusWarning This event indicates that we had to

retry to connect to your tenant’s
Service Bus instance. Under normal
conditions, this should not be a
concern, but if you see this event many
times, consider checking your network
connection to Service Bus, especially if
it’s a high-latency or low-bandwidth
connection.
32015 ReportServiceHealthError In order to monitor the health of your

password writeback service, we send
heartbeat data to our password-reset
web service every five minutes. This
event indicates that there was an error
when sending this health information
back to the cloud web service. This
health information does not include an
object identifiable information (OII) or
personally identifiable information (PII)
data, and is purely a heartbeat and
basic service statistics so that we can
provide service status information in
the cloud.
33001 ADUnKnownError This event indicates that there was an

unknown error returned by Active
Directory. Check the Azure AD Connect
server event log for events from the
ADSync source for more information.
33002 ADUserNotFoundError This event indicates that the user who

is trying to reset or change a password
was not found in the on-premises
directory. This error can occur when
the user has been deleted on-premises
but not in the cloud. This error can also
occur if there is a problem with sync.
Check your sync logs and the last few
sync run details for more information.
33003 ADMutliMatchError When a password reset or change

request originates from the cloud, we
use the cloud anchor specified during
the setup process of Azure AD Connect
to determine how to link that request
back to a user in your on-premises
environment. This event indicates that
we found two users in your on-
premises directory with the same cloud
anchor attribute. Check your sync logs
and the last few sync run details for
more information.
33004 ADPermissionsError This event indicates that the Active

Directory Management Agent (ADMA)
service account does not have the
appropriate permissions on the
account in question to set a new
password. Ensure that the ADMA
account in the user’s forest has reset
and change password permissions on
all objects in the forest. For more
information on how to set the
permissions, see Step 4: Set up the
appropriate Active Directory
permissions.
33005 ADUserAccountDisabled This event indicates that we attempted

to reset or change a password for an
account that was disabled on-premises.
Enable the account and try the
operation again.
33006 ADUserAccountLockedOut This event indicates that we attempted

to reset or change a password for an
account that was locked out on-
premises. Lockouts can occur when a
user has tried a change or reset
password operation too many times in
a short period. Unlock the account and
try the operation again.
33007 ADUserIncorrectPassword This event indicates that the user

specified an incorrect current password
when performing a password change
operation. Specify the correct current
password and try again.
33008 ADPasswordPolicyError This event occurs when the password

writeback service attempts to set a
password on your local directory that
does not meet the password age,
history, complexity, or filtering
requirements of the domain.
If you have a minimum password age

and have recently changed the
password within that window of time,
you're not able to change the
password again until it reaches the
specified age in your domain. For
testing purposes, the minimum age
should be set to 0.
If you have password history

requirements enabled, then you must
select a password that has not been
used in the last N times, where N is the
password history setting. If you do
select a password that has been used
in the last N times, then you see a
failure in this case. For testing
purposes, the password history should
be set to 0.
If you have password complexity

requirements, all of them are enforced
when the user attempts to change or
reset a password.
If you have password filters enabled

and a user selects a password that
does not meet the filtering criteria,
then the reset or change operation
fails.
33009 ADConfigurationError This event indicates there was a

problem writing a password back to
your on-premises directory because of
a configuration issue with Active
Directory. Check the Azure AD Connect
machine’s application event log for
messages from the ADSync service for
more information on which error
occurred.
Troubleshoot password writeback connectivity

If you're experiencing service interruptions with the password writeback component of Azure AD Connect, here
are some quick steps you can take to resolve this problem:
Confirm network connectivity
Restart the Azure AD Connect Sync service
Disable and re-enable the password writeback feature
Install the latest Azure AD Connect release
Troubleshoot password writeback
In general, to recover your service in the most rapid manner, we recommend that you execute these steps in the
order discussed previously.
Confirm network connectivity
The most common point of failure is that firewall and or proxy ports and idle timeouts are incorrectly configured.
For Azure AD Connect version 1.1.443.0 and above, you need outbound HTTPS access to the following:
passwordreset.microsoftonline.com
servicebus.windows.net
For more granularity, reference the updated list of Microsoft Azure Datacenter IP Ranges updated every
Wednesday and put into effect the following Monday.
For more information, review the connectivity prerequisites in the Prerequisites for Azure AD Connect article.
Restart the Azure AD Connect Sync service
To resolve connectivity problems or other transient problems with the service, restart the Azure AD Connect Sync
service:
1. As an administrator, select Start on the server running Azure AD Connect.
2. Enter services.msc in the search field and select Enter.
3. Look for the Microsoft Azure AD Sync entry.
4. Right-click the service entry, select Restart, and then wait for the operation to finish.
These steps re-establish your connection with the cloud service and resolve any interruptions you might be
experiencing. If restarting the ADSync service does not resolve your problem, we recommend that you try to
disable and then re-enable the password writeback feature.
Disable and re -enable the password writeback feature
To resolve connectivity issues, disable and then re-enable the password writeback feature:
1. As an administrator, open the Azure AD Connect Configuration wizard.
2. In Connect to Azure AD, enter your Azure AD global admin credentials.
3. In Connect to AD DS, enter your AD Domain Services admin credentials.
4. In Uniquely identifying your users, select the Next button.
5. In Optional features, clear the Password writeback check box.
6. Select Next through the remaining dialog pages without changing anything until you get to the Ready to
configure page.
7. Ensure that the Ready to configure page shows the Password writeback option as disabled and then
select the green Configure button to commit your changes.
8. In Finished, clear the Synchronize now option, and then select Finish to close the wizard.
9. Reopen the Azure AD Connect Configuration wizard.
10. Repeat steps 2-8, except ensure you select the Password writeback option on the Optional features page
to re-enable the service.
These steps re-establish your connection with our cloud service and resolve any interruptions you might be
experiencing.
If disabling and then re-enabling the password writeback feature does not resolve your problem, we recommend
that you reinstall Azure AD Connect.
Install the latest Azure AD Connect release
Reinstalling Azure AD Connect can resolve configuration and connectivity issues between our cloud services and
your local Active Directory environment.
We recommend that you perform this step only after you attempt the first two steps previously described.
WARNING
If you have customized the out-of-the-box sync rules, back them up before proceeding with upgrade and then manually
redeploy them after you're finished.
1. Download the latest version of Azure AD Connect from the Microsoft Download Center.
2. Because you have already installed Azure AD Connect, you need to perform an in-place upgrade to update
your Azure AD Connect installation to the latest version.
3. Execute the downloaded package and follow the on-screen instructions to update your Azure AD Connect
machine.
The previous steps should re-establish your connection with our cloud service and resolve any interruptions you
might be experiencing.
If installing the latest version of the Azure AD Connect server does not resolve your problem, we recommend
that you try disabling and then re-enabling password writeback as a final step after you install the latest release.
Verify that Azure AD Connect has the required permission for

password writeback
Azure AD Connect requires Active Directory Reset password permission to perform password writeback. To find
out if Azure AD Connect has the required permission for a given on-premises Active Directory user account, you
can use the Windows Effective Permission feature:
1. Sign in to the Azure AD Connect server and start the Synchronization Service Manager by selecting Start
> Synchronization Service.
2. Under the Connectors tab, select the on-premises Active Directory Domain Services connector, and
then select Properties.
3. In the pop-up window, select Connect to Active Directory Forest and make note of the User name
property. This property is the AD DS account used by Azure AD Connect to perform directory
synchronization. For Azure AD Connect to perform password writeback, the AD DS account must have
reset password permission.
4. Sign in to an on-premises domain controller and start the Active Directory Users and Computers
application.
5. Select View and make sure the Advanced Features option is enabled.
6. Look for the Active Directory user account you want to verify. Right-click the account name and select
Properties.
7. In the pop-up window, go to the Security tab and select Advanced.
8. In the Advanced Security Settings for Administrator pop-up window, go to the Effective Access tab.
9. Select Select a user, select the AD DS account used by Azure AD Connect (see step 3), and then select
View effective access.
10. Scroll down and look for Reset password. If the entry has a check mark, the AD DS account has
permission to reset the password of the selected Active Directory user account.
Azure AD forums
If you have a general question about Azure AD and self-service password reset, you can ask the community for
assistance on the Azure AD forums. Members of the community include engineers, product managers, MVPs,
and fellow IT professionals.
Contact Microsoft support

If you can't find the answer to a problem, our support teams are always available to assist you further.
To properly assist you, we ask that you provide as much detail as possible when opening a case. These details
include:
General description of the error: What is the error? What was the behavior that was noticed? How can we
reproduce the error? Provide as much detail as possible.
Page: What page were you on when you noticed the error? Include the URL if you're able to and a screenshot
of the page.
Support code: What was the support code that was generated when the user saw the error?
To find this code, reproduce the error, then select the Support code link at the bottom of the
screen and send the support engineer the GUID that results.
If you're on a page without a support code at the bottom, select F12 and search for the SID and CID
and send those two results to the support engineer.
Date, time, and time zone: Include the precise date and time with the time zone that the error occurred.
User ID: Who was the user who saw the error? An example is user@contoso.com.
Is this a federated user?
Is this a password-hash-synchronized user?
Is this a cloud-only user?
Licensing: Does the user have an Azure AD Premium or Azure AD Basic license assigned?
Application event log: If you're using password writeback and the error is in your on-premises
infrastructure, include a zipped copy of your application event log from the Azure AD Connect server.
Next steps
The following articles provide additional information about password reset through Azure AD:
Password management frequently asked questions
The following are some frequently asked questions (FAQ) for all things related to password reset.
If you have a general question about Azure Active Directory (Azure AD) and self-service password reset (SSPR)
that's not answered here, you can ask the community for assistance on the Azure AD forum. Members of the
community include engineers, product managers, MVPs, and fellow IT professionals.
This FAQ is split into the following sections:
Questions about password reset registration
Questions about password reset
Questions about password change
Questions about password management reports
Questions about password writeback
Password reset registration

Q: Can my users register their own password reset data?
A: Yes. As long as password reset is enabled and they are licensed, users can go to the password reset
registration portal (http://aka.ms/ssprsetup) to register their authentication information. Users can
also register through the Access Panel (http://myapps.microsoft.com). To register through the Access
Panel, they need to select their profile picture, select Profile, and then select the Register for
password reset option.
Q: If I enable password reset for a group and then decide to enable it for everyone are my users
required re-register?
A: No. Users who have populated authentication data are not required to re-register.
Q: Can I define password reset data on behalf of my users?
A: Yes, you can do so with Azure AD Connect, PowerShell, the Azure portal, or the Office 365 Admin
center. For more information, see Data used by Azure AD self-service password reset.
Q: Can I synchronize data for security questions from on-premises?
A: No, this is not possible today.
Q: Can my users register data in such a way that other users can't see this data?
A: Yes. When users register data by using the password reset registration portal, the data is saved into
private authentication fields that are visible only to global administrators and the user.
Q: Do my users have to be registered before they can use password reset?
A: No. If you define enough authentication information on their behalf, users don't have to register.
Password reset works as long as you have properly formatted the data stored in the appropriate
fields in the directory.
Q: Can I synchronize or set the authentication phone, authentication email, or alternate

authentication phone fields on behalf of my users?
Q: How does the registration portal determine which options to show my users?
A: The password reset registration portal shows only the options that you have enabled for your
users. These options are found under the User Password Reset Policy section of your directory’s
Configure tab. For example, if you don't enable security questions, then users are not able to register
for that option.
Q: When is a user considered registered?
A: A user is considered registered for SSPR when they have registered at least the Number of
methods required to reset a password that you have set in the Azure portal.
Password reset
Q: Do you prevent users from multiple attempts to reset a password in a short period of time?
A: Yes, there are security features built into password reset to protect it from misuse.
Users can try only five password reset attempts within a 24 hour period before they're locked out for
24 hours.
Users can try to validate a phone number, send a SMS, or validate security questions and answers
only five times within an hour before they're locked out for 24 hours.
Users can send an email a maximum of 10 times within a 10 minute period before they're locked out
for 24 hours.
The counters are reset once a user resets their password.
Q: How long should I wait to receive an email, SMS, or phone call from password reset?
A: Emails, SMS messages, and phone calls should arrive in under a minute. The normal case is 5 to 20
seconds. If you don't receive the notification in this time frame:
Check your junk folder.
Check that the number or email being contacted is the one you expect.
Check that the authentication data in the directory is correctly formatted, for example, +1
4255551234 or user@contoso.com.
Q: What languages are supported by password reset?
A: The password reset UI, SMS messages, and voice calls are localized in the same languages that are
supported in Office 365.
Q: What parts of the password reset experience get branded when I set the organizational
branding items in my directory’s configure tab?
A: The password reset portal shows your organization's logo and allows you to configure the
"Contact your administrator" link to point to a custom email or URL. Any email that's sent by
password reset includes your organization’s logo, colors, and name in the body of the email, and is
customized from the settings for that particular name.
Q: How can I educate my users about where to go to reset their passwords?
A: Try some of the suggestions in our SSPR deployment article.
Q: Can I use this page from a mobile device?
A: Yes, this page works on mobile devices.
Q: Do you support unlocking local Active Directory accounts when users reset their passwords?
A: Yes. When a user resets their password, if password writeback has been deployed through Azure
AD Connect, that user’s account is automatically unlocked when they reset their password.
Q: How can I integrate password reset directly into my user’s desktop sign-in experience?
A: If you're an Azure AD Premium customer, you can install Microsoft Identity Manager at no
additional cost and deploy the on-premises password reset solution.
Q: Can I set different security questions for different locales?
Q: How many questions can I configure for the security questions authentication option?
A: You can configure up to 20 custom security questions in the Azure portal.
Q: How long can security questions be?
A: Security questions can be 3 to 200 characters long.
Q: How long can the answers to security questions be?
A: Answers can be 3 to 40 characters long.
Q: Are duplicate answers to security questions rejected?
A: Yes, we reject duplicate answers to security questions.
Q: Can a user register the same security question more than once?
A: No. After a user registers a particular question, they can't register for that question a second time.
Q: Is it possible to set a minimum limit of security questions for registration and reset?
A: Yes, one limit can be set for registration and another for reset. Three to five security questions can
be required for registration, and three to five questions can be required for reset.
Q: I configured my policy to require users to use security questions for reset, but the Azure
administrators seem to be configured differently.
A: This is the expected behavior. Microsoft enforces a strong default two-gate password reset policy
for any Azure administrator role. This prevents administrators from using security questions. You can
find more information about this policy in the Password policies and restrictions in Azure Active
Directory article.
Q: If a user has registered more than the maximum number of questions required to reset, how
are the security questions selected during reset?
A: N number of security questions are selected at random out of the total number of questions a user
has registered for, where N is the amount that is set for the Number of questions required to reset
option. For example, if a user has registered five security questions, but only three are required to
reset a password, three of the five questions are randomly selected and are presented at reset. To
prevent question hammering, if the user gets the answers to the questions wrong the selection
process starts over.
Q: How long are the email and SMS one-time passcodes valid?
A: The session lifetime for password reset is 15 minutes. From the start of the password reset
operation, the user has 15 minutes to reset their password. The email and SMS one-time passcode
are invalid after this time period expires.
Q: Can I block users from resetting their password?
A: Yes, if you use a group to enable SSPR, you can remove an individual user from the group that
allows users to reset their password.
Password change
Q: Where should my users go to change their passwords?
A: Users can change their passwords anywhere they see their profile picture or icon, like in the upper-
right corner of their Office 365 portal or Access Panel experiences. Users can change their passwords
from the Access Panel Profile page. Users can also be asked to change their passwords automatically
at the Azure AD sign-in page if their passwords have expired. Finally, users can browse to the Azure
AD password change portal directly if they want to change their passwords.
Q: Can my users be notified in the Office portal when their on-premises password expires?
A: Yes, this is possible today if you use Active Directory Federation Services (AD FS). If you use AD FS,
follow the instructions in the Sending password policy claims with AD FS article. If you use password
hash synchronization, this is not possible today. We don't sync password policies from on-premises
directories, so it's not possible for us to post expiration notifications to cloud experiences. In either
case, it's also possible to notify users whose passwords are about to expire through PowerShell.
Q: Can I block users from changing their password?
A: For cloud-only users, password changes can't be blocked. For on-premises users, you can set the
User cannot change password option to selected. The selected users can't change their password.
Password management reports
Q: How long does it take for data to show up on the password management reports?
A: Data should appear on the password management reports in 5 to 10 minutes. In some instances, it
might take up to an hour to appear.
Q: How can I filter the password management reports?
A: To filter the password management reports, select the small magnifying glass to the extreme right
of the column labels, near the top of the report. If you want to do richer filtering, you can download
the report to Excel and create a pivot table.
Q: What is the maximum number of events that are stored in the password management
reports?
A: Up to 75,000 password reset or password reset registration events are stored in the password
management reports, spanning back as far as 30 days. We are working to expand this number to
include more events.
Q: How far back do the password management reports go?
A: The password management reports show operations that occurred within the last 30 days. For
now, if you need to archive this data, you can download the reports periodically and save them in a
separate location.
Q: Is there a maximum number of rows that can appear on the password management reports?
A: Yes. A maximum of 75,000 rows can appear on either of the password management reports,
whether they are shown in the UI or are downloaded.
Q: Is there an API to access the password reset or registration reporting data?
A: Yes. To learn how you can access the password reset reporting data stream, see Learn how to
access password reset reporting events programmatically.
Password writeback
Q: How does password writeback work behind the scenes?
A: See the article How password writeback works for an explanation of what happens when you
enable password writeback and how data flows through the system back into your on-premises
environment.
Q: How long does password writeback take to work? Is there a synchronization delay like there
is with password hash sync?
A: Password writeback is instant. It is a synchronous pipeline that works fundamentally differently

than password hash synchronization. Password writeback allows users to get real-time feedback
about the success of their password reset or change operation. The average time for a successful
writeback of a password is under 500 ms.
Q: If my on-premises account is disabled, how is my cloud account and access affected?
A: If your on-premises ID is disabled, your cloud ID and access will also be disabled at the next sync
interval through Azure AD Connect. By default, this sync is every 30 minutes.
Q: If my on-premises account is constrained by an on-premises Active Directory password

policy, does SSPR obey this policy when I change my password?
A: Yes, SSPR relies on and abides by the on-premises Active Directory password policy. This policy
includes the typical Active Directory domain password policy, as well as any defined, fine-grained
password policies that are targeted to a user.
Q: What types of accounts does password writeback work for?
A: Password writeback works for federated and password hash synchronized users.
Q: Does password writeback enforce my domain’s password policies?
A: Yes. Password writeback enforces password age, history, complexity, filters, and any other
restriction you might put in place on passwords in your local domain.
Q: Is password writeback secure? How can I be sure I won’t get hacked?
A: Yes, password writeback is secure. To read more about the four layers of security implemented by
the password writeback service, check out the Password writeback security model section in the
Password writeback overview article.
Next steps
Introduction to device management in Azure Active
Directory
In a mobile-first, cloud-first world, Azure Active Directory (Azure AD) enables single sign-on to devices, apps, and
services from anywhere. With the proliferation of devices - including Bring Your Own Device (BYOD), IT
professionals are faced with two opposing goals:
Empower the end users to be productive wherever and whenever
Protect the corporate assets at any time
Through devices, your users are getting access to your corporate assets. To protect your corporate assets, as an IT
administrator, you want to have control over these devices. This enables you to make sure that your users are
accessing your resources from devices that meet your standards for security and compliance.
Device management is also the foundation for device-based conditional access. With device-based conditional
access, you can ensure that access to resources in your environment is only possible with trusted devices.
This topic explains how device management in Azure Active Directory works.
Getting devices under the control of Azure AD

To get a device under the control of Azure AD, you have two options:
Registering
Joining
Registering a device to Azure AD enables you to manage a device’s identity. When a device is registered, Azure
AD device registration provides the device with an identity that is used to authenticate the device when a user
signs-in to Azure AD. You can use the identity to enable or disable a device.
When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device attributes
in Azure AD are updated with additional information about the device. This allows you to create conditional access
rules that enforce access from devices to meet your standards for security and compliance. For more information
on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune .
Joining a device is an extension to registering a device. This means, it provides you with all the benefits of
registering a device and in addition to this, it also changes the local state of a device. Changing the local state
enables your users to sign-in to a device using an organizational work or school account instead of a personal
account.
Azure AD registered devices

The goal of Azure AD registered devices is to provide you with support for the Bring Your Own Device (BYOD)
scenario. In this scenario, a user can access your organization’s Azure Active Directory controlled resources using
a personal device.
The access is based on a work or school account that has been entered on the device.
For example, Windows 10 enables users to add a work or school account to a personal computer, tablet, or phone.
When a user has added a work or school account, the device is registered with Azure AD and optionally enrolled
in the mobile device management (MDM) system that your organization has configured. Your organization’s
users can add a work or school account to a personal device conveniently:
When accessing a work application for the first time
Manually via the Settings menu in the case of Windows 10
You can configure Azure AD registered devices for Windows 10, iOS, Android and macOS.
Azure AD joined devices

The goal of Azure AD joined devices is to simplify:
Windows deployments of work-owned devices
Access to organizational apps and resources from any Windows device
These goals are accomplished by providing your users with a self-service experience for getting work-owned
devices under the control of Azure AD.
Azure AD Join is intended for organizations that are cloud-first / cloud-only. These are typically small- and
medium-sized businesses that do not have an on-premises Windows Server Active Directory infrastructure.
Implementing Azure AD joined devices provides you with the following benefits:
Single-Sign-On (SSO) to your Azure managed SaaS apps and services. Your users don’t see additional
authentication prompts when accessing work resources. The SSO functionality is even when they are not
connected to the domain network available.
Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a
Microsoft account (for example, Hotmail) to see settings across devices.
Access to Windows Store for Business using AD account. Your users can choose from an inventory of
applications pre-selected by the organization.
Windows Hello support for secure and convenient access to work resources.
Restriction of access to apps from only devices that meet compliance policy.
While Azure AD join is primarily intended for organizations that do not have an on-premises Windows Server
Active Directory infrastructure, you can certainly also use it in scenarios where:
You can’t use an on-premises domain join, for example, if you need to get mobile devices such as tablets
and phones under control.
Your users primarily need to access Office 365 or other SaaS apps integrated with Azure AD.
You want to manage a group of users in Azure AD instead of in Active Directory. This can apply, for
example, to seasonal workers, contractors, or students.
You want to provide joining capabilities to workers in remote branch offices with limited on-premises
infrastructure.
You can configure Azure AD joined devices for Windows 10 devices.
Hybrid Azure AD joined devices

For more than a decade, many organizations have used the domain join to their on-premises Active Directory to
enable:
IT departments to manage work-owned devices from a central location.
Users to sign in to their devices with their Active Directory work or school accounts.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they
often use System Center Configuration Manager (SCCM) or group policy (GP) to manage them.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by
Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both, joined
to your on-premises Active Directory and your Azure Active Directory.
You should use Azure AD hybrid joined devices if:

You have Win32 apps deployed to these devices that use NTLM / Kerberos.
You require GP or SCCM / DCM to manage devices.
You want to continue to use imaging solutions to configure devices for your employees.
You can configure Hybrid Azure AD joined devices for Windows 10 and down-level devices such as Windows 8
and Windows 7.
Summary
With device management in Azure AD, you can:
Simplify the process of bringing devices under the control of Azure AD
Provide your users with an easy to use access to your organization’s cloud-based resources
As a rule of a thumb, you should use:
Azure AD registered devices:
For personal devices
To manually register devices with Azure AD
Azure AD joined devices:
For devices that are owned by your organization
For devices that are not joined to an on-premises AD
To manually register devices with Azure AD
To change the local state of a device
Hybrid Azure AD joined devices for devices that are joined to an on-premises AD
For devices that are owned by your organization
For devices that are joined to an on-premises AD
To automatically register devices with Azure AD
To change the local state of a device
Next steps
To get an overview of how to manage device in the Azure portal, see managing devices using the Azure
portal
To learn more about device-based conditional access, see configure Azure Active Directory device-based
conditional access policies.
To setup:
Azure Active Directory registered Windows 10 devices, see how to configure Azure Active Directory
registered Windows 10 devices
Azure Active Directory joined devices, see how to configure Azure Active Directory joined devices
Hybrid Azure AD joined devices, see how to configure hybrid Azure Active Directory joined devices.
Managing devices using the Azure portal
With device management in Azure Active Directory (Azure AD), you can ensure that your users are accessing your
resources from devices that meet your standards for security and compliance.
This topic:
Assumes that you are familiar with the introduction to device management in Azure Active Directory
Provides you with information about managing your devices using the Azure portal
Manage devices
The Azure portal provides you with a central place to manage your devices. You can get to this place by either
using a direct link or by following these manual steps:
1. Sing-in to the Azure portal as administrator.
2. On the left navbar, click Active Directory.
3. In the Manage section, click Devices.

The Devices page enables you to:
Configure your device management settings
Locate devices
Perform device management tasks
Review the device management related audit logs
Configure device settings

To manage your devices using the Azure portal, your devices need to be either registered or joined to Azure AD.
As an administrator, you can fine-tune the process of registering and joining devices by configuring the device
settings.
The device settings page enables you to configure:
Users may join devices to Azure AD - This setting enables you to select the users who can join devices to
Azure AD. The default is All.
Additional local administrators on Azure AD joined devices - You can select the users that are
granted local administrator rights on a device. Users added here are added to the Device Administrators
role in Azure AD. Global administrators in Azure AD and device owners are granted local administrator
rights by default. This option is a premium edition capability available through products such as Azure AD
Premium or the Enterprise Mobility Suite (EMS).
Users may register their devices with Azure AD - You need to configure this setting to allow devices to
be registered with Azure AD. If you select None, devices are not allowed to register when they are not
Azure AD joined or hybrid Azure AD joined. Enrollment with Microsoft Intune or Mobile Device
Management (MDM) for Office 365 requires registration. If you have configured either of these services,
ALL is selected and NONE is not available..
Require Multi-Factor Auth to join devices - You can choose whether users are required to provide a
second authentication factor to join their device to Azure AD. The default is No. We recommend requiring
multi-factor authentication when registering a device. Before you enable multi-factor authentication for this
service, you must ensure that multi-factor authentication is configured for the users that register their
devices. For more information on different Azure multi-factor authentication services, see getting started
with Azure multi-factor authentication.
Maximum number of devices - This setting enables you to select the maximum number of devices that a
user can have in Azure AD. If a user reaches this quota, they are not be able to add additional devices until
one or more of the existing devices are removed. The device quote is counted for all devices that are either
Azure AD joined or Azure AD registered today. The default value is 20.
Users may sync settings and app data across devices - By default, this setting is set to NONE. Selecting
specific users or groups or ALL allows the user’s settings and app data to sync across their Windows 10
devices. Learn more on how sync works in Windows 10. This option is a premium capability available
through products such as Azure AD Premium or the Enterprise Mobility Suite (EMS).
Locate devices
You have two options to locate registered and joined devices:
All devices in the Manage section of the Devices page
Devices in the Manage section of a User page

With both options, you can get to a view that:
Enables you to search for devices using the display name as filter.
Provides you with detailed overview of registered and joined devices
Enables you to perform common device management tasks
Device management tasks

As an administrator, you can manage the registered or joined devices. This section provides you with information
about common device management tasks.
Manage an Intune device
If you are an Intune administrator, you can manage devices marked as Microsoft Intune. An administrator can
see additional device
Enable / disable an Azure AD device

To enable / disable a device, you have two options:
The tasks menu ("...") on the All devices page
The toolbar on the Devices page
Remarks:
You need to be a global administrator in Azure AD to enable / disable a device.
Disabling a device prevents a device from accessing your Azure AD resources.
Delete an Azure AD device
To delete a device, you have two options:
The tasks menu ("...") on the All devices page
The toolbar on the Devices page
Remarks:
You need to be a global administrator in Azure AD to delete a device.
Deleting a device:
Prevents a device from accessing your Azure AD resources.
Removes all details that are attached to the device, for example, BitLocker keys for Windows devices.
Represents a non-recoverable activity and is not recommended unless it is required.
If a device is managed by another management authority (for example, Microsoft Intune), please make sure that
the device has been wiped / retired before deleting the device in Azure AD.
View or copy device ID
You can use a device ID to verify the device ID details on the device or using PowerShell during troubleshooting.
To access the copy option, click the device.
View or copy BitLocker keys

If you are an administrator, you can view and copy the BitLocker keys to help users to recover their encrypted
drive. These keys are only available for Windows devices that are encrypted and have their keys stored in Azure
AD. You can copy these keys when accessing details of the device.
Audit logs
Device activities are available through the activity logs. This includes activities triggered by the device registration
service and by users:
Device creation and adding owners / users on the device
Changes to device settings
Device operations such as deleting or updating a device
Your entry point to the auditing data is Audit logs in the Activity section of the Devices page.

The date and time of the occurrence
The targets
The initiator / actor (who) of an activity
The activity (what)
To narrow down the reported data to a level that works for you, you can filter the audit data using the following
fields:
Category
Activity resource type
Activity
Date range
Target
Initiated By (Actor)
In addition to the filters, you can search for specific entries.
Next steps
Introduction to device management in Azure Active Directory
Usage scenarios and deployment considerations for
Azure AD Join
Usage scenarios for Azure AD Join

Scenario 1: Businesses largely in the cloud
Azure Active Directory Join (Azure AD Join) can benefit you if you currently operate and manage identities for your
business in the cloud or are moving to the cloud soon. You can use an account that you have created in Azure AD
to sign in to Windows 10. Through the first run experience (FRX) process, or by joining Azure AD from the settings
menu, your users can join their machines to Azure AD. Your users can also enjoy single sign-on (SSO) access to
cloud resources like Office 365, either in their browsers or in Office applications.
Scenario 2: Educational institutions
Educational institutions usually have two user types: faculty and students. Faculty members are considered longer-
term members of the organization. Creating on-premises accounts for them is desirable. But students are shorter-
term members of the organization and their accounts can be managed in Azure AD. This means that directory scale
can be pushed to the cloud instead of being stored on-premises. It also means that students will be able to sign in
to Windows with their Azure AD accounts and get access to Office 365 resources in Office applications.
Scenario 3: Retail businesses
Retail businesses have seasonal workers and long-term employees. You typically create on-premises accounts and
use domain-joined machines for longer-term full-time employees. But seasonal workers are shorter-term
members of the organization, and it's desirable to manage their accounts where user licenses can be more easily
moved around. When you create their user accounts in the cloud with Office 365 licenses, these users get the
benefits of signing in to Windows and Office applications with an Azure AD account, while you maintain more
flexibility with their licenses after they leave.
Scenario 4: Additional scenarios
Along with the benefits discussed earlier, you benefit from having your users join their devices to Azure AD
because of a simplified joining experience, efficient device management, automatic mobile device management
enrollment, and single sign-on to Azure AD and on-premises resources.
Deployment considerations for Azure AD Join

Enable your users to join a company-owned device directly to Azure AD
Enterprises can provide cloud-only accounts to partner companies and organizations. These partners can then
easily access company apps and resources with single sign-on. This scenario is applicable to users who access
resources primarily in the cloud, such as Office 365 or SaaS apps that rely on Azure AD for authentication.
Prerequisites
At the enterprise level (administrator)
Azure subscription with Azure Active Directory
At the user level
Windows 10 (Professional and Enterprise editions)
Administrator tasks
Set up device registration
User tasks
Set up a new Windows 10 device with Azure AD during setup
Set up a Windows 10 device with Azure AD from the settings menu
Join a personal Windows 10 device to your organization
Enable BYOD in your organization for Windows 10

You can set up your users and employees to use their personal Windows devices (BYOD) to access company apps
and resources. Your users can add their Azure AD accounts (work or school accounts) to a personal Windows
device to access resources in a secure and compliant fashion.
Prerequisites
At the enterprise level (administrator)
Azure AD subscription
At the user level
Windows 10 (Professional and Enterprise editions)
Administrator tasks
Set up device registration
User tasks
Join a personal Windows 10 device to your organization
Windows 10 for the enterprise: Ways to use devices for work
Extending cloud capabilities to Windows 10 devices through Azure Active Directory Join
Authenticating identities without passwords through Microsoft Passport
Learn about usage scenarios for Azure AD Join
Connect domain-joined devices to Azure AD for Windows 10 experiences
Set up Azure AD Join
Azure Active Directory device management FAQ
Q: How can I register a macOS device?

A: To register macOS device:
1. Create a compliance policy
2. Define a conditional access policy for macOS devices
Remarks:
The users that are included in your conditional access policy need a supported version of Office for macOS
to access resources.
During the first access attempt, your users are prompted to enroll the device using the company portal.
Q: I registered the device recently. Why can’t I see the device under my user info in the Azure portal?
A: Windows 10 devices that are domain-joined with automatic device registration do not show up under the USER
info. You need to use PowerShell to see all devices.
Only the following devices are listed under the USER info:
All personal devices that are not enterprise joined
All non-Windows 10 / Windows Server 2016
All non-Windows devices
Q: Why can I not see all the devices registered in Azure Active Directory in the Azure portal?
A: Currently, there is no way to see all registered devices in the Azure portal. You can use Azure PowerShell to find
all devices. For more details, see the Get-MsolDevice cmdlet.
Q: How do I know what the device registration state of the client is?
A: The device registration state depends on:
What the device is
How it was registered
Any details related to it.
Q: Why is a device I have deleted in the Azure portal or using Windows PowerShell still listed as
registered?
A: This is by design. The device will not have access to resources in the cloud. If you want to remove the device and
register again, a manual action must be to be taken on the device.
For Windows 10 and Windows Server 2016 that are on-premises AD domain-joined:
1. Open the command prompt as an administrator.
2. Type dsregcmd.exe /debug /leave
3. Sign out and sign in to trigger the scheduled task that registers the device again.
For other Windows platforms that are on-premises AD domain-joined:
1. Open the command prompt as an administrator.
2. Type "%programFiles%\Microsoft Workplace Join\autoworkplace.exe /l" .
3. Type "%programFiles%\Microsoft Workplace Join\autoworkplace.exe /j" .
Q: Why do I see duplicate device entries in Azure portal?

A:
For Windows 10 and Windows Server 2016, if they are repeated attempts to unjoin and re-join the same
device, there might be duplicate entries.
If you have used Add Work or School Account, each windows user who uses Add Work or School Account
will create a new device record with the same device name.
Other Windows platforms that are on-premises AD domain-joined using automatic registration will create a
new device record with the same device name for each domain user who logs into the device.
An AADJ machine that has been wiped, re-installed and re-joined with the same name, will show up as
another record with the same device name.
Q: Why can a user still access resources from a device I have disabled in the Azure portal?
A: It can take up to an hour for a revoke to be applied.
NOTE
For lost devices, we recommend wiping the device to ensure that users cannot access the device. For more details, see Enroll
devices for management in Intune.
Q: Why do my users see “You can’t get there from here”?

A: If you have configured certain conditional access rules to require a specific device state and the device does not
meet the criteria, users are blocked and see this message. Please evaluate the rules and ensure that the device is
able to meet the criteria to avoid this message.
Q: I see the device record under the USER info in the Azure portal and can see the state as registered on
the client. Am I setup correctly for using conditional access?
A: The device record (deviceID) and state on the Azure portal must match the client and meet any evaluation
criteria for conditional access. For more details, see Get started with Azure Active Directory Device Registration.
Q: Why do I get a "username or password is incorrect" message for a device I have just joined to Azure
AD?
A: Common reasons for this scenario are:
Your user credentials are no longer valid.
Your computer is unable to communicate with Azure Active Directory. Check for any network connectivity
issues.
The Azure AD Join pre-requisites were not met. Please ensure that you have followed the steps for Extending
cloud capabilities to Windows 10 devices through Azure Active Directory Join.
Federated logins requires your federation server to support a WS-Trust active endpoint.
Q: Why do I see the “Oops… an error occurred!" dialog when I try do join my PC?
A: This is a result of setting up Azure Active Directory enrollment with Intune. For more details, see Set up Windows
device management.
Q: Why did my attempt to join a PC fail although I didn't get any error information?
A: A likely cause is that the user is logged in to the device using the built-in administrator account. Please create a
different local account before using Azure Active Directory Join to complete the setup.
Q: Where can I find instructions for the setup of automatic device registration?
A: For detailed instructions, see How to configure automatic registration of Windows domain-joined devices with
Q: Where can I find troubleshooting information about the automatic device registration?
A: For troubleshooting information, see:
Troubleshooting auto-registration of domain joined computers to Azure AD – Windows 10 and Windows
Server 2016
Troubleshooting auto-registration of domain joined computers to Azure AD for Windows down-level clients
Set up Azure Active Directory registered Windows 10
devices
resources from devices that meet your standards for security and compliance. For more details, see Introduction to
device management in Azure Active Directory.
If you want to enable the Bring Your Own Device (BYOD) scenario, you can accomplish this by configuring Azure
AD registered devices. In Azure AD, you can configure Azure AD registered devices for Windows 10, iOS, Android
and macOS. This topic provides you with the related steps for Windows 10 devices.
Before you begin

To register a Windows 10 device, the device registration service must be configured to enable you to register
devices. In addition to having permission to registering devices in your Azure AD tenant, you must have fewer
devices registered than the configured maximum. For more details, see configure device settings.

When registering a device, you should keep the following in mind:
Windows registers the device in the organization’s directory in Azure AD
You might be required to go through multi-factor authentication challenge. This challenge is configurable by
your IT administrator.
Azure AD checks whether the device requires mobile device management enrollment and enrolls it if
applicable.
If you are a managed user, Windows takes you to the desktop through the automatic sign-in.
If you are a federated user, you will be taken to a Windows sign-in screen to enter your credentials.
Registering a device
This section provides you with the steps to register your Windows 10 device to your Azure AD. If you have
successfully registered your device to Azure AD, your Access work or school dialog indicates this with a Work or
school account entry.
To register your Windows 10 device:
1. In the Start menu, click Settings.
2. Click Accounts.
3. Click Access work or school.
4. On the Access work or school dialog, click Connect.

5. On the Set up a work or school account dialog, enter your account name (e.g.: someone@example.com),
and then click Next.
6. On the Enter password dialog, enter your password, and then click Next.
7. On the You're all set dialog, click Done.
Verification
To verify whether a device is joined to an Azure AD, you can review the Access work or school dialog on your
device.
Alternatively, you can also review device settings on the Azure AD portal.
Next steps
For more details, see the introduction to device management in Azure Active Directory
For more details about managing devices in the Azure AD portal, see the managing devices using the Azure
portal .
Set up Azure Active Directory joined devices
resources from devices that meet your standards for security and compliance. For more information, see
Introduction to device management in Azure Active Directory.
If you want to bring work-owned Windows 10 devices under the control of Azure AD, you can accomplish this by
configuring Azure AD joined devices. This topic provides you with the related steps.
Prerequisites
To join a Windows 10 device, the device registration service must be configured to enable you to register devices.
In addition to having permission to joining devices in your Azure AD tenant, you must have fewer devices
registered than the configured maximum. For more information, see configure device settings.

Windows joins the device in the organization’s directory in Azure AD.
You might be required to go through multi-factor authentication challenge. This challenge is configurable by
your IT administrator.
Azure AD checks whether the device requires mobile device management enrollment and enrolls it if
applicable.
If you are a managed user, Windows takes you to the desktop through the automatic sign-in.
If you are a federated user, you have to sign-in using your credentials.
Joining a device
This section provides you with the steps to join your Windows 10 device to your Azure AD. If you have successfully
joined your device to Azure AD, your Access work or school dialog indicates this with a Connected to <your
Azure AD> entry.
To join your Windows 10 device:
1. In the Start menu, click Settings.
2. Click Accounts.
3. Click Access work or school.
4. On the Access work or school dialog, click Connect.
5. On the Setup a work or school account dialog, click Join this device to Azure Active Directory.
6. On the Let's get you signed in dialog, enter your account name (for example, someone@example.com),
and then click Next.
7. On the Enter password dialog, enter your password, and then click Sign in.
8. On the Make sure this is your organization dialog, click Join.

9. On the You're all set dialog, click Done.
Verification
To verify whether a device is joined to an Azure AD, you can review the Access work or school dialog on your
device.
Alternatively, you can run the following command: dsregcmd /status

On a successfully joined device, AzureAdJoined is Yes.
You can also review device settings on the Azure AD portal.
For more information, see locate devices.
Next steps
The introduction to device management in Azure Active Directory
Managing devices using the Azure portal
How to configure hybrid Azure Active Directory
joined devices
resources from devices that meet your standards for security and compliance. For more details, see Introduction to
device management in Azure Active Directory.
If you have an on-premises Active Directory environment and you want to join your domain-joined devices to
Azure AD, you can accomplish this by configuring hybrid Azure AD joined devices. The topic provides you with the
related steps.
Before you begin

Before you start configuring hybrid Azure AD joined devices in your environment, you should familiarize yourself
with the supported scenarios and the constraints.
If you are relying on the System Preparation Tool (Sysprep), please make sure you create images from an
installation of Windows that has not been yet registered with Azure AD.
To improve the readability of the descriptions, this topic uses the following term:
Windows current devices - This term refers to domain-joined devices running Windows 10 or Windows
Server 2016.
Windows down-level devices - This term refers to all supported domain-joined Windows devices that are
neither running Windows 10 nor Windows Server 2016.
Windows current devices
For devices running the Windows desktop operating system, the supported version is the Windows 10
Anniversary Update (version 1607) or later.
The registration of Windows current devices is supported in non-federated environments such as password
hash sync configurations.
Windows down-level devices
The following Windows down-level devices are supported:
Windows 8.1
Windows 7
Windows Server 2012 R2
Windows Server 2012
The registration of Windows down-level devices is supported in non-federated environments through Seamless
Single Sign On Azure Active Directory Seamless Single Sign-On.
The registration of Windows down-level devices is not supported for devices using roaming profiles. If you are
relying on roaming of profiles or settings, use Windows 10.
Prerequisites
Before you start enabling hybrid Azure AD joined devices in your organization, you need to make sure that you are
running an up-to-date version of Azure AD connect.
Azure AD Connect:
Keeps the association between the computer account in your on-premises Active Directory (AD) and the device
object in Azure AD.
Enables other device related features like Windows Hello for Business.
Make sure that the following URLs are accessible from computers inside your organization network for registration
of computers to Azure AD:
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
https://device.login.microsoftonline.com
If your organizations requires access to the Internet via an outbound proxy, must implement Web Proxy Auto-
Discovery (WPAD) to enable Windows 10 computers to register to Azure AD.
Configuration steps
You can configure hybrid Azure AD joined devices for various types of Windows device platforms. This topic
includes the required steps for all typical configuration scenarios.
Use the following table to get an overview of the steps that are required for your scenario:
WINDOWS CURRENT AND WINDOWS CURRENT AND

STEPS PASSWORD HASH SYNC FEDERATION WINDOWS DOWN-LEVEL
Step 1: Configure service

connection point
Step 2: Setup issuance of

claims
Step 3: Enable non-Windows

10 devices
Step 4: Control deployment

and rollout
Step 5: Verify joined devices
Step 1: Configure service connection point

The service connection point (SCP) object is used by your devices during the registration to discover Azure AD
tenant information. In your on-premises Active Directory (AD), the SCP object for the hybrid Azure AD joined
devices must exist in the configuration naming context partition of the computer's forest. There is only one
configuration naming context per forest. In a multi-forest Active Directory configuration, the service connection
point must exist in all forests containing domain-joined computers.
You can use the Get-ADRootDSE cmdlet to retrieve the configuration naming context of your forest.
For a forest with the Active Directory domain name fabrikam.com, the configuration naming context is:
CN=Configuration,DC=fabrikam,DC=com
In your forest, the SCP object for the auto-registration of domain-joined devices is located at:
CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration
Naming Context]
Depending on how you have deployed Azure AD Connect, the SCP object may have already been configured. You
can verify the existence of the object and retrieve the discovery values using the following Windows PowerShell
script:
$scp = New-Object System.DirectoryServices.DirectoryEntry;
$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration

Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";
$scp.Keywords;
The $scp.Keywords output shows the Azure AD tenant information, for example:
azureADName:microsoft.com
azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47
If the service connection point does not exist, you can create it by running the
Initialize-ADSyncDomainJoinedComputerSync cmdlet on your Azure AD Connect server. Enterprise admin credential
is required to run this cmdlet.
The cmdlet:
Creates the service connection point in the Active Directory forest Azure AD Connect is connected to.
Requires you to specify the AdConnectorAccount parameter. This is the account that is configured as Active
Directory connector account in Azure AD connect.
The following script shows an example for using the cmdlet. In this script, $aadAdminCred = Get-Credential requires
you to type a user name. You need to provide the user name in the user principal name (UPN) format (
user@example.com ).
Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";
$aadAdminCred = Get-Credential;
Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials

$aadAdminCred;
The Initialize-ADSyncDomainJoinedComputerSync cmdlet:

Uses the Active Directory PowerShell module and AD DS Tools, which rely on Active Directory Web Services
running on a domain controller. Active Directory Web Services is supported on domain controllers running
Windows Server 2008 R2 and later.
Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this
link.
If the AD DS tools are not installed, the Initialize-ADSyncDomainJoinedComputerSync will fail. The AD DS tools can
be installed through Server Manager under Features - Remote Server Administration Tools - Role
Administration Tools.
For domain controllers running Windows Server 2008 or earlier versions, use the script below to create the service
connection point.
In a multi-forest configuration, you should use the following script to create the service connection point in each
forest where computers exist:
$verifiedDomain = "contoso.com" # Replace this with any of your verified domain names in Azure AD
$tenantID = "72f988bf-86f1-41af-91ab-2d7cd011db47" # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com" # Replace this with your AD configuration naming
context
$de = New-Object System.DirectoryServices.DirectoryEntry

$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")

$deDRC.CommitChanges()
$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")

$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)
$deSCP.CommitChanges()
Step 2: Setup issuance of claims

In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a 3rd party
on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register
against the Azure Active Directory Device Registration Service (Azure DRS).
Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint
(either 1.3 or 2005 versions) hosted by the on-premises federation service.
NOTE
When using AD FS, either adfs/services/trust/13/windowstransport or adfs/services/trust/2005/windowstransport
must be enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the
proxy. You can see what end-points are enabled through the AD FS management console under Service > Endpoints.
If you don’t have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they
support WS-Trust 1.3 or 2005 end-points and that these are published through the Metadata Exchange file (MEX).
The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS
will create a device object in Azure AD with some of this information which is then used by Azure AD Connect to
associate the newly created device object with the computer account on-premises.
http://schemas.microsoft.com/ws/2012/01/accounttype
http://schemas.microsoft.com/identity/claims/onpremobjectguid
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
If you have more than one verified domain name, you need to provide the following claim for computers:
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid
If you are already issuing an ImmutableID claim (e.g., alternate login ID) you need to provide one corresponding
claim for computers:
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
In the following sections, you find information about:

The values each claim should have
How a definition would look like in AD FS
The definition helps you to verify whether the values are present or if you need to create them.
NOTE
If you don’t use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate
configuration to issue these claims.
Issue account type claim

http://schemas.microsoft.com/ws/2012/01/accounttype - This claim must contain a value of DJ, which identifies the
device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue account type for domain-joined computers"

c:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value =~ "-515$",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value = "DJ"
);
Issue objectGUID of the computer account on-premises

http://schemas.microsoft.com/identity/claims/onpremobjectguid - This claim must contain the objectGUID value of
the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue object GUID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
]
=> issue(
store = "Active Directory",
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
query = ";objectguid;{0}",
param = c2.Value
);
Issue objectSID of the computer account on-premises

http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid - This claim must contain the the objectSid
value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
@RuleName = "Issue objectSID for domain-joined computers"
c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
]
=> issue(claim = c2);
Issue issuerID for computer when multiple verified domain names in Azure AD
http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid - This claim must contain the Uniform Resource
Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or
3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that
specific order after the ones above. Please note that one rule to explicitly issue the rule for users is necessary. In the
rules below, a first rule identifying user vs. computer authentication is added.
@RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
Value == "DJ"
]
)
=> add(
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Value == "User"
]
=> issue(
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid",
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "http://<verified-domain-name>/adfs/services/trust/"
);
In the claim above,

<verified-domain-name> is a placeholder you need to replace with one of your verified domain names in Azure
AD. For example, Value = "http://contoso.com/adfs/services/trust/"
For more details about verified domain names, see Add a custom domain name to Azure Active Directory.
To get a list of your verified company domains, you can use the Get-MsolDomain cmdlet.
Issue ImmutableID for computer when one for users exist (e.g. alternate login ID is set)
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID - This claim must contain a valid value for
computers. In AD FS, you can create an issuance transform rule as follows:
@RuleName = "Issue ImmutableID for computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
param = c2.Value
);
Helper script to create the AD FS issuance transform rules

The following script helps you with the creation of the issuance transform rules described above.
$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains
$rule1 = '@RuleName = "Issue account type for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "DJ"
);'
$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
=> issue(
types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"),
param = c2.Value
);'
$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"

c1:[
Value =~ "-515$",
]
&&
c2:[
Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
]
=> issue(claim = c2);'
$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
Value == "DJ"
]
)
=> add(
Value = "User"
);
@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&&
c2:[
Value == "User"
]
=> issue(
Value = regexreplace(
c1.Value,
".+@(?<domain>.+)",
"http://${domain}/adfs/services/trust/"
)
);
@RuleName = "Issue issuerID for domain-joined computers"

c:[
Value =~ "-515$",
]
=> issue(
Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}
$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
Value =~ "-515$",
]
&&
c2:[
]
=> issue(
types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"),
param = c2.Value
);'
}
$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules
$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules

$crSet.ClaimRulesString
Remarks
This script appends the rules to the existing rules. Do not run the script twice because the set of rules would
be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding
conditions) before running the script again.
If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains
cmdlet), set the value of $multipleVerifiedDomainNames in the script to $true. Also make sure that you
remove any existing issuerid claim that might have been created by Azure AD Connect or via other means.
Here is an example for this rule:
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value =
regexreplace(c.Value, ".+@(?<domain>.+)", "http://${domain}/adfs/services/trust/"));
If you have already issued an ImmutableID claim for user accounts, set the value of
$immutableIDAlreadyIssuedforUsers in the script to $true.
Step 3: Enable Windows down-level devices

If some of your domain-joined devices Windows down-level devices, you need to:
Set a policy in Azure AD to enable users to register devices.
Configure your on-premises federation service to issue claims to support Integrated Windows
Authentication (IWA) for device registration.
Add the Azure AD device authentication end-point to the local Intranet zones to avoid certificate prompts
when authenticating the device.
Set policy in Azure AD to enable users to register devices
To register Windows down-level devices, you need to make sure that the setting to allow users to register devices
in Azure AD is set. In the Azure portal, you can find this setting under:
Azure Active Directory > Users and groups > Device settings
The following policy must be set to All: Users may register their devices with Azure AD
Configure on-premises federation service

Your on-premises federation service must support issuing the authenticationmehod and wiaormultiauthn
claims when receiving an authentication request to the Azure AD relying party holding a resouce_params
parameter with an encoded value as shown below:
eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0
which decoded is {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}
When such a request comes, the on-premises federation service must authenticate the user using Integrated
Windows Authentication and upon success, it must issue the following two claims:
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
http://schemas.microsoft.com/claims/wiaormultiauthn
In AD FS, you must add an issuance transform rule that passes-through the authentication method.
To add this rule:
1. In the AD FS management console, go to AD FS > Trust Relationships > Relying Party Trusts .
2. Right-click the Microsoft Office 365 Identity Platform relying party trust object, and then select Edit Claim
Rules.
3. On the Issuance Transform Rules tab, select Add Rule.
4. In the Claim rule template list, select Send Claims Using a Custom Rule.
5. Select Next.
6. In the Claim rule name box, type Auth Method Claim Rule.
7. In the Claim rule box, type the following rule:
c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);
8. On your federation server, type the PowerShell command below after replacing <RPObjectName> with
the relying party object name for your Azure AD relying party trust object. This object usually is named
Microsoft Office 365 Identity Platform.
Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences
wiaormultiauthn
Add the Azure AD device authentication end-point to the Local Intranet zones
To avoid certificate prompts when users in register devices authenticate to Azure AD you can push a policy to your
domain-joined devices to add the following URL to the Local Intranet zone in Internet Explorer:
https://device.login.microsoftonline.com
Step 4: Control deployment and rollout

When you have completed the required steps, domain-joined devices are ready to automatically join Azure AD:
All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016
automatically register with Azure AD at device restart or user sign-in.
New devices register with Azure AD when the device restarts after the domain join operation is completed.
Devices that were previously Azure AD registered (for example, for Intune) transition to “Domain Joined,
AAD Registered”; however it takes some time for this process to complete across all devices due to the
normal flow of domain and user activity.
Remarks
You can use a Group Policy object to control the rollout of automatic registration of Windows 10 and
Windows Server 2016 domain-joined computers.
Windows 10 November 2015 Update automatically joins with Azure AD only if the rollout Group Policy
object is set.
To rollout of Windows down-level computers, you can deploy a Windows Installer package to computers
that you select.
If you push the Group Policy object to Windows 8.1 domain-joined devices, a join is attempted; however it is
recommended that you use the Windows Installer package to join all your Windows down-level devices.
Create a Group Policy object
To control the rollout of Windows current computers, you should deploy the Register domain-joined computers
as devices Group Policy object to the devices you want to register. For example, you can deploy the policy to an
organizational unit or to a security group.
To set the policy:
1. Open Server Manager, and then go to Tools > Group Policy Management .
2. Go to the domain node that corresponds to the domain where you want to activate auto-registration of
Windows current computers.
3. Right-click Group Policy Objects, and then select New.
4. Type a name for your Group Policy object. For example, *Hybrid Azure AD join.
5. Click OK.
6. Right-click your new Group Policy object, and then select Edit.
7. Go to Computer Configuration > Policies > Administrative Templates > Windows Components >
Device Registration.
8. Right-click Register domain-joined computers as devices, and then select Edit.
NOTE
This Group Policy template has been renamed from earlier versions of the Group Policy Management console. If you
are using an earlier version of the console, go to
Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join >
Automatically workplace join client computers
.
9. Select Enabled, and then click Apply.

10. Click OK.
11. Link the Group Policy object to a location of your choice. For example, you can link it to a specific organizational
unit. You also could link it to a specific security group of computers that automatically join with Azure AD. To set
this policy for all domain-joined Windows 10 and Windows Server 2016 computers in your organization, link
the Group Policy object to the domain.
Windows Installer packages for non-Windows 10 computers
To join domain-joined Windows down-level computers in a federated environment, you can download and install
these Windows Installer package (.msi) from Download Center at the Microsoft Workplace Join for non-Windows
10 computers page.
You can deploy the package by using a software distribution system like System Center Configuration Manager.
The package supports the standard silent install options with the quiet parameter. System Center Configuration
Manager Current Branch offers additional benefits from earlier versions, like the ability to track completed
registrations. For more information, see System Center Configuration Manager.
The installer creates a scheduled task on the system that runs in the user’s context. The task is triggered when the
user signs in to Windows. The task silently joins the device with Azure AD with the user credentials after
authenticating using Integrated Windows Authentication. To see the scheduled task, in the device, go to Microsoft
> Workplace Join, and then go to the Task Scheduler library.
Step 5: Verify joined devices

You can check successful joined devices in your organization by using the Get-MsolDevice cmdlet in the Azure
Active Directory PowerShell module.
The output of this cmdlet shows devices that are registered and joined with Azure AD. To get all devices, use the -
All parameter, and then filter them using the deviceTrustType property. Domain joined devices have a value of
Domain Joined.
Next steps
Introduction to device management in Azure Active Directory
Setting up on-premises conditional access by using
Azure Active Directory device registration
When you require users to workplace-join their personal devices to the Azure Active Directory (Azure AD) device
registration service, their devices can be marked as known to your organization. Following is a step-by-step guide
for enabling conditional access to on-premises applications by using Active Directory Federation Services (AD FS) in
Windows Server 2012 R2.
NOTE
An Office 365 license or Azure AD Premium license is required when using devices that are registered in Azure Active
Directory device registration service conditional access policies. These include policies that are enforced by AD FS in on-
premises resources.
For more information about the conditional access scenarios for on-premises resources, see Join to workplace from any device
for SSO and seamless second-factor authentication across company applications.
These capabilities are available to customers who purchase an Azure Active Directory Premium license.
Supported devices
Windows 7 domain-joined devices
Windows 8.1 personal and domain-joined devices
iOS 6 and later for the Safari browser
Android 4.0 or later, Samsung GS3 or later phones, Samsung Galaxy Note 2 or later tablets
Scenario prerequisites
Subscription to Office 365 or Azure Active Directory Premium
An Azure Active Directory tenant
Windows Server Active Directory (Windows Server 2008 or later)
Updated schema in Windows Server 2012 R2
License for Azure Active Directory Premium
Windows Server 2012 R2 Federation Services, configured for SSO to Azure AD
Windows Server 2012 R2 Web Application Proxy
Microsoft Azure Active Directory Connect (Azure AD Connect) (Download Azure AD Connect)
Verified domain
Known issues in this release

Device-based conditional access policies require device object writeback to Active Directory from Azure Active
Directory. It can take up to three hours for device objects to be written back to Active Directory.
iOS 7 devices always prompt the user to select a certificate during client certificate authentication.
Some versions of iOS 8 before iOS 8.3 do not work.
Scenario assumptions
This scenario assumes that you have a hybrid environment consisting of an Azure AD tenant and an on-premises
Active Directory. These tenants should be connected with Azure AD Connect, with a verified domain, and with AD FS
for SSO. Use the following checklist to help you configure your environment according to the requirements.
Checklist: Prerequisites for conditional access scenario

Connect your Azure AD tenant with your on-premises Active Directory instance.
Configure Azure Active Directory device registration service

Use this guide to deploy and configure the Azure Active Directory device registration service for your organization.
This guide assumes that you've configured Windows Server Active Directory and have subscribed to Microsoft
Azure Active Directory. See the prerequisites described earlier.
To deploy the Azure Active Directory device registration service with your Azure Active Directory tenant, complete
the tasks in the following checklist in order. When a reference link takes you to a conceptual topic, return to this
checklist afterward, so that you can proceed with the remaining tasks. Some tasks include a scenario validation step
that can help you confirm whether the step was completed successfully.
Part 1: Enable Azure Active Directory device registration

Follow the steps in the checklist to enable and configure the Azure Active Directory device registration service.
TASK REFERENCE
Enable device registration in your Azure Active Directory Enable Azure Active Directory device registration
tenant to allow devices to join the workplace. By default, Azure
Multi-Factor Authentication is not enabled for the service.
However, we recommend that you use Multi-Factor
Authentication when you register a device. Before enabling
Multi-Factor Authentication in Active Directory registration
service, ensure that AD FS is configured for a Multi-Factor
Authentication provider.
Devices discover your Azure Active Directory device Configure Azure Active Directory device registration discovery
registration service by looking for well-known DNS records.
Configure your company DNS so that devices can discover
your Azure Active Directory device registration service.
Part 2: Deploy and configure Windows Server 2012 R2 Active Directory

Federation Services and set up a federation relationship with Azure AD
TASK REFERENCE
Deploy Active Directory Domain Services with the Windows Upgrade your Active Directory Domain Services schema
Server 2012 R2 schema extensions. You do not need to
upgrade any of your domain controllers to Windows Server
2012 R2. The schema upgrade is the only requirement.
Devices discover your Azure Active Directory device Prepare your Active Directory support devices
registration service by looking for well-known DNS records.
Configure your company DNS so that devices can discover
your Azure Active Directory device registration service.
Part 3: Enable device writeback in Azure AD
TASK REFERENCE
Complete part two of "Enabling device writeback in Azure AD Enabling device writeback in Azure AD Connect
Connect." After you finish it, return to this guide.
[Optional] Part 4: Enable Multi-Factor Authentication

We strongly recommended that you configure one of the several options for Multi-Factor Authentication. If you
want to require Multi-Factor Authentication, see Choose the Multi-Factor Authentication security solution for you. It
includes a description of each solution, and links to help you configure the solution of your choice.
Part 5: Verification
The deployment is now complete, and you can try out some scenarios. Use the following links to experiment with
the service and become familiar with its features.
TASK REFERENCE
Join some devices to your workplace by using Azure Active Join devices to your workplace using Azure Active Directory
Directory device registration service. You can join iOS, device registration service
Windows, and Android devices.
View and enable or disable registered devices by using the Azure Active Directory device registration service overview
administrator portal. In this task, you view some registered
devices by using the administrator portal.
Verify that device objects are written back from Azure Active Verify registered devices are written back to Active Directory
Directory to Windows Server Active Directory.
Now that users can register their devices, you can create Create an application access policy and custom access-denied
application access polices in AD FS that allow only registered message
devices. In this task, you create an application access rule and
a custom access-denied message.
Integrate Azure Active Directory with on-premises Active Directory

See:
Integrate your on-premises directories with Azure Active Directory - to review conceptual information.
Custom installation of Azure AD Connect - for installation instructions.
Upgrade your Active Directory Domain Services schema

NOTE
After you upgrade your Active Directory schema, the process cannot be reversed. We recommend that you first perform the
upgrade in a test environment.
1. Sign in to your domain controller with an account that has both enterprise administrator and schema
administrator rights.
2. Copy the [media]\support\adprep directory and subdirectories to one of your Active Directory domain
controllers (where [media] is the path to the Windows Server 2012 R2 installation media).
3. From a command prompt, go to the adprep directory and run adprep.exe /forestprep. Follow the onscreen
instructions to complete the schema upgrade.
Prepare your Active Directory to support devices

NOTE
This is a one-time operation that you must run to prepare your Active Directory forest to support devices. To complete this
procedure, you must be signed in with enterprise administrator permissions and your Active Directory forest must have the
Windows Server 2012 R2 schema.
Prepare your Active Directory forest

1. On your federation server, open a Windows PowerShell command window, and then type Initialize-
ADDeviceRegistration.
2. When prompted for ServiceAccountName, enter the name of the service account you selected as the service
account for AD FS. If it's a gMSA account, enter the account in the domain\accountname$ format. For a
domain account, use the format domain\accountname.
Enable device authentication in AD FS
1. On your federation server, open the AD FS management console and go to AD FS > Authentication Policies.
2. On the Actions pane, select Edit Global Primary Authentication.
3. Check Enable device authentication, and then select OK.
4. By default, AD FS periodically removes unused devices from Active Directory. Disable this task when you're
using Azure Active Directory device registration service so that devices can be managed in Azure.
Disable unused device cleanup
On your federation server, open a Windows PowerShell command window, and then type Set-
AdfsDeviceRegistration -MaximumInactiveDays 0.
Prepare Azure AD Connect for device writeback
Complete part 1: Prepare Azure AD Connect.
Join devices to your workplace by using Azure Active Directory device

registration service
Join an iOS device by using Azure Active Directory device registration
Azure Active Directory device registration uses the Over-the-Air Profile enrollment process for iOS devices. This
process begins when the user connects to the profile enrollment URL with Safari. The URL format is as follows:
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/"yourdomainname"
In this case, yourdomainname is the domain name that you configured with Azure Active Directory. For example, if
your domain name is contoso.com, the URL is as follows:
https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/contoso.com
There are many different ways to communicate this URL to your users. For example, one method we recommend is
publishing this URL in a custom application access-denied message in AD FS. This information is covered in the
upcoming section Create an application access policy and custom access-denied message.
Join a Windows 8.1 device by using Azure Active Directory device registration
1. On your Windows 8.1 device, select PC Settings > Network > Workplace.
2. Enter your user name in UPN format; for example, dan@contoso.com.
3. Select Join.
4. When prompted, sign in with your credentials. The device is now joined.
Join a Windows 7 device by using Azure Active Directory device registration
To register Windows 7 domain-joined devices, you need to deploy the device registration software package.
For instructions about how to use the package, see Windows Installer packages for non-Windows 10 computers.
Verify that registered devices are written back to Active Directory

You can view and verify that your device objects have been written back to your Active Directory by using LDP.exe
or ADSI Edit. Both are available with the Active Directory administrator tools.
By default, device objects that are written back from Azure Active Directory are placed in the same domain as your
AD FS farm.
CN=RegisteredDevices,defaultNamingContext
Create an application access policy and custom access-denied message

Consider the following scenario: You create an application Relying Party Trust in AD FS and configure an Issuance
Authorization Rule that allows only registered devices. Now only devices that are registered are allowed to access
the application.
To make it easy for your users to gain access to the application, you configure a custom access-denied message that
includes instructions for how to join their device. Now your users have a seamless way to register their devices so
they can access an application.
The following steps show you how to implement this scenario.
NOTE
This section assumes that you have already configured a Relying Party Trust for your application in AD FS.
1. Open the AD FS MMC tool, and then select AD FS > Trust Relationships > Relying Party Trusts.
2. Locate the application to which this new access rule applies. Right-click the application, and then select Edit
Claim Rules.
3. Select the Issuance Authorization Rules tab, and then select Add Rule.
4. From the Claim rule template drop-down list, select Permit or Deny Users Based on an Incoming Claim.
Then select Next.
5. In the Claim rule name field, type Permit access from registered devices.
6. From the Incoming claim type drop-down list, select Is Registered User.
7. In the Incoming claim value field, type true.
8. Select the Permit access to users with this incoming claim radio button.
9. Select Finish, and then select Apply.
10. Remove any rules that are more permissive than the rule you created. For example, remove the default rule
Permit Access to all Users.
Your application is now configured to allow access only when the user is coming from a device that they registered
and joined to the workplace. For more advanced access polices, see Manage Risk with Additional Multi-Factor
Authentication for Sensitive Applications.
Next, you configure a custom error message for your application. The error message lets users know that they must
join their device to the workplace before they can access the application. You can create a custom application
access-denied message by using custom HTML and PowerShell.
On your federation server, open a PowerShell command window, and then type the following command. Replace
portions of the command with items that are specific to your system:
Set-AdfsRelyingPartyWebContent -Name "relying party trust name" -ErrorPageAuthorizationErrorMessage
You must register your device before you can access this application.
If you are using an iOS device, select this link to join your device:
a href='https://enterpriseregistration.windows.net/enrollmentserver/otaprofile/yourdomain.com
Join this iOS device to your workplace.

If you are using a Windows 8.1 device, you can join your device by selecting PC Settings> Network > Workplace.
In the preceding commands, relying party trust name is the name of your application's Relying Party Trust object
in AD FS. And yourdomain.com is the domain name that you have configured with Azure Active Directory (for
example, contoso.com). Be sure to remove any line breaks (if any) from the HTML content that you pass to the Set-
AdfsRelyingPartyWebContent cmdlet.
Now when users access your application from a device that's not registered with the Azure Active Directory device
registration service, they see an error.
Join a new Windows 10 device with Azure AD during
a first run
resources from devices that meet your standards for security and compliance. For more details, see the introduction
to device management in Azure Active Directory.
With Windows 10, You can join a new device to Azure AD during the first-run experience (FRX).
This enables you to distribute shrink-wrapped devices to your employees or students.
If you have either Windows 10 Professional or Windows 10 Enterprise installed on a device, the experience defaults
to the setup process for company-owned devices.
In the Windows out-of-box experience, joining an on-premises Active Directory (AD) domain is not supported. If
you plan to join a computer to an AD domain, during setup, you should select the link Set up Windows with a
local account. You can then join the domain from the settings on your computer.
Before you begin

To join a Windows 10 device, the device registration service must be configured to enable you to register devices. In
addition to having permission to joining devices in your Azure AD tenant, you must have fewer devices registered
than the configured maximum. For more details, see configure device settings.
Joining a device
To join a Windows 10 device to Azure AD during FRX:
1. When you turn on your new device and start the setup process, you should see the Getting Ready message.
Follow the prompts to set up your device.
2. Start by customizing your region and language. Then accept the Microsoft Software License Terms.
3. Select the network you want to use for connecting to the Internet.
4. Click This device belongs to my organization.
5. Enter the credentials that were provided to you by your organization, and then click Sign in.
6. You device locates a matching tenant in Azure AD. If you are in a federated domain, you are redirected to
your on-premises Secure Token Service (STS) server, for example, Active Directory Federation Services (AD
FS).
7. If you are a user in a non-federated domain, enter your credentials directly on the Azure AD-hosted page.
8. You are prompted for a multi-factor authentication challenge.
9. Azure AD checks whether an enrollment in mobile device management is required.
10. Windows registers the device in the organization’s directory in Azure AD and enrolls it in mobile device
management, if applicable.
11. If you are:
A managed user, Windows takes you to the desktop through the automatic sign-in process.
A federated user, you are directed to the Windows sign-in screen to enter your credentials.
Verification
To verify whether a device is joined to your Azure AD, review the Access work or school dialog on your Windows
device. The dialog should indicate that you are connected to your Azure AD directory.
Next steps
For more details, see the introduction to device management in Azure Active Directory.
For more details about managing devices in the Azure AD portal, see managing devices using the Azure
portal.
Troubleshooting hybrid Azure Active Directory joined
Windows 10 and Windows Server 2016 devices
This topic is applicable to the following clients:

Windows 10
Windows Server 2016
For other Windows clients, see Troubleshooting hybrid Azure Active Directory joined down-level devices.
This topic assumes that you have configured hybrid Azure Active Directory joined devices to support the following
scenarios:
Device-based conditional access
Enterprise roaming of settings
Windows Hello for Business
This document provides troubleshooting guidance on how to resolve potential issues.
For Windows 10 and Windows Server 2016, hybrid Azure Active Directory join supports the Windows 10
November 2015 Update and above. We recommend using the Anniversary update.
Step 1: Retrieve the join status

To retrieve the join status:
1. Open the command prompt as an administrator
2. Type dsregcmd /status
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined: YES
EnterpriseJoined: NO
DeviceId: 5820fbe9-60c8-43b0-bb11-44aee233e4e7
Thumbprint: B753A6679CE720451921302CA873794D94C6204A
KeyContainerId: bae6a60b-1d2f-4d2a-a298-33385f6d05e9
KeyProvider: Microsoft Platform Crypto Provider
TpmProtected: YES
KeySignTest: : MUST Run elevated to test.
Idp: login.windows.net
TenantId: 72b988bf-86f1-41af-91ab-2d7cd011db47
TenantName: Contoso
AuthCodeUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/authorize
AccessTokenUrl: https://login.microsoftonline.com/msitsupp.microsoft.com/oauth2/token
MdmUrl: https://enrollment.manage-beta.microsoft.com/EnrollmentServer/Discovery.svc
MdmTouUrl: https://portal.manage-beta.microsoft.com/TermsOfUse.aspx
dmComplianceUrl: https://portal.manage-beta.microsoft.com/?portalAction=Compliance
SettingsUrl:
eyJVcmlzIjpbImh0dHBzOi8va2FpbGFuaS5vbmUubWljcm9zb2Z0LmNvbS8iLCJodHRwczovL2thaWxhbmkxLm9uZS5taWNyb3NvZnQuY29tLyJ
dfQ==
JoinSrvVersion: 1.0
JoinSrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId: urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion: 1.0
KeySrvUrl: https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId: urn:ms-drs:enterpriseregistration.windows.net
DomainJoined: YES
DomainName: CONTOSO
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet: YES
NgcKeyId: {C7A9AEDC-780E-4FDA-B200-1AE15561A46B}
WorkplaceJoined: NO
WamDefaultSet: YES
WamDefaultAuthority: organizations
WamDefaultId: https://login.microsoft.com
WamDefaultGUID: {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
AzureAdPrt: YES
Step 2: Evaluate the join status

Review the following fields and make sure that they have the expected values:
AzureAdJoined : YES
This field indicates whether the device is joined with Azure AD. If the value is NO, the join to Azure AD has not
completed yet.
Possible causes:
Authentication of the computer for a join failed.
There is an HTTP proxy in the organization that cannot be discovered by the computer
The computer cannot reach Azure AD to authenticate or Azure DRS for registration
The computer may not be on the organization’s internal network or on VPN with direct line of sight to an
on-premises AD domain controller.
If the computer has a TPM, it can be in a bad state.
There might be a misconfiguration in the services noted in the document earlier that you will need to verify
again. Common examples are:
Your federation server does not have WS-Trust endpoints enabled
Your federation server does not allow inbound authentication from computers in your network using
Integrated Windows Authentication.
There is no Service Connection Point object that points to your verified domain name in Azure AD in
the AD forest where the computer belongs to
DomainJoined : YES
This field indicates whether the device is joined to an on-premises Active Directory or not. If the value is NO, the
device cannot perform a hybrid Azure AD join.
WorkplaceJoined : NO
This field indicates whether the device is registered with Azure AD as a personal device (marked as Workplace
Joined). This value should be NO for a domain-joined computer that is also hybrid Azure AD joined. If the value is
YES, a work or school account was added prior to the completion of the hybrid Azure AD join. In this case, the
account is ignored when using the Anniversary Update version of Windows 10 (1607).
WamDefaultSet : YES and AzureADPrt : YES

These fields indicate whether the user has successfully authenticated to Azure AD when signing in to the device. If
the values are NO, it could be due:
Bad storage key (STK) in TPM associated with the device upon registration (check the KeySignTest while
running elevated).
Alternate Login ID
HTTP Proxy not found
Next steps
For questions, see the device management FAQ
Troubleshooting hybrid Azure Active Directory joined
down-level devices
This topic is applicable only to the following devices:

Windows 7
Windows 8.1
Windows Server 2012
For Windows 10 or Windows Server 2016, see Troubleshooting hybrid Azure Active Directory joined Windows 10
and Windows Server 2016 devices.
This topic assumes that you have configured hybrid Azure Active Directory joined devices to support the following
scenarios:
Device-based conditional access
Enterprise roaming of settings
This topic provides you with troubleshooting guidance on how to resolve potential issues.
What you should know:
The maximum number of devices per user is device-centric. For example, if jdoe and jharnett sign-in to a
device, a separate registration (DeviceID) is created for each of them in the USER info tab.
The initial registration / join of devices is configured to perform an attempt at either logon or lock / unlock.
There could be 5-minute delay triggered by a task scheduler task.
A reinstall of the operating system or a manual unregister and re-register may create a new registration on
Azure AD and results in multiple entries under the USER info tab in the Azure portal.
Step 1: Retrieve the registration status

To verify the registration status:
1. Open the command prompt as an administrator
2. Type "%programFiles%\Microsoft Workplace Join\autoworkplace.exe /i"
This command displays a dialog box that provides you with more details about the join status.
Step 2: Evaluate the hybrid Azure AD join status
If the hybrid Azure AD join was not successful, the dialog box provides you with details about the issue that has
occurred.
The most common issues are:
A misconfigured AD FS or Azure AD
You are not signed on as a domain user
A quota has been reached
The service is not responding

You can also find the status information in the event log under Applications and Services Log\Microsoft-
Workplace Join.
The most common causes for a failed hybrid Azure AD join are:
Your computer is not on the organization’s internal network or a VPN without connection to an on-premises
AD domain controller.
You are logged on to your computer with a local computer account.
Service configuration issues:
The federation server has been configured to support WIAORMULTIAUTHN.
There is no Service Connection Point object that points to your verified domain name in Azure AD in
the AD forest where the computer belongs to.
A user has reached the limit of devices.
Next steps
For questions, see the device management FAQ
Managing Applications with Azure Active Directory
Beyond the actual workflow or content, businesses have two basic requirements for all applications:
1. To increase productivity, applications should be easy to discover and access
2. To enable security and governance, the organization needs control and oversight on who can and actually is
accessing each application
In the world of cloud applications this can best be achieved using identity to control “WHO is allowed to do WHAT”.
In computing terminology:
Who is known as identity - the management of users and groups
What is known as access management – the management of access to protected resources
Both components together are known as Identity and Access Management (IAM), which is defined by the Gartner
group as “the security discipline that enables the right individuals to access the right resources at the right times for
the right reasons”.
Okay, so what’s the problem? If IAM is not managed in one place with an integrated solution:
Identity administrators have to individually create and update user accounts in all applications separately, a
redundant and time consuming activity.
Users have to memorize multiple credentials to access the applications they need to work with. As a result, users
tend to write down their passwords or use other password management solutions which introduces other data
security risks.
Redundant, time consuming activities reduce the amount of time users and administrators are working on
business activities that increase your business’s bottom line.
So, what generally prevents organizations from adopting integrated IAM solutions?
Most technical solutions are based on software platforms that need to be deployed and adapted by each
organization for their own applications.
Cloud applications are often adopted at a higher rate than IT organization can integrate with existing IAM
solutions.
Security and monitoring tooling require additional customization and integration to achieve comprehensive E2E
scenarios.
Azure Active Directory integrated with applications

Azure Active Directory is Microsoft’s comprehensive Identity as a Service (IDaaS) solution that:
Enables IAM as a cloud service
Provides central access management, single-sign on (SSO), and reporting
Supports integrated access management for thousands of applications in the application gallery, including
Salesforce, Google Apps, Box, Concur, and more.
With Azure Active Directory, all applications you publish for your partners and customers (business or consumer)
have the same identity and access management capabilities.
This enables you to significantly reduce your operational costs.
What if you need to implement an application that is not yet listed in the application gallery? While this is a bit
more time-consuming than configuring SSO for applications from the application gallery, Azure AD provides you
with a wizard that helps you with the configuration.
The value of Azure AD goes beyond “just” cloud applications. You can also use it with on-premises applications by
providing secure remote access. With secure remote access, you can eliminate the the need for VPNs or other
traditional remote access management implementations.
By providing central access management and single sign on (SSO) for all your applications, Azure AD provides the
solution to the main data security and productivity problems.
Users can access multiple applications with one sign on giving more time to income generating or business
operations activities done.
Identity administrators can manage access to applications in one place.
The benefit for the user and for your company is obvious. Let’s take a closer look at the benefits for an identity
administrator and the organization.
Integrated application benefits

The SSO process has two steps:
Authentication, the process of validating the user’s identity.
Authorization, the decision to enable or block access to a resource with an access policy.
When using Azure AD to manage applications and enable SSO:
Authentication is done on the user’s on-premises (e.g. AD) or Azure AD account.
Authorization executes on the Azure AD assignment and protection policy ensuring consistent end user
experience and enabling you to add assignment, locations, and MFA conditions on any application, regardless of
its internal capabilities.
It important to understand that the way the authorization is enacted on the target application varies depending on
how the application was integrated with Azure AD.
Applications pre-integrated by service provider Like Office 365 and Azure, these are applications built
directly on Azure AD and relying on it for their comprehensive identity and access management capabilities.
Access to these applications is enabled through directory information and token issuance.
Applications pre-integrated by Microsoft and custom applications These are independent cloud
applications that rely on an internal application directory and can operate independently of Azure AD. Access to
these applications is enabled by issuing an application specific credential mapped to an application account.
Depending on the application capabilities, the credential may be a federation token or user-name and password
for an account that was previously provisioned in the application.
On-premises applications Applications published through the Azure AD application proxy primarily enabling
access to on-premises applications. These applications rely on a central on-premises directory like Windows
Server Active Directory. Access to these applications is enabled by triggering the proxy to deliver the application
content to the end user while honoring the on-premises sign-on requirement.
For example, if a user joins your organization, you need to create an account for the user in Azure AD for the
primary sign-on operations. If this user requires access to a managed application such as Salesforce, you also need
to create an account for this user in Salesforce and link it to the Azure account to make SSO work. When the user
leaves your organization, it is advisable to delete the Azure AD account and all counterpart accounts in the IAM
stores of the applications the user had access to.
Access detection
In modern enterprises, IT departments are often not aware of all the cloud applications that are being used. In
conjunction with Cloud App Discovery, Azure AD provides you with a solution to detect these applications.
Account management
Traditionally, managing accounts in the various applications is a manual process performed by IT or support
personal in the organization. Azure AD fully automated account management across all service provider integrated
applications and those applications pre-integrated by Microsoft supporting automated user provisioning or SAML
JIT.
Automated user provisioning

Some applications provide automation interfaces for creation and removal (or deactivation) of accounts. If a
provider offers such an interface, it is leveraged by Azure AD. This reduces your operational costs because
administrative tasks happen automatically, and improves the security of your environment because it decreases the
chance of unauthorized access.
Access management
Using Azure AD you can manage access to applications using individual or rule driven assignments. You can also
delegate access management to the right people in the organization ensuring the best oversight and reducing the
burden on helpdesk.
On-premises applications
The built in application proxy enables you to publish your on-premises applications to your users resulting in both
consistent access experience with modern cloud application and the benefits from Azure AD monitoring, reporting,
and security capabilities.
Reporting and monitoring

Azure AD provides you with pre-integrated reporting and monitoring capabilities that enable you to know who has
access to applications and when they actually used them.
Related capabilities
With Azure AD you can secure your applications with granular access policies and pre-integrated MFA. To learn
more about Azure MFA see Azure MFA.
Getting started
To get started integrating applications with Azure AD, take a look at the Integrating Azure Active Directory with
applications getting started guide.
See also
Integrating Azure Active Directory with applications
getting started guide
Overview
This topic is intended to give you a roadmap for integrating applications with Azure Active Directory (AD). Each of
the sections below contain a brief summary of a more detailed topic so you can identify which parts of this getting
started guide are relevant to you. Follow the links for a deeper dive on each subject.
Before you begin, take inventory

Before you jump in to integrating applications with Azure AD, it is important to know where you are and where you
want to go. The following questions are intended to help you think about your Azure AD application integration
project.
Application inventory
Where are all of your applications? Who owns them?
What kind of authentication do your applications require?
Who needs access to which applications?
Do you want to deploy a new application?
Will you build it in-house and deploy it on an Azure compute instance?
Will you use one that is available in the Azure Application Gallery?
User and group inventory
Where do your user accounts reside?
On-premises Active Directory
Azure AD
Within a separate application database that you own
In unsanctioned applications
All of the above
What permissions and role assignments do individual users currently have? Do you need to review their access
or are you sure that your user access and role assignments are appropriate now?
Are groups already established in your on-premises Active Directory?
How are your groups organized?
Who are the group members?
What permissions/role assignments do the groups currently have?
Will you need to clean up user/group databases before integrating? (This is a pretty important question.
Garbage in, garbage out.)
Access management inventory
How do you currently manage user access to applications? Does that need to change? Have you considered
other ways to manage access, such as with RBAC for example?
Who needs access to what?
Maybe you don't have the answers to all of these questions up front but that's okay. This guide can help you
answer some of those questions and make some informed decisions.
Prerequisites
An Azure subscription and an Azure Active Directory directory. If you don't already have an Azure subscription,
you can try out Azure for free for 30 days. Try it out!
Application integration with Azure AD

Finding unsanctioned cloud applications with Cloud App Discovery
As mentioned above, there may be applications that haven't been managed by your organization until now. As part
of the inventory process, it is possible to find unsanctioned cloud applications. See Finding unsanctioned cloud
applications with Cloud App Discovery.
Authentication Types
Each of your applications may have different authentication requirements. With Azure AD, signing certificates can
be used with applications that use SAML 2.0, WS-Federation, or OpenID Connect Protocols as well as Password
Single Sign On. For more information about application authentication types for use with Azure AD see Managing
Certificates for Federated Single Sign-On in Azure Active Directory and Password based single sign on.
Enabling SSO with Azure AD App Proxy
With Microsoft Azure AD Application Proxy, you can provide access to applications located inside your private
network securely, from anywhere and on any device. After you have installed an application proxy connector within
your environment, it can be easily configured with Azure AD.
Integrating applications with Azure AD
The following articles discuss the different ways applications integrate with Azure AD, and provide some guidance.
Determining which Active Directory to use
Using applications in the Azure application gallery
Integrating SaaS applications tutorials list
Managing access to applications

The following articles describe ways you can manage access to applications once they have been integrated with
Azure AD using Azure AD Connectors and Azure AD.
Managing access to apps using Azure AD
Automating with Azure AD Connectors
Assigning users to an application
Assigning groups to an application
Sharing accounts
Integrating custom applications

If you are writing a new application and want to assist developers in leveraging the power Azure AD, see Guiding
developers.
If you want to add your custom application to the Azure Application Gallery, see “Bring your own app” with Azure
AD Self-Service SAML configuration.
See also
SaaS application integration with Azure Active
Directory
To help integrate your cloud-enabled (SaaS) applications with Azure Active Directory, we have developed a
collection of tutorials that walk you through configuration.
Where we have user provisioning guidance, we have included an application tutorial for user provisioning in the
right column, next to the application tutorial.
For the comprehensive list of SaaS apps that have been pre-integrated into Azure AD, see the Active Directory
Marketplace.
SaaS tutorials
APPLICATION TUTORIAL FOR SINGLE SIGN- APPLICATION TUTORIAL FOR USER
LOGO ON PROVISIONING
&frankly
@Task
10,000ft Plans
123ContactForm
15Five
23 Video
360 Online
8x8 Virtual Office

Abintegro
Absorb LMS
Accredible
Achieve3000
Adaptive Suite
Adobe Creative Cloud
Adobe EchoSign
Adobe Experience Manager
ADP eTime
ADP GlobalView
Agiloft
Aha!
AirWatch
Alcumus Info Exchange
Allocadia
Amazon Web Services (AWS)
Anaplan
AnswerHub
Apex Portal
AppBlade
AppDynamics
Apptio
Aravo
ArcGIS
Ariba
Asana
ASC Contracts
Asset Bank
Atlassian Cloud
Atomic Learning
Autotask
Bamboo HR
Bambu by Sprout Social
BC in the Cloud
BeeLine
BenefitHub
Benefitsolver
BenSelect
BetterWorks
BGS Online
Bime
Birst Agile Business Analytics
Blackboard Learn - Shibboleth
Blackboard Learn
BlueJeans
Bonus.ly
Boomi
Box Box - User Provisioning
Bpm’online
Bridge
Brightspace by Desire2Learn
BritaBIZ
Bynder
CA PPM
Canvas LMS
Capriza
Central Desktop
Ceridian Dayforce HCM
Cerner Central - Single Sign On Cerner Central - User Provisioning
Certify
Cezanne HR Software
Cherwell
Chromeriver
Cimpl
Cisco Spark
Cisco Webex
Citrix GoToMeeting Citrix GoToMeeting - User Provisioning
Citrix ShareFile
Clarizen
ClearCompany
Clear Review
Clever
ClickTime
CloudPassage
Collaborative Innovation
Communifire
Competency IQ
Compliance ELF
Concur Concur - User Provisioning
Condeco
Convercent
Cornerstone OnDemand
Coupa
CS Stars
DATABASICS
Datahug
Dealpath
Degreed
Deputy
DigiCert
Direct
Directions on Microsoft
DocuSign DocuSign - User Provisioning
Domo
Dow Jones Factiva
Dropbox for Business Dropbox for Business - User

Provisioning
Druva
EasyTerritory
Edcor
eDigitalResearch
EFI Digital StoreFront
Egnyte
eKincare
EmpCenter
Encompass
Envoy
EthicsPoint Incident Management

(EPIM)
eTouches
EverBridge
Evernote
Evidence.com
Expensify
FactSet
Fieldglass
FileCloud
FilesAnywhere
FirmPlay - Employee Advocacy for

Recruiting
Five9 Plus Adapter (CTI, Contact Center

Agents)
Flatter Files
FM:Systems
Form.com
FreshDesk
FreshGrade
FreshService
Front
Fuse
Fuze
GaggleAMP
Gigya
GitHub
Google Apps Google Apps - User Provisioning
Getabstract
Greenhouse
Grovo
HackerOne
Halogen Software
Halosys
HappyFox
Help Scout
Heroku
Hightail
HireVue
Hosted Graphite
HPE SaaS
HR2day by Merces
Huddle
IBM Kenexa Survey Enterprise
IBM OpenPages
Icertis Contract Management Platform
ICIMS
IdeaScale
Igloo Software
iLMS
Image Relay
IMAGE WORKS
IMPAC Risk Manager

Infor Retail – Information Management
Inkling
Innotas
InsideView
Insignia SAML SSO
Insperity ExpensAble
Intacct
InTime
Intralinks
IQNavigator VMS
iQualify LMS
IriusRisk
itslearning
ITRP
Jitbit Helpdesk
Jive Jive - User Provisioning
Jobbadmin
Jobscience
JobScore
Jostle
Kantega SSO for Bamboo
Kantega SSO for Bitbucket
Kantega SSO for Confluence
Kantega SSO for FishEye/Crucible
Kantega SSO for JIRA
Keeper Password Manager

Keylight
Kindling
Kintone
Kiteworks
Klue
KnowBe4
Kontiki
Kronos
Kudos
Land Gorilla Client
LCVista
Learning at Work
Learningpool
LearnUpon
Lecorpio
Lesson.ly
Lifesize Cloud
LinkedIn Elevate LinkedIn Elevate - User Provisioning
LinkedIn Learning LinkedIn Learning - User Provisioning
LinkedIn Sales Navigator LinkedIn Sales Navigator - User

Provisioning
LiquidFiles
Litmos
LogicMonitor
Lucidchart
Lynda.com
Marketo
MaxxPoint
MCM
Menlo Security
Mercer BenefitsCentral
MerchLogix
M-Files
Mimecast Admin Console
Mimecast Personal Portal
Mindflash
Mixpanel
MOBI
MobileIron
MobileXpense
MOVEit Transfer
Moxi Engage
Moxtra
Mozy Enterprise
myPolicies
Namely
Neota Logic Studio
NetDocuments
Netsuite Netsuite - User Provisioning
New Relic
New Signature Cloud Management

Portal for Microsoft Azure
Nexonia
Nomadesk
Nomadic
Novatus
O. C. Tanner - AppreciateHub
OfficeSpace Software
Oneteam
Onit
OnTrack
OneTrust Privacy Management

Software
OpenAthens
OpsGenie
Optimizely
Origami
Overdrive Books
Pacific Timesheet
Pagerduty
Panopto
Panorama9
Pantheon
Pega Systems
People
Peoplecart
Perception United States (Non-UltiPro)
PerformanceCentre
Picturepark
Pingboard
PlanMyLeave
Pluralsight
PolicyStat
PostBeyond
Predictix Assortment Planning
Predictix Ordering
Predictix Price Reporting
Printix
Procore SSO
Projectplace
Promapp
Proofpoint on Demand
PurelyHR
Qlik Sense Enterprise

QPrism
Qualtrics
Questetra BPM Suite
QuickHelp
Rally Software
RealtimeBoard
Recognize
RedVector
Reflektive
Replicon
Reward Gateway
RFPIO
RightAnswers
RightScale
RolePoint
Rollbar
RunMyProcess
Salesforce Sandbox Salesforce Sandbox - User Provisioning
Salesforce Salesforce - User Provisioning
Samanage
SAML SSO for Confluence by resolution

GmbH
SAML SSO for Jira by resolution GmbH
SanSan
SAP Business ByDesign
SAP BusinessObjects Cloud
SAP Cloud for Customer

SAP HANA
SAP HANA Cloud Platform Identity

Authentication
SAP HANA Cloud Platform
SAP NetWeaver
ScaleX Enterprise
SCC LifeCycle
Schoox
Sciforma
SciQuest Spend Director
ScreenSteps
SD Elements
SECURE DELIVER
SensoScientific Wireless Temperature

Monitoring System
ServiceChannel
ServiceNow
ShiftPlanning
Shmoop For Schools
Showpad
SilkRoad Life Suite
SimpleNexus
Skilljar
Skillport
Skills Manager
SkyDesk Email
Slack Slack - User Provisioning
Small Improvements
SmartRecruiters
SmarterU
Softeon WMS
Soonr Workplace
SpaceIQ
Splunk Enterprise and Splunk Cloud
SpringCM
Springer Link
Sprinklr
StatusPage
SuccessFactors
SugarCRM
SumoLogic
SumTotalCentral
Symantec Web Security Service (WSS)
Syncplicity
Synergi
T&E Express
Tableau Online
Tableau Server
TalentLMS
Tango Analytics
Tangoe Command Premium Mobile
TargetProcess
Teamphoria
TeamSeer
Teamwork
TextMagic
The Funding Portal
ThirdLight
Thoughtworks Mingle
ThousandEyes
Tidemark
TigerText Secure Messenger
TimeLive
TimeOffManager
Tinfoil Security
TiViTz
TOPdesk - Public
TOPdesk - Secure
Trakopolis
Trakstar
Trello
TurboRater
UltiPro
UNIFI
UserEcho
UserVoice
Velpic SAML
Veracode
Veritas Enterprise Vault.cloud SSO
Versal
Vodeclic
Voyance
vxMaintain
Wdesk
Weekdone
Wikispaces
Wingspan eTMF
Wizergos Productivity Software
Work.com
Workday Workday - User Provisioning
Workplace by Facebook Workplace by Facebook - User

Provisioning
Workfront
Workpath
Workrite
WORKS MOBILE
Workstars
XaitPorter
xMatters OnDemand
Yardi eLearning
Yonyx Interactive Guides
YouEarnedIt
Zendesk
ZIVVER
Zoho Mail
Zoom
Zscaler Beta
Zscaler One
Zscaler Private Access (ZPA)
Zscaler Two
Zscaler ZSCloud
Zscaler
Related articles
List of Tutorials on How to Integrate SaaS Apps
Set up Cloud App Discovery in Azure AD
Cloud App Discovery in Azure AD is now based on integration with data available from Microsoft Cloud App
Security. To provide ongoing information on cloud use and shadow IT, Cloud App Discovery compares your traffic
logs to the Cloud App Security catalog of over 15,000 cloud apps. This article describes the setup process and
contains links to the detailed information for each step. It also describes firewall and proxy information and log file
support.
Prerequisites
Your organization must have an Azure AD Premium P1 license to use the product. For more information, see
Azure Active Directory pricing.
To set up Cloud App Discovery, you must be a Global Administrator or a Security Reader in Azure Active
Directory.
Setup steps
1. Set up snapshot reports to check your log format make sure your logs provide usable information to Cloud
App Discovery. They can also provide ad-hoc visibility into traffic logs you manually upload from your
firewalls and proxy servers.
2. Set up continuous reporting to analyze all logs that are forwarded from your network using the Cloud App
Security log collector. You can use them to identify new apps and usage trends.
3. If your logs are not currently supported, set up a custom log parser so that Cloud App Discovery can analyze
them.
Log processing flow

It can take anywhere from a few minutes to several hours to generate reports depending on the amount of data.
Here's what is analyzed:
Upload Web traffic logs from your network are uploaded to the portal.
Parse Cloud App Security parses and extracts traffic data from the traffic logs with a dedicated parser for each
data source.
Analyze Traffic data is analyzed against the Cloud App Security catalog to identify more than 15,000 cloud
apps. Active users and IP addresses are also identified as part of the analysis.
Generate report Cloud App Security generates a report of the data extracted from log files and makes it
available to Cloud App Discovery.
NOTE
Continuous report data is analyzed twice a day.
The log collector compresses data before it is uploaded. The outbound traffic on the log collector is around 10% of the
size of the received traffic logs.
Using traffic logs for Cloud App Discovery

Cloud App Discovery uses the data in your traffic logs. The more detail you can add in your log, the better visibility
you get. Cloud App Discovery requires web-traffic data with the following attributes:
Date of the transaction
Source IP address
Source user recommended
Destination IP address
Destination URL recommended (URLs provide more accuracy for cloud app detection than IP addresses)
Total amount of data
Amount of uploaded or downloaded data, for insights about patterns of cloud app usage
Action taken (allowed/blocked)
Cloud App Discovery can't show or analyze attributes that are not included in your logs. For example, Cisco ASA
Firewall standard log format does not contain the Amount of uploaded bytes per transaction, Username, or
Target URL but only the destination IP address. Thus, you might have less visibility into the cloud apps from this
data source. For Cisco ASA firewalls, set the information level to 6.1.
In order to successfully generate a Cloud App Discovery report, your traffic logs must meet the following
conditions:
1. Data source is a supported firewall or proxy server.
2. Log format matches the expected standard format. This is checked at upload time. To optimize uour log format,
see Create snapshot Cloud App Discovery reports.
3. Events are not more than 90 days old.
4. The log file is valid and includes outbound traffic information.
Supported firewalls and proxy servers

Barracuda - Web App Firewall (W3C)
Blue Coat Proxy SG - Access log (W3C)
Check Point
Cisco ASA FirePOWER
Cisco ASA Firewall (For Cisco ASA firewalls, set the information level to 6)
Cisco IronPort WSA
Cisco ScanSafe
Cisco Meraki – URLs log
Clavister NGFW (Syslog)
Dell Sonicwall
Fortinet Fortigate
Juniper SRX
Juniper SSG
McAfee Secure Web Gateway
Microsoft Forefront Threat Management Gateway (W3C)
Palo Alto series Firewall
Sophos SG
Sophos Cyberoam
Squid (Common)
Squid (Native)
Websense - Web Security Solutions - Investigative detail report (CSV)
Websense - Web Security Solutions - Internet activity log (CEF)
Zscaler
NOTE
Cloud App Discovery supports both IPv4 and IPv6 addresses.
If your log is not supported, select Other as the Data source and specify the device and log you are trying to
upload. Your log is reviewed by the Cloud App Security cloud analyst team. When support for your log type is
added we notify you, but instead, you can define a custom parser that matches your log format. For more
information, see Use a custom log parser.
Data attributes (according to vendor documentation)

TARGETED APP TARGETED APP ORIGIN IP UPLOADED
DATA SOURCE URL IP ADDRESS USERNAME ADDRESS TOTAL TRAFFIC BYTES
Barracuda Yes Yes Yes Yes No No
Blue Coat Yes No Yes Yes Yes Yes
Checkpoint No Yes No Yes No No
Cisco ASA No Yes No Yes Yes No
Cisco FWSM No Yes No Yes Yes No
Cisco Ironport Yes Yes Yes Yes Yes Yes

WSA
Cisco Meraki Yes Yes No Yes No No
Clavister Yes Yes Yes Yes Yes Yes

NGFW
(Syslog)
Dell SonicWall Yes Yes No Yes Yes Yes
Fortigate No Yes No Yes Yes Yes
Juniper SRX No Yes No Yes Yes Yes
Juniper SSG No Yes No Yes Yes Yes
McAfee SWG Yes No No Yes Yes Yes
MS TMG Yes No Yes Yes Yes Yes
Palo Alto Yes Yes Yes Yes Yes Yes

Networks
Sophos Yes Yes Yes Yes Yes No

TARGETED APP TARGETED APP ORIGIN IP UPLOADED
DATA SOURCE URL IP ADDRESS USERNAME ADDRESS TOTAL TRAFFIC BYTES
Squid Yes No Yes Yes No Yes

(Common)
Squid (Native) Yes No Yes Yes No Yes
Websense - Yes Yes Yes Yes Yes Yes

Investigative
report (CSV)
Websense - Yes Yes Yes Yes Yes Yes

Internet
activity log
(CEF)
Zscaler Yes Yes Yes Yes Yes Yes
Next steps
Use the following links to continue to set up Cloud App Discovery in Azure AD.
Create snapshot reports
Configure continuous reporting
Use a custom log parser
Create Cloud App Discovery snapshot reports
Before setting up the automatic log collector, upload a log manually and let Cloud App Security parse it. If you
don't have a log yet and you want to see a sample of what your log should look like, use the procedure below to
download a sample log file to see what your log is supposed to look like.
To create a snapshot report

1. Collect log files from your firewall and proxy server through which users in your organization access the
Internet. Gather logs during times of peak traffic that are representative of the user activity in your organization.
2. On the Cloud App Security menu bar, select Discover, and then Create snapshot report.
3. Enter a Report name and a Description.

4. Select the Data source from which you want to upload the log files.
5. Verify your log format to make sure that it is formatted properly according to the sample you can
download. Click View and verify and then click Download sample log. Then compare your log with the
sample provided to make sure it's compatible.
NOTE
The FTP sample format is supported in snapshots and automated upload while syslog is supported in automated
upload only. Downloading a sample log downloads a sample FTP log.
6. Choose the traffic logs that you want to upload. You can upload up to 20 files at once. Compressed and
zipped files are also supported.
7. Click Create. After upload completes, it might take some time for them to be parsed and analyzed. If it does,
Cloud App Discovery sends an email notification when they're ready.
8. Select Manage snapshot reports and the select your snapshot report.
Next steps
Get started using Cloud App Discovery in Azure AD
Configure automatic log upload for continuous reporting
Use a custom log parser
Find unmanaged cloud applications with Cloud App
Discovery
Summary
Cloud App Discovery in Azure Active Directory now provides an enhanced agentless discovery experience
powered by Microsoft Cloud App Security. To use Cloud App Discovery, just sign in with your Azure AD Premium
P1 credentials. This update is available at no additional cost to all Azure AD Premium P1 customers. Get started
with the article Set up Cloud App Discovery in Azure AD, then try out Microsoft Cloud App Security.
IMPORTANT
The current Azure AD Cloud App Discovery experience with agent-based discovery is to be turned off on March 5, 2018,
after which the agents will be disabled and data deleted. Please take action before March 5th to get up and running on the
new experience to avoid disruption of service.
With Cloud App Discovery, you can:

Find the cloud applications being used and measure that usage by number of users, volume of traffic or
number of web requests to the application.
Identify the users that are using an application.
Export data for offline analysis.
Bring these applications under IT control and enable single sign-on for user management.
How it works
1. Application usage agents are installed on user's computers.
2. The application usage information captured by the agents is sent over a secure, encrypted channel to the cloud
app discovery service.
3. The Cloud App Discovery service evaluates the data and generates reports.
Next steps
Cloud App Discovery Security and Privacy Considerations
Cloud App Discovery Registry Settings for Proxy Servers with Custom Ports
Cloud App Discovery Agent Changelog
Cloud App Discovery Registry Settings for Proxy
Services
The purpose of this topic is to tell you how to perform to set the required port on the computers running the Cloud
App Discovery agent. By default, the Cloud App Discovery agent is configured to use only the ports 80 or 443. If
you are planning on installing Cloud App Discovery in an environment with a proxy server that is using a custom
port (neither 80 nor 443), you need to configure your agents to use this port. The configuration is based on a
registry key.
TIP
Check out the improvements to the now agentless Cloud App Discovery in Azure Active Directory (Azure AD), which are
enhanced by integration with Microsoft Cloud App Security.
Modify the port used by the computer running the Cloud App
Discovery agent
1. Start the registry editor.

2. Navigate to or create the following registry key: HKLM_LOCAL_MACHINE\Software\Microsoft\Cloud App
Discovery\Endpoint
3. Create a new multi-string value called Ports.
4. To open the Edit Multi-String dialog, double-click the Ports value.

5. In the Value data, enter the following values and add all custom ports that are used by your organization:
80
8080
8118
8888
81
12080
6999
30606
31595
4080
443
1110
6. Click OK to close the Edit Multi-String dialog.
Next steps
Cloud App Discovery Security and Privacy
Considerations
This topic explains how data is collected, processed, and secured within Azure Active Directory Cloud App
Discovery. Microsoft is committed to protecting your privacy and securing your data. Microsoft adheres to secure
software development lifecycle practices for operating a service. Securing and protecting data is a top priority at
Microsoft.
TIP
Check out the new agentless Cloud App Discovery in Azure Active Directory (Azure AD), which are enhanced by integration
with Microsoft Cloud App Security.
Overview
Cloud App Discovery is a feature of Azure AD and is hosted in Microsoft Azure.
The Cloud App Discovery endpoint agent is used to collect application discovery data from IT managed machines.
The collected data is sent securely over an encrypted channel to the Azure AD Cloud App Discovery service. The
Cloud App Discovery data for an organization is then visible in the Azure portal.
The following sections follow the secure flow of information from your organization to the Cloud App Discovery
service and ultimately to the Cloud App Discovery portal.
Collecting data from your organization

In order to use Azure Active Directory’s Cloud App discovery feature to get insights into the applications used by
employees in your organization, you need to first deploy the Azure AD Cloud App Discovery endpoint agent to
machines in your organization.
Administrators of the Azure Active Directory tenant (or their delegate) can download the agent installation package
from the Azure portal. The agent can either be manually installed or installed across multiple machines in the
organization using SCCM or Group Policy.
For further instructions on deployment options, see Cloud App Discovery Group Policy Deployment Guide.
Data collected by the agent
The information outlined in the following list is collected by the agent when a connection is made to a Web
application. The information is only collected for those applications that the administrator has configured for
discovery. You can edit the list of cloud apps that the agent monitors through the Cloud App Discovery in Azure AD
in the Microsoft Azure portal, under Settings->Data Collection->App Collection list.
Information Category: User information
Description: The Windows user name of the process that made a request to the target Web application (for
example, DOMAIN\username) as well as the Windows Security Identifier (SID) of the user.
Information Category: Process information
Description: The name of the process that made the request to the target Web application (for example,
iexplore.exe)
Information Category: Machine information
Description: The machine NetBIOS name on which the agent is installed.
Information Category: App traffic information
Description: The following connection information:
The source (local computer) and destination IP addresses and port numbers
The public IP address of the organization through which the request goes out.
The time of the request
The volume of traffic sent and received
The IP version (4 or 6)
For TLS connections only: The target host name from either the Server Name Indication extension or the server
certificate.
The following HTTP information:
Method (GET, POST, etc.)
Protocol (HTTP/1.1, etc.)
User agent string
Hostname
Target URI (excluding query string)
Content type information
Referrer URL information (excluding query string)
NOTE
The HTTP information above is collected for all non-encrypted connections. For TLS connections, this information is only
captured when the ‘Deep Inspection’ setting is turned on in the portal. The setting is ‘ON’ by default. For more details, see
below, and Getting Started With Cloud App Discovery
In addition to the data that the agent collects about the network activity, it also collects anonymous data about
Software and hardware configuration
Error reports
Data on how the agent is being used.
How the agent works
The agent installation includes two components:
A user-mode component
A kernel-mode driver component (Windows Filtering Platform driver)
When the agent is first installed it stores a machine-specific trusted certificate on the machine which it then uses to
establish a secure connection with the Cloud App Discovery service. The agent periodically retrieves policy
configuration from the Cloud App Discovery service over this secure connection. The policy includes information
about which cloud applications to monitor and whether auto-updating should be enabled, among other things.
As Web traffic is sent and received on the machine from Internet Explorer and Chrome, the Cloud App Discovery
agent analyzes the traffic and extracts the relevant metadata (see the Data collected by the agent section above).
Every minute, the agent uploads the collected metadata to the Cloud App Discovery service over an encrypted
channel.
The driver component intercepts the encrypted traffic and inserts itself into the encrypted stream. More details in
the Intercepting data from encrypted connections (Deep inspection) section below.
Respecting user privacy
Our goal is to provide administrators the tools to set the balance between detailed optics into application usage
and user privacy as appropriate for their organization. To that end, we provide the following knobs in the settings
page in the Portal:
Data Collection: Administrators can choose to specify which applications or application categories they want
to get discovery data on.
Deep Inspection: Administrators can chose to specify if the agent collects HTTP traffic for SSL/TLS connections
(aka 'Deep Inspection'). More on this in the next section.
Consent Options: Administrators can use the Cloud App Discovery portal to choose whether to notify users of
the data collection by the agent, and whether to require user consent before the agent starts collecting user
data.
The Cloud App Discovery endpoint agent only collects the information described in the Data collected by the
agent section above.
Intercepting data from encrypted connections (Deep inspection)
As we mentioned earlier, administrators can configure the agent to monitor data from encrypted connections
('deep inspection'). TLS (Transport Layer Security) is one of the most common protocols in use on the Internet
today. By encrypting communication with TLS, a client can establish a secure and private communication channel
with a web server; TLS provides essential protection for passing authentication credentials and prevent the
disclosure of sensitive information.
While the end-to-end secure encrypted channel provided by TLS enables important security and privacy protection,
the protocol is often abused for malicious or nefarious purposes. So much so, in fact, that TLS is often referred to as
the “universal firewall-bypass protocol”. The root of the problem is that most firewalls are unable to inspect TLS
communication because the application-layer data is encrypted with SSL. Knowing this, attackers frequently
leverage TLS to deliver malicious payloads to a user confident that even the most intelligent application-layer
firewalls are completely blind to TLS and must simply relay TLS communication between hosts. End users
frequently leverage TLS to bypass access controls enforced by their corporate firewalls and proxy servers, using it
to connect to public proxies and for tunneling non-TLS protocols through the firewall that might otherwise be
blocked by policy.
Deep inspection allows the Cloud App Discovery agent to act as a trusted man-in-the-middle. When a client request
is made to access an HTTPS protected resource, the Endpoint Agent driver intercepts the connection and
establishes a new connection to the destination server to retrieves its SSL certificate on behalf of the client. The
agent then verifies that the certificate can be trusted (by checking that it was not revoked, and performing other
certificate checks), and if these pass, the Endpoint Agent then copies the information from the server certificate and
creates its own server certificate -- known as an interception certificate -- using that information. The interception
certificate is signed on-the-fly by the endpoint agent with a root certificate, which is installed in the Windows
trusted certificate store. This self-signed root certificate is marked non-exportable and is ACL’d to administrators. It
is intended to never leave the machine on which it was created. When the end-user’s client application receives the
interception certificate, it will trust it because it can successfully validate the certificate chain all the way to the root
certificate. This process is mostly transparent from an end-user’s point of view with a few caveats as described
below.
By enabling deep inspection, the Cloud App Discovery Endpoint Agent can decrypt and inspect TLS encrypted
communications, allowing the service to reduce noise and provide insights about the usage of the encrypted cloud
apps.
A word of caution
Before turning on deep inspection, it is strongly suggested that you communicate your intentions to your legal and
HR departments and obtain their consent. Inspecting end user’s private encrypted communications can be a
sensitive subject, for obvious reasons. Before a production roll-out of deep inspection, make certain that your
corporate security and acceptable use policies have been updated to indicate that encrypted communication will be
inspected. User notification and exemption of sites deemed sensitive (e.g. banking and medical sites) may also be
necessary if you configure Cloud App Discovery to monitor them. As mentioned above, administrators can use the
Cloud App Discovery portal to choose whether to notify users of the data collection by the agent, and whether to
require user consent before the agent starts collecting user data.
Known issues and drawbacks
There are a few cases where TLS interception may impact the end user experience:
Extended Validation (EV) certificates render the address bar of the web browser green to act as a visual clue that
you are visiting a trusted web site. TLS inspection cannot duplicate EV in the certificate it issues to the client, so
web sites that use EV certificates will work normally but the address bar will not display green.
Public key pinning (also known as certificate pinning) are designed to help protect users from man-in-the-
middle attacks and rogue certificate authorities. When the root certificate for a pinned site does not match one
of the known good CA's, the browser rejects the connection with an error. Since TLS interception is, in fact, a
man-in-the-middle, these connections will fail.
If users click the lock icon in the browser address bar browser to inspect the site information, they will not see a
chain ending in the certificate authority used to sign the website certificate, but instead a certificate chain ending
with the Windows trusted certificate store.
To reduce the occurrences of these issues, we keep track of cloud services and client applications known to use
extended validation or public key pinning and instruct the Endpoint Agent to avoid intercepting impacted
connections. Even in these cases, however, you will still receive reports of the use of these cloud apps and the
volume of data being transferred, but since they are not deep inspected, no details about how the apps were used
will be available.
Sending data to Cloud App Discovery

Once metadata has been collected by the agent, it is cached on the machine for up to one minute or until the
cached data reaches a size of 5MB. It is then compressed and sent over a secure connection to the Cloud App
Discovery service.
If the agent is unable to communicate with the Cloud App Discovery service for any reason, the collected metadata
is stored in a local file cache that can only be accessed by privileged users on the machine (such as the
Administrators group).
The agent automatically attempts to resend the cached metadata until it has successfully been received by the
Cloud App Discovery service.
Receiving the data at the service end

The agents authenticate to the Cloud App Discovery service using the machine specific client authentication
certificate referenced above and forwards data over an encrypted channel.
The Cloud App Discovery service’s analytics pipeline processes metadata for each customer separately by logically
partitioning it through all stages of the analytics pipeline. The analyzed metadata drives the various reports in the
portal.
The unprocessed metadata and the analyzed metadata are stored for up to 180 days. In addition, customers can
choose to capture the analyzed metadata in an Azure blob storage account of their choosing. This is useful for
offline analysis of metadata as well as longer retention of the data.
Accessing the data using the Azure portal

In an effort to keep the metadata collected secure, by default only global administrators of the tenant have access
to the Cloud App Discovery feature in the Azure portal.
However, administrators can choose to delegate this access to other users or groups.
NOTE
For more details, see Getting Started With Cloud App Discovery
Any user accessing the data in the portal, must be licensed with an Azure AD Premium license.
Additional Resources
How to provide secure remote access to on-premises
applications
Employees today want to be productive at any place, at any time, and from any device. They want to work on their
own devices, whether they be tablets, phones, or laptops. And they expect to be able to access all their
applications, both SaaS apps in the cloud and corporate apps on-premises. Providing access to on-premises
applications has traditionally involved virtual private networks (VPNs) or demilitarized zones (DMZs). Not only are
these solutions complex and hard to make secure, but they are costly to set up and manage.
There is a better way!
A modern workforce in the mobile-first, cloud-first world needs a modern remote access solution. Azure AD
Application Proxy is a feature of Azure Active Directory that offers remote access as a service. That means it's easy
to deploy, use, and manage.
NOTE
To learn if specific features are supported by your license type, check the Azure Active Directory Pricing information page.
What is Azure Active Directory Application Proxy?

Azure AD Application Proxy provides single sign-on (SSO) and secure remote access for web applications hosted
on-premises. Some apps you would want to publish include SharePoint sites, Outlook Web Access, or any other
LOB web applications you have. These on-premises web applications are integrated with Azure AD, the same
identity and control platform that is used by O365. End users can access your on-premises applications the same
way they access O365 and other SaaS apps integrated with Azure AD. You don't need to change the network
infrastructure or require VPN to provide this solution for your users.
Why is Application Proxy a better solution?

Azure AD Application Proxy provides a simple, secure, and cost-effective remote access solution to all your on-
premises applications.
Azure AD Application Proxy is:
Simple
You don't need to change or update your applications to work with Application Proxy.
Your users get a consistent authentication experience. They can use the MyApps portal to get single
sign-on to both SaaS apps in the cloud and your apps on-premises.
Secure
When you publish your apps using Azure AD Application Proxy, you can take advantage of the rich
authorization controls and security analytics in Azure. You get cloud-scale security and Azure security
features like conditional access and two-step verification.
You don't have to open any inbound connections through your firewall to give your users remote
access.
Cost-effective
Application Proxy works in the cloud, so you can save time and money. On-premises solutions typically
require you to set up and maintain DMZs, edge servers, or other complex infrastructures.
What kind of applications work with Application Proxy?

With Azure AD Application Proxy you can access different types of internal applications:
Web applications that use Integrated Windows Authentication for authentication
Web applications that use form-based or header-based access
Web APIs that you want to expose to rich applications on different devices
Applications hosted behind a Remote Desktop Gateway
Rich client apps that are integrated with the Active Directory Authentication Library (ADAL)
How does Application Proxy work?

There are two components that you need to configure to make Application Proxy work: a connector and an
external endpoint.
The connector is a lightweight agent that sits on a Windows Server inside your network. The connector facilitates
the traffic flow from the Application Proxy service in the cloud to your application on-premises. It only uses
outbound connections, so you don't have to open any inbound ports or put anything in the DMZ. The connectors
are stateless and pull information from the cloud as necessary. For more information about connectors, like how
they load-balance and authenticate, see Understand Azure AD Application Proxy connectors.
The external endpoint is how your users reach your applications while outside of your network. They can either go
directly to an external URL that you determine, or they can access the application through the MyApps portal.
When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the
connector to the on-premises application.
1. The user accesses the application through the Application Proxy service and is directed to the Azure AD sign-in
page to authenticate.
2. After a successful sign-in, a token is generated and sent to the client device.
3. The client sends the token to the Application Proxy service, which retrieves the user principal name (UPN) and
security principal name (SPN) from the token, then directs the request to the Application Proxy connector.
4. If you have configured single sign-on, the connector performs any additional authentication required on behalf
of the user.
5. The connector sends the request to the on-premises application.
6. The response is sent through Application Proxy service and connector to the user.
Single sign-on
Azure AD Application Proxy provides single sign-on (SSO) to applications that use Integrated Windows
Authentication (IWA), or claims-aware applications. If your application uses IWA, Application Proxy impersonates
the user using Kerberos Constrained Delegation to provide SSO. If you have a claims-aware application that trusts
Azure Active Directory, SSO works because the user was already authenticated by Azure AD.
For more information about Kerberos, see All you want to know about Kerberos Constrained Delegation (KCD).
Managing apps
Once your app is published with Application Proxy, you can manage it like any other enterprise app in the Azure
portal. You can use Azure Active Directory security features like conditional access and two-step verification,
control user permissions, and customize the branding for your app.
Get started
Before you configure Application Proxy, make sure you have a supported Azure Active Directory edition and an
Azure AD directory for which you are a global administrator.
Get started with Application Proxy in two steps:
1. Enable Application Proxy and configure the connector.
2. Publish applications - use the quick and easy wizard to get your on-premises apps published and accessible
remotely.
What's next?
Once you publish your first app, there's a lot more you can do with Application Proxy:
Enable single-sign on
Publish applications using your own domain name
Learn about Azure AD Application Proxy connectors
Working with existing on-premises Proxy servers
Set a custom home page
For the latest news and updates, check out the Application Proxy blog
Get started with Application Proxy and install the
connector
This article walks you through the steps to enable Microsoft Azure AD Application Proxy for your cloud directory
in Azure AD.
If you're not yet aware of the security and productivity benefits Application Proxy brings to your organization,
learn more about How to provide secure remote access to on-premises applications.
Application Proxy prerequisites

Before you can enable and use Application Proxy services, you need to have:
A Microsoft Azure AD basic or premium subscription and an Azure AD directory for which you are a global
administrator.
A server running Windows Server 2012 R2 or 2016, on which you can install the Application Proxy Connector.
The server needs to be able to connect to the Application Proxy services in the cloud, and the on-premises
applications that you are publishing.
For single sign-on to your published applications using Kerberos Constrained Delegation, this machine
should be domain-joined in the same AD domain as the applications that you are publishing. For
information, see KCD for single sign-on with Application Proxy.
If your organization uses proxy servers to connect to the internet, read Work with existing on-premises proxy
servers for details on how to configure them before you get started with Application Proxy.
Open your ports

To prepare your environment for Azure AD Application Proxy, you first need to enable communication to Azure
data centers. If there is a firewall in the path, make sure that it's open so that the Connector can make HTTPS
(TCP) requests to the Application Proxy.
1. Open the following ports to outbound traffic:
PORT NUMBER HOW IT'S USED
80 Downloading certificate revocation lists (CRLs) while

validating the SSL certificate
443 All outbound communication with the Application Proxy

service
If your firewall enforces traffic according to originating users, open these ports for traffic from Windows
services that run as a Network Service.
IMPORTANT
The table reflects the port requirements for connector versions 1.5.132.0 and newer. If you still have an older
connector version, you also need to enable the following ports in addition to 80 and 443: 5671, 8080, 9090-9091,
9350, 9352, 10100–10120.
For information about updating your connectors to the newest version, see Understand Azure AD Application
Proxy connectors.
2. If your firewall or proxy allows DNS whitelisting, you can whitelist connections to msappproxy.net and
servicebus.windows.net. If not, you need to allow access to the Azure DataCenter IP ranges, which are
updated each week.
3. Microsoft uses four addresses to verify certificates. Allow access to the following URLs if you haven't done
so for other products:
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
4. Your connector needs access to login.windows.net and login.microsoftonline.com for the registration
process.
5. Use the Azure AD Application Proxy Connector Ports Test Tool to verify that your connector can reach the
Application Proxy service. At a minimum, make sure that the Central US region and the region closest to
you have all green checkmarks. Beyond that, more green checkmarks means greater resiliency.
Install and register a connector

1. Sign in as an administrator in the Azure portal.
2. Your current directory appears under your username in the top right corner. If you need to change directories,
select that icon.
3. Go to Azure Active Directory > Application Proxy.
4. Select Download Connector.
5. Run AADApplicationProxyConnectorInstaller.exe on the server you prepared according to the

prerequisites.
6. Follow the instructions in the wizard to install. During installation, you are prompted to register the
connector with the Application Proxy of your Azure AD tenant.
Provide your Azure AD global administrator credentials. Your global administrator tenant may be
different from your Microsoft Azure credentials.
Make sure the admin who registers the connector is in the same directory where you enabled the
Application Proxy service. For example, if the tenant domain is contoso.com, the admin should be
admin@contoso.com or any other alias on that domain.
If IE Enhanced Security Configuration is set to On on the server where you are installing the
connector, you may not see the registration screen. To get access, follow the instructions in the error
message. Make sure that Internet Explorer Enhanced Security is off.
For high availability purposes, you should deploy at least two connectors. Each connector must be registered
separately.
Test that the connector installed correctly

You can confirm that a new connector installed correctly by checking for it in either the Azure portal or on your
server.
In the Azure portal, sign in to your tenant and navigate to Azure Active Directory > Application Proxy. All of
your connectors and connector groups appear on this page. Select a connector to see its details or move it into a
different connector group.
On your server, check the list of active services for the connector and the connector updater. The two services
should start running immediately, but if not, turn them on:
Microsoft AAD Application Proxy Connector enables connectivity
Microsoft AAD Application Proxy Connector Updater is an automated update service. The updater
checks for new versions of the connector and updates the connector as needed.
For information about connectors and how they stay up to date, see Understand Azure AD Application Proxy
connectors.
Next steps
You are now ready to Publish applications with Application Proxy.
If you have applications that are on separate networks or different locations, use connector groups to organize
the different connectors into logical units. Learn more about Working with Application Proxy connectors.
Publish applications using Azure AD Application
Proxy
Azure Active Directory (AD) Application Proxy helps you support remote workers by publishing on-premises
applications to be accessed over the internet. You can publish these applications through the Azure portal to
provide secure remote access from outside your network.
This article walks you through the steps to publish an on-premises app with Application Proxy. After you complete
this article, your users will be able to access your app remotely. And you'll be ready to configure extra features for
the application like single sign-on, personalized information, and security requirements.
If you're new to Application Proxy, learn more about this feature with the article How to provide secure remote
access to on-premises applications.
Publish an on-premises app for remote access

Follow these steps to publish your apps with Application Proxy. If you haven't already downloaded and configured
a connector for your organization, go to Get started with Application Proxy and install the connector first, and then
publish your app.
TIP
If you're testing out Application Proxy for the first time, choose an application that's set up for password-based
authentication. Application Proxy supports other types of authentication, but password-based apps are the easiest to get up
and running quickly.
1. Sign in as an administrator in the Azure portal.

2. Select Azure Active Directory > Enterprise applications > New application.
3. Select All, then select On-premises application.
4. Provide the following information about your application:

Name: The name of the application that will appear on the access panel and in the Azure portal.
Internal URL: The URL that you use to access the application from inside your private network. You
can provide a specific path on the backend server to publish, while the rest of the server is
unpublished. In this way, you can publish different sites on the same server as different apps, and
give each one its own name and access rules.
TIP
If you publish a path, make sure that it includes all the necessary images, scripts, and style sheets for your
application. For example, if your app is at https://yourapp/app and uses images located at
https://yourapp/media, then you should publish https://yourapp/ as the path. This internal URL doesn't have
to be the landing page your users see. For more information, see Set a custom home page for published
apps.
External URL: The address your users will go to in order to access the app from outside your
network. If you don't want to use the default Application Proxy domain, read about custom domains
in Azure AD Application Proxy.
Pre Authentication: How Application Proxy verifies users before giving them access to your
application.
Azure Active Directory: Application Proxy redirects users to sign in with Azure AD, which
authenticates their permissions for the directory and application. We recommend keeping this
option as the default, so that you can take advantage of Azure AD security features like
conditional access and Multi-Factor Authentication.
Passthrough: Users don't have to authenticate against Azure Active Directory to access the
application. You can still set up authentication requirements on the backend.
Connector Group: Connectors process the remote access to your application, and connector groups
help you organize connectors and apps by region, network, or purpose. If you don't have any connector
groups created yet, your app is assigned to Default.
5. If necessary, configure additional settings. For most applications, you should keep these settings in their
default states.
Backend Application Timeout: Set this value to Long only if your application is slow to authenticate
and connect.
Translate URLs in Headers: Keep this value as Yes unless your application required the original host
header in the authentication request.
Translate URLs in Application Body: Keep this value as No unless you have hardcoded HTML links to
other on-premises applications, and don't use custom domains. For more information, see Link
translation with Application Proxy.
6. Select Add.
Add a test user

To test that your app was published correctly, add a test user account. Verify that this account already has
permissions to access the app from inside the corporate network.
1. Back on the Quick start blade, select Assign a user for testing.
2. On the Users and groups blade, select Add.
3. On the Add assignment blade, select Users and groups then choose the account you want to add.
4. Select Assign.
Test your published app

In your browser, navigate to the external URL that you configured during the publish step. You should see the start
screen, and be able to sign in with the test account you set up.
Next steps
Download connectors and create connector groups to publish applications on separate networks and
locations.
Set up single sign-on for your newly published app
Working with custom domains in Azure AD
Application Proxy
When you publish an application through Azure Active Directory Application Proxy, you create an external URL for
your users to go to when they're working remotely. This URL gets the default domain yourtenant.msappproxy.net.
For example, if you published an app named Expenses and your tenant is named Contoso, then the external URL
would be https://expenses-contoso.msappproxy.net. If you want to use your own domain name, configure a
custom domain for your application.
We recommend that you set up custom domains for your applications whenever possible. Some of the benefits of
custom domains include:
Your users can get to the application with the same URL, whether they are working inside or outside of your
network.
If all of your applications have the same internal and external URLs, then links in one application that point to
another continue to work even outside the corporate network.
You control your branding, and create the URLs you want.
Configure a custom domain

Prerequisites
Before you configure a custom domain, make sure that you have the following requirements prepared:
A verified domain added to Azure Active Directory.
A custom certificate for the domain, in the form of a PFX file.
An on-premises app published through Application Proxy.
Configure your custom domain
When you have those three requirements ready, follow these steps to set up your custom domain:
1. Sign in to the Azure portal.
2. Navigate to Azure Active Directory > Enterprise applications > All applications and choose the app you
want to manage.
3. Select Application Proxy.
4. In the External URL field, use the dropdown list to select your custom domain. If you don't see your domain in
the list, then it hasn't been verified yet.
5. Select Save
6. The Certificate field that was disabled becomes enabled. Select this field.
If you already uploaded a certificate for this domain, the Certificate field displays the certificate information.
7. Upload the PFX certificate and enter the password for the certificate.
8. Select Save to save your changes.
9. Add a DNS record that redirects the new external URL to the msappproxy.net domain.
TIP
You only need to upload one certificate per custom domain. Once you upload a certificate, you can choose the custom
domain when you publish a new app and not have to do additional configuration except for the DNS record.
Manage certificates
Certificate format
There is no restriction on the certificate signature methods. Elliptic Curve Cryptography (ECC), Subject Alternative
Name (SAN), and other common certificate types are all supported.
You can use a wildcard certificate as long as the wildcard matches the desired external URL.
Changing the domain
All verified domains appear in the External URL dropdown list for your application. To change the domain, just
update that field for the application. If the domain you want isn't in the list, add it as a verified domain. If you
select a domain that doesn't have an associated certificate yet, follow steps 5-7 to add the certificate. Then, make
sure you update the DNS record to redirect from the new external URL.
Certificate management
You can use the same certificate for multiple applications unless the applications share an external host.
You get a warning when a certificate expires, telling you to upload another certificate through the portal. If the
certificate is revoked, your users may see a security warning when accessing the application. We don’t perform
revocation checks for certificates. To update the certificate for a given application, navigate to the application and
follow steps 5-7 for configuring custom domains on published applications to upload a new certificate. If the old
certificate is not being used by other applications, it is deleted automatically.
Currently all certificate management is through individual application pages so you need to manage certificates in
the context of the relevant applications.
Next steps
Enable single sign-on to your published apps with Azure AD authentication.
Enable conditional access to your published apps.
Add your custom domain name to Azure AD
How does Azure AD Application Proxy provide single
sign-on?
Single sign-on is a key element of Azure AD Application Proxy. It provides the best user experience because your
users only have to sign in to Azure Active Directory in the cloud. Once they authenticate to Azure Active Directory,
the Application Proxy connector handles the authentication to the on-premises application. The backend
application can't tell the difference between a remote user signing in through Application Proxy and a regular use
on a domain-joined device.
To use Azure Active Directory for single sign-on to your applications, you need to select Azure Active Directory
as the pre-authentication method. If you select Passthrough then your users don't authenticate to Azure Active
Directory at all, but are directed straight to the application. You can configure this setting when you first publish an
application, or navigate to your application in the Azure portal and edit the Application Proxy settings.
To see your single sign-on options, follow these steps:
2. Navigate to Azure Active Directory > Enterprise applications > All applications.
3. Select the app whose single sign-on options you want to manage.
4. Select Single sign-on.
The dropdown menu shows five options for single sign-on to your application:
Azure AD single sign-on disabled
Password-based sign-on
Linked sign-on
Integrated Windows Authentication
Header-based sign-on
Azure AD single sign-on disabled

If you don't want to use Azure Active Directory integration for single sign-on to your application, choose Azure AD
single sign-on disabled. With this option selected, your users may authenticate twice. First, they authenticate to
Azure Active Directory and then sign in to the application itself.
This option is a good choice if your on-premises application doesn't require users to authenticate, but you want to
add Azure Active Directory as a layer of security for remote access.
If you want to use Azure Active Directory as a password vault for your on-premises applications, choose
Password-based sign-on. This option is a good choice if your application authenticates with a
username/password combo instead of access tokens or headers. With password-based sign-on, your users need to
sign in to the application the first time they access it. After that, Azure Active Directory supplies the username and
password on behalf of the user.
For information about setting up password-based sign-on, see Password vaulting for single sign-on with
Application Proxy.
Linked sign-on
If you already have a single sign-on solution set up for your on-premises identities, choose Linked sign-on. This
option enables Azure Active Directory to leverage existing SSO solutions, but still gives your users remote access
to the application.
For information about linked sign-on (formally known as existing single sign-on), see What is application access
and single sign-on with Azure Active Directory?.
Integrated Windows Authentication

If your on-premises applications use Integrated Windows Authentication(IWA) or if you want to use Kerberos
Constrained Delegation (KCD) for single sign-on, choose Integrated Windows Authentication. With this option,
your users only need to authenticate to Azure Active Directory, and then the Application Proxy connector
impersonates the user to get a Kerberos token and sign in to the application.
For information about setting up Integrated Windows Authentication, see Kerberos Constrained Delegation for
single sign-on with Application Proxy.
Header-based sign-on
If your applications use headers for authentication, choose Header-based sign-on. With this option, your users
only need to authentication the Azure Active Directory. Microsoft partners with a third-party authentication service
called PingAccess, which translated the Azure Active Directory access token into a header format for the
application.
For information about setting up header-based authentication, see Header-based authentication for single sign-on
with Application Proxy.
Next steps
Password vaulting for single sign-on with Application Proxy
Kerberos Constrained Delegation for single sign-on with Application Proxy
Header-based authentication for single sign-on with Application Proxy
Kerberos Constrained Delegation for single sign-on
to your apps with Application Proxy
You can provide single sign-on for on-premises applications published through Application Proxy that are
secured with Integrated Windows Authentication. These applications require a Kerberos ticket for access.
Application Proxy uses Kerberos Constrained Delegation (KCD) to support these applications.
You can enable single sign-on to your applications using Integrated Windows Authentication (IWA) by giving
Application Proxy connectors permission in Active Directory to impersonate users. The connectors use this
permission to send and receive tokens on their behalf.
How single sign-on with KCD works

This diagram explains the flow when a user attempts to access an on-prem application that uses IWA.
1. The user enters the URL to access the on-prem application through Application Proxy.
2. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point,
Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication.
If the user is validated, Azure AD creates a token and sends it to the user.
3. The user passes the token to Application Proxy.
4. Application Proxy validates the token and retrieves the User Principal Name (UPN) from it, and then sends the
request, the UPN, and the Service Principal Name (SPN) to the Connector through a dually authenticated
secure channel.
5. The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on-prem AD,
impersonating the user to get a Kerberos token to the application.
6. Active Directory sends the Kerberos token for the application to the Connector.
7. The Connector sends the original request to the application server, using the Kerberos token it received from
AD.
8. The application sends the response to the Connector, which is then returned to the Application Proxy service
and finally to the user.
Prerequisites
Before you get started with single sign-on for IWA applications, make sure your environment is ready with the
following settings and configurations:
Your apps, like SharePoint Web apps, are set to use Integrated Windows Authentication. For more information,
see Enable Support for Kerberos Authentication, or for SharePoint see Plan for Kerberos authentication in
SharePoint 2013.
All your apps have Service Principal Names.
The server running the Connector and the server running the app are domain joined and part of the same
domain or trusting domains. For more information on domain join, see Join a Computer to a Domain.
The server running the Connector has access to read the TokenGroupsGlobalAndUniversal attribute for users.
This default setting might have been impacted by security hardening the environment.
Configure Active Directory
The Active Directory configuration varies, depending on whether your Application Proxy connector and the
application server are in the same domain or not.
Connector and application server in the same domain
1. In Active Directory, go to Tools > Users and Computers.
2. Select the server running the connector.
3. Right-click and select Properties > Delegation.
4. Select Trust this computer for delegation to specified services only.
5. Under Services to which this account can present delegated credentials add the value for the SPN
identity of the application server. This enables the Application Proxy Connector to impersonate users in AD
against the applications defined in the list.
Connector and application server in different domains

1. For a list of prerequisites for working with KCD across domains, see Kerberos Constrained Delegation across
domains.
2. Use the principalsallowedtodelegateto property on the Connector server to enable the Application Proxy
to delegate for the Connector server. The application server is sharepointserviceaccount and the
delegating server is connectormachineaccount . For Windows 2012 R2, use this code as an example:
$connector= Get-ADComputer -Identity connectormachineaccount -server dc.connectordomain.com
Set-ADComputer -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
Get-ADComputer sharepointserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
Sharepointserviceaccount can be the SPS machine account or a service account under which the SPS app pool is
running.
Configure single sign-on

1. Publish your application according to the instructions described in Publish applications with Application Proxy.
Make sure to select Azure Active Directory as the Preauthentication Method.
2. After your application appears in the list of enterprise applications, select it and click Single sign-on.
3. Set the single sign-on mode to Integrated Windows Authentication.
4. Enter the Internal Application SPN of the application server. In this example, the SPN for our published
application is http/www.contoso.com. This SPN needs to be in the list of services to which the connector can
present delegated credentials.
5. Choose the Delegated Login Identity for the connector to use on behalf of your users. For more
information, see Working with different on-premises and cloud identities
SSO for non-Windows apps

The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the
cloud. Once the request arrives on-premises, the Azure AD Application Proxy connector issues a Kerberos ticket
on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos
Constrained Delegation (KCD). In the next phase, a request is sent to the backend application with this Kerberos
ticket. There are several protocols that define how to send such requests. Most non-Windows servers expect
Negotiate/SPNego that is now supported on Azure AD Application Proxy.
For more information about Kerberos, see All you want to know about Kerberos Constrained Delegation (KCD).
Non-Windows apps typically user usernames or SAM account names instead of domain email addresses. If that
situation applies to your applications, you need to configure the delegated login identity field to connect your
cloud identities to your application identities.
Working with different on-premises and cloud identities

Application Proxy assumes that users have exactly the same identity in the cloud and on-premises. If that's not
the case, you can still use KCD for single sign-on. Configure a Delegated login identity for each application to
specify which identity should be used when performing single sign-on.
This capability allows many organizations that have different on-premises and cloud identities to have SSO from
the cloud to on-premises apps without requiring the users to enter different usernames and passwords. This
includes organizations that:
Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the
cloud (joe@contoso.com).
Have non-routable domain name internally (joe@contoso.usa) and a legal one in the cloud.
Do not use domain names internally (joe)
Use different aliases on-prem and in the cloud. For example, joe-johns@contoso.com vs. joej@contoso.com
With Application Proxy, you can select which identity to use to obtain the Kerberos ticket. This setting is per
application. Some of these options are suitable for systems that do not accept email address format, others are
designed for alternative login.
If delegated login identity is used, the value might not be unique across all the domains or forests in your
organization. You can avoid this issue by publishing these applications twice using two different Connector
groups. Since each application has a different user audience, you can join its Connectors to a different domain.
Configure SSO for different identities
1. Configure Azure AD Connect settings so the main identity is the email address (mail). This is done as part of
the customize process, by changing the User Principal Name field in the sync settings. These settings also
determine how users log in to Office365, Windows10 devices, and other applications that use Azure AD as
their identity store.
2. In the Application Configuration settings for the application you would like to modify, select the
Delegated Login Identity to be used:
User Principal Name (for example, joe@contoso.com)
Alternate User Principal Name (for example, joed@contoso.local)
Username part of User Principal Name (for example, joe)
Username part of Alternate User Principal Name (for example, joed)
On-premises SAM account name (depends on the domain controller configuration)
Troubleshooting SSO for different identities
If there is an error in the SSO process, it appears in the connector machine event log as explained in
Troubleshooting. But, in some cases, the request is successfully sent to the backend application while this
application replies in various other HTTP responses. Troubleshooting these cases should start by examining event
number 24029 on the connector machine in the Application Proxy session event log. The user identity that was
used for delegation appears in the “user” field within the event details. To turn on session log, select Show
analytic and debug logs in the event viewer view menu.
Next steps
How to configure an Application Proxy application to use Kerberos Constrained Delegation
Troubleshoot issues you're having with Application Proxy
For the latest news and updates, check out the Application Proxy blog
Header-based authentication for single sign-on with
Application Proxy and PingAccess
Azure Active Directory Application Proxy and PingAccess have partnered together to provide Azure Active
Directory customers with access to even more applications. PingAccess expands the existing Application Proxy
offerings to include single sign-on access to applications that use headers for authentication.
What is PingAccess for Azure AD?

PingAccess for Azure Active Directory is an offering of PingAccess that enables you to give users access and single
sign-on to applications that use headers for authentication. Application Proxy treats these apps like any other,
using Azure AD to authenticate access and then passing traffic through the connector service. PingAccess sits in
front of the apps and translates the access token from Azure AD into a header so that the application receives the
authentication in the format it can read.
Your users won’t notice anything different when they sign in to use your corporate apps. They can still work from
anywhere on any device.
Since the Application Proxy connectors direct remote traffic to all apps regardless of their authentication type,
they’ll continue to load balance automatically, as well.
How do I get access?

Since this scenario is offered through a partnership between Azure Active Directory and PingAccess, you need
licenses for both services. However, Azure Active Directory Premium subscriptions include a basic PingAccess
license that covers up to 20 applications. If you need to publish more than 20 header-based applications, you can
purchase an additional license from PingAccess.
For more information, see Azure Active Directory editions.
Publish your application in Azure

This article is intended for people who are publishing an app with this scenario for the first time. It walks through
how to get started with both Application and PingAccess, in addition to the publishing steps. If you’ve already
configured both services but want a refresher on the publishing steps, you can skip the connector installation and
move on to Add your app to Azure AD with Application Proxy.
NOTE
Since this scenario is a partnership between Azure AD and PingAccess, some of the instructions exist on the Ping Identity
site.
Install an Application Proxy connector

If you already have Application Proxy enabled, and have a connector installed, you can skip this section and move
on to Add your app to Azure AD with Application Proxy.
The Application Proxy connector is a Windows Server service that directs the traffic from your remote employees
to your published apps. For more detailed installation instructions, see Enable Application Proxy in the Azure
portal.
1. Sign in to the Azure portal as a global administrator.
2. Select Azure Active Directory > Application proxy.
3. Select Download Connector to start the Application Proxy connector download. Follow the installation
instructions.
4. Downloading the connector should automatically enable Application Proxy for your directory, but if not you
can select Enable Application Proxy.
Add your app to Azure AD with Application Proxy
There are two actions you need to take in the Azure portal. First, you need to publish your application with
Application Proxy. Then, you need to collect some information about the app that you can use during the
PingAccess steps.
Follow these steps to publish your app. For a more detailed walkthrough of steps 1-8, see Publish applications
using Azure AD Application Proxy.
1. If you didn't in the last section, sign in to the Azure portal as a global administrator.
2. Select Azure Active Directory > Enterprise applications.
3. Select Add at the top of the blade.
4. Select On-premises application.
5. Fill out the required fields with information about your new app. Use the following guidance for the settings:
Internal URL: Normally you provide the URL that takes you to the app’s sign in page when you’re on
the corporate network. For this scenario the connector needs to treat the PingAccess proxy as the
front page of the app. Use this format: https://<host name of your PA server>:<port> . The port is
3000 by default, but you can configure it in PingAccess.
WARNING
For this type of SSO, the internal URL must use https and cannot use http.
Pre-authentication method: Azure Active Directory

Translate URL in Headers: No
NOTE
If this is your first application, use port 3000 to start and come back to update this setting if you change your
PingAccess configuration. If this is your second or later app, this will need to match the Listener you’ve configured in
PingAccess. Learn more about listeners in PingAccess.
6. Select Add at the bottom of the blade. Your application is added, and the quick start menu opens.
7. In the quick start menu, select Assign a user for testing, and add at least one user to the application. Make
sure this test account has access to the on-premises application.
8. Select Assign to save the test user assignment.
9. On the app management blade, select Single sign-on.
10. Choose Header-based sign-on from the drop-down menu. Select Save.
TIP
If this is your first time using header-based single sign-on, you need to install PingAccess. To make sure your Azure
subscription is automatically associated with your PingAccess installation, use the link on this single sign-on page to
download PingAccess. You can open the download site now, or come back to this page later.
11. Close the Enterprise applications blade or scroll all the way to the left to return to the Azure Active Directory
menu.
12. Select App registrations.
13. Select the app you just added, then Reply URLs.
14. Check to see if the external URL that you assigned to your app in step 5 is in the Reply URLs list. If it’s not,
add it now.
15. On the app settings blade, select Required permissions.
16. Select Add. For the API, choose Windows Azure Active Directory, then Select. For the permissions,
choose Read and write all applications and Sign in and read user profile, then Select and Done.
17. Grant permissions before you close the permissions screen.
Collect information for the PingAccess steps

1. On your app settings blade, select Properties.
2. Save the Application Id value. This is used for the client ID when you configure PingAccess.
3. On the app settings blade, select Keys.
4. Create a key by entering a key description and choosing an expiration date from the drop-down menu.
5. Select Save. A GUID appears in the Value field.
Save this value now, as you won’t be able to see it again after you close this window.
6. Close the App registrations blade or scroll all the way to the left to return to the Azure Active Directory
menu.
7. Select Properties.
8. Save the Directory ID GUID.
Optional - Update GraphAPI to send custom fields
For a list of security tokens that Azure AD sends for authentication, see Azure AD token reference. If you need a
custom claim that sends other tokens, use Graph Explorer or the manifest for the application in the Azure Portal to
set the app field acceptMappedClaims to True.
This example uses Graph Explorer:
PATCH https://graph.windows.net/myorganization/applications/<object_id_GUID_of_your_application>
{
"acceptMappedClaims":true
}
This example uses the Azure portal to udpate the acceptedMappedClaims field:
1. Sign in to the Azure portal as a global administrator.
2. Select Azure Active Directory > App registrations.
3. Select your application > Manifest.
4. Select Edit, search for the acceptedMappedClaims field and change the value to true.
5. Select Save.
NOTE
To use a custom claim, you must also have a custom policy defined and assigned to the application. This policy should
include all required custom attributes.
Policy definition and assignment can be done through PowerShell, Azure AD Graph Explorer, or MS Graph. If you are doing
this in PowerShell, you may need to first use New-AzureADPolicy and then assign it to the application with
Set-AzureADServicePrincipalPolicy . For more information see the Azure AD Policy documentation.
Optional - Use a custom claim

To make your application use a custom claim and include additional fields, be sure that you have also created a
custom claims mapping policy and assigned it to the application.
Download PingAccess and configure your app

Now that you've completed all the Azure Active Directory setup steps, you can move on to configuring PingAccess.
The detailed steps for the PingAccess part of this scenario continue in the Ping Identity documentation, Configure
PingAccess for Azure AD.
Those steps walk you through the process of getting a PingAccess account if you don't already have one, installing
the PingAccess Server, and creating an Azure AD OIDC Provider connection with the Directory ID that you copied
from the Azure portal. Then, you use the Application ID and Key values to create a Web Session on PingAccess.
After that, you can set up identity mapping and create a virtual host, site, and application.
Test your app
When you've completed all these steps, your app should be up and running. To test it, open a browser and
navigate to the external URL that you created when you published the app in Azure. Sign in with the test account
that you assigned to the app.
Next steps
Configure PingAccess for Azure AD
How does Azure AD Application Proxy provide single sign-on?
Troubleshoot Application Proxy
Password vaulting for single sign-on with Application
Proxy
Azure Active Directory Application Proxy helps you improve productivity by publishing on-premises applications
so that remote employees can securely access them, too. In the Azure portal, you can also set up single sign-on
(SSO) to these apps. Your users only need to authenticate with Azure AD, and they can access your enterprise
application without having to sign in again.
Application Proxy supports several single sign-on modes. Password-based sign-on is intended for applications that
use a username/password combination for authentication. When you configure password-based sign-on for your
application, your users have to sign in to the on-premises application once. After that, Azure Active Directory stores
the sign-in information and automatically provides it to the application when your users access it remotely.
You should already have published and tested your app with Application Proxy. If not, follow the steps in Publish
applications using Azure AD Application Proxy then come back here.
Set up password vaulting for your application

1. Sign in to the Azure portal as an administrator.
2. Select Azure Active Directory > Enterprise applications > All applications.
3. From the list, select the app that you want to set up with SSO.
4. Select Single sign-on.
5. For the SSO mode, choose Password-based Sign-on.

6. For the Sign-on URL, enter the URL for the page where users enter their username and password to sign in
to your app outside of the corporate network. This may be the External URL that you created when you
published the app through Application Proxy.
7. Select Save.
Test your app

Go to external URL that you configured for remote access to your application. Sign in with your credentials for that
app (or the credentials for a test account that you set up with access). Once you sign in successfully, you should be
able to leave the app and come back without entering your credentials again.
Next steps
Read about other ways to implement Single sign-on with Application Proxy
Learn about Security considerations for accessing apps remotely with Azure AD Application Proxy
Understand Azure AD Application Proxy connectors
Connectors are what make Azure AD Application Proxy possible. They are simple, easy to deploy and maintain,
and super powerful. This article discusses what connectors are, how they work, and some suggestions for how to
optimize your deployment.
What is an Application Proxy connector?

Connectors are lightweight agents that sit on-premises and facilitate the outbound connection to the Application
Proxy service. Connectors must be installed on a Windows Server that has access to the backend application. You
can organize connectors into connector groups, with each group handling traffic to specific applications.
Connectors load-balance automatically, and can help to optimize your network structure.
Requirements and deployment

To deploy Application Proxy successfully, you need at least one connector, but we recommend two or more for
greater resiliency. Install the connector on a Windows Server 2012 R2 or 2016 machine. The connector needs to
be able to communicate with the Application Proxy service as well as the on-premises applications that you
publish.
For more information about the network requirements for the connector server, see Get started with Application
Proxy and install a connector.
Maintenance
The connectors and the service take care of all the high availability tasks. They can be added or removed
dynamically. Each time a new request arrives it is routed to one of the connectors that is currently available. If a
connector is temporarily not available, it doesn't respond to this traffic.
The connectors are stateless and have no configuration data on the machine. The only data they store is the
settings for connecting the service and its authentication certificate. When they connect to the service, they pull all
the required configuration data and refresh it every couple of minutes.
Connectors also poll the server to find out whether there is a newer version of the connector. If one is found, the
connectors update themselves.
You can monitor your connectors from the machine they are running on, using either the event log and
performance counters. Or you can view their status from the Application Proxy page of the Azure portal:
You don't have to manually delete connectors that are unused. When a connector is running, it remains active as
it connects to the service. Unused connectors are tagged as inactive and are removed after 10 days of inactivity. If
you do want to uninstall a connector, though, uninstall both the Connector service and the Updater service from
the server. Restart your computer to fully remove the service.
Automatic updates
Azure AD provides automatic updates for all the connectors that you deploy. As long as the Application Proxy
Connector Updater service is running, your connectors update automatically. If you don’t see the Connector
Updater service on your server, you need to reinstall your connector to get any updates.
If you don't want to wait for an automatic update to come to your connector, you can perform a manual upgrade.
Go to the connector download page on the server where your connector is located and select Download. This
process kicks off an upgrade for the local connector.
For tenants with multiple connectors, the automatic updates target one connector at a time in each group to
prevent downtime in your environment.
You may experience downtime when your connector updates if:
You only have one connector. To avoid this downtime and improve high availability, we recommend you
install a second connector and create a connector group.
A connector was in the middle of a transaction when the update began. Although the initial transaction is lost,
your browser should automatically retry the operation or you can refresh your page. When the request is
resent, the traffic is routed to a backup connector.
Creating connector groups

Connector groups enable you to assign specific connectors to serve specific applications. You can group a
number of connectors together, and then assign each application to a group.
Connector groups make it easier to manage large deployments. They also improve latency for tenants that have
applications hosted in different regions, because you can create location-based connector groups to serve only
local applications.
To learn more about connector groups, see Publish applications on separate networks and locations using
connector groups.
Capacity Planning
While connectors will automatically load balance within a connector group, it is also important to make sure you
have planned enough capacity between connectors to handle the expected traffic volume. In general, the more
users you have, the larger a machine you will need. Below is a table giving an outline of the volume different
machines can handle. Please note it is all based on expected Transactions Per Second (TPS) rather than by user
since usage patterns vary and cannot be used to predict load. Also note that there will be some differences based
on the size of the responses and the backend application response time - larger response sizes and slower
response times will result in a lower Max TPS.
CORES RAM EXPECTED LATENCY (MS)-P99 MAX TPS
2 8 325 586
4 16 320 1150
8 32 270 1190
CORES RAM EXPECTED LATENCY (MS)-P99 MAX TPS
16 64 245 1200*
* This machine had a connection limit of 800. For all other machines we used the default 200 connection limit.
NOTE
There is not much difference in the maximum TPS between 4, 8, and 16 core machines. The main difference between those
is in the expected latency.
Security and networking

Connectors can be installed anywhere on the network that allows them to send requests to the Application Proxy
service. What's important is that the computer running the connector also has access to your apps. You can install
connectors inside of your corporate network or on a virtual machine that runs in the cloud. Connectors can run
within a demilitarized zone (DMZ), but it's not necessary because all traffic is outbound so your network stays
secure.
Connectors only send outbound requests. The outbound traffic is sent to the Application Proxy service and to the
published applications. You don't have to open inbound ports because traffic flows both ways once a session is
established. You don't have to set up load balancing between the connectors or configure inbound access
through your firewalls.
For more information about configuring outbound firewall rules, see Work with existing on-premises proxy
servers.
Use the Azure AD Application Proxy Connector Ports Test Tool to verify that your connector can reach the
Application Proxy service. At a minimum, make sure that the Central US region and the region closest to you have
all green checkmarks. Beyond that, more green checkmarks means greater resiliency.
Performance and scalability

Scale for the Application Proxy service is transparent, but scale is a factor for connectors. You need to have
enough connectors to handle peak traffic. However, you don't need to configure load balancing because all
connectors within a connector group automatically load balance.
Since connectors are stateless, they are not affected by the number of users or sessions. Instead, they respond to
the number of requests and their payload size. With standard web traffic, an average machine can handle a
couple thousand requests per second. The specific capacity depends on the exact machine characteristics.
The connector performance is bound by CPU and networking. CPU performance is needed for SSL encryption and
decryption, while networking is important to get fast connectivity to the applications and the online service in
Azure.
In contrast, memory is less of an issue for connectors. The online service takes care of much of the processing and
all unauthenticated traffic. Everything that can be done in the cloud is done in the cloud.
The load balancing happens between connectors of a given connector group. We do a variation of a round-robin
to determine which connector in the group serves a particular request. After choosing a the connector, we
maintain a session affinity between that user and application for the duration of the session. If for any reason that
connector or machine become unavailable, the traffic will start going to another connector in the group. This
resiliency is also why we recommend having multiple connectors.
Another factor that affects performance is the quality of the networking between the connectors, including:
The online service: Slow or high-latency connections to the Application Proxy service in Azure influence the
connector performance. For the best performance, connect your organization to Azure with Express Route.
Otherwise, have your networking team ensure that connections to Azure are handled as efficiently as possible.
The backend applications: In some cases, there are additional proxies between the connector and the
backend applications that can slow or prevent connections. To troubleshoot this scenario, open a browser
from the connector server and try to access the application. If you run the connectors in Azure but the
applications are on-premises, the experience might not be what your users expect.
The domain controllers: If the connectors perform SSO using Kerberos Constrained Delegation, they contact
the domain controllers before sending the request to the backend. The connectors have a cache of Kerberos
tickets, but in a busy environment the responsiveness of the domain controllers can affect performance. This
issue is more common for connectors that run in Azure but communicate with domain controllers that are on-
premises.
For more information about optimizing your network, see Network topology considerations when using Azure
Active Directory Application Proxy.
Domain joining
Connectors can run on a machine that is not domain-joined. However, if you want single sign-on (SSO) to
applications that use Integrated Windows Authentication (IWA), you need a domain-joined machine. In this case,
the connector machines must be joined to a domain that can perform Kerberos Constrained Delegation on behalf
of the users for the published applications.
Connectors can also be joined to domains or forests that have a partial trust, or to read-only domain controllers.
Connector deployments on hardened environments

Usually, connector deployment is straightforward and requires no special configuration. However, there are some
unique conditions that should be considered:
Organizations that limit the outbound traffic must open required ports.
FIPS-compliant machines might be required to change their configuration to allow the connector processes to
generate and store a certificate.
Organizations that lock down their environment based on the processes that issue the networking requests
have to make sure that both connector services are enabled to access all required ports and IPs.
In some cases, outbound forward proxies may break the two-way certificate authentication and cause the
communication to fail.
Connector authentication
To provide a secure service, connectors have to authenticate toward the service, and the service has to
authenticate toward the connector. This authentication is done using client and server certificates when the
connectors initiate the connection. This way the administrator’s username and password are not stored on the
connector machine.
The certificates used are specific to the Application Proxy service. They get created during the initial registration
and are automatically renewed by the connectors every couple of months.
If a connector is not connected to the service for several months, its certificates may be outdated. In this case,
uninstall and reinstall the connector to trigger registration. You can run the following PowerShell commands:
Import-module AppProxyPSModule
Register-AppProxyConnector
Under the hood
Connectors are based on Windows Server Web Application Proxy, so they have most of the same management
tools including Windows Event Logs
and Windows performance counters.
The connectors have both admin and session logs. The admin logs include key events and their errors. The
session logs include all the transactions and their processing details.
To see the logs, go to the Event Viewer, open the View menu, and enable Show analytic and debug logs. Then,
enable them to start collecting events. These logs do not appear in Web Application Proxy in Windows Server
2012 R2, as the connectors are based on a more recent version.
You can examine the state of the service in the Services window. The connector comprises two Windows Services:
the actual connector, and the updater. Both of them must run all the time.
Next steps
Publish applications on separate networks and locations using connector groups
Work with existing on-premises proxy servers
Troubleshoot Application Proxy and connector errors
How to silently install the Azure AD Application Proxy Connector
Security considerations for accessing apps remotely
with Azure AD Application Proxy
This article explains the components that work to keep your users and applications safe when you use Azure Active
Directory Application Proxy.
The following diagram shows how Azure AD enables secure remote access to your on-premises applications.
Security benefits
Azure AD Application Proxy offers the following security benefits:
Authenticated access
If you choose to use Azure Active Directory preauthentication, then only authenticated connections can access your
network.
Azure AD Application Proxy relies on the Azure AD security token service (STS) for all authentication.
Preauthentication, by its very nature, blocks a significant number of anonymous attacks, because only
authenticated identities can access the back-end application.
If you choose Passthrough as your preauthentication method, you don't get this benefit.
Conditional access
Apply richer policy controls before connections to your network are established.
With conditional access, you can define restrictions on what traffic is allowed to access your back-end applications.
You can create policies that restrict sign-ins based on location, strength of authentication, and user risk profile.
You can also use conditional access to configure Multi-Factor Authentication policies, adding another layer of
security to your user authentications.
Traffic termination
All traffic is terminated in the cloud.
Because Azure AD Application Proxy is a reverse-proxy, all traffic to back-end applications is terminated at the
service. The session can get reestablished only with the back-end server, which means that your back-end servers
are not exposed to direct HTTP traffic. This configuration means that you are better protected from targeted attacks.
All access is outbound
You don't need to open inbound connections to the corporate network.
Application Proxy connectors only use outbound connections to the Azure AD Application Proxy service, which
means that there is no need to open firewall ports for incoming connections. Traditional proxies required a
perimeter network (also known as DMZ, demilitarized zone, or screened subnet) and allowed access to
unauthenticated connections at the network edge. This scenario required investments in web application firewall
products to analyze traffic and protect the environment. With Application Proxy, you don't need a perimeter
network because all connections are outbound and take place over a secure channel.
For more information about connectors, see Understand Azure AD Application Proxy connectors.
Cloud-scale analytics and machine learning
Get cutting-edge security protection.
Because it's part of Azure Active Directory, Application Proxy can leverage Azure AD Identity Protection, with data
from the Microsoft Security Response Center and Digital Crimes Unit. Together we proactively identify
compromised accounts and offer protection from high-risk sign-ins. We take into account numerous factors to
determine which sign-in attemps are high risk. These factors include flagging infected devices, anonymizing
networks, and atypical or unlikely locations.
Many of these reports and events are already available through an API for integration with your security
information and event management (SIEM) systems.
Remote access as a service
You don’t have to worry about maintaining and patching on-premises servers.
Unpatched software still accounts for a large number of attacks. Azure AD Application Proxy is an Internet-scale
service that Microsoft owns, so you always get the latest security patches and upgrades.
To improve the security of applications published by Azure AD Application Proxy, we block web crawler robots
from indexing and archiving your applications. Each time a web crawler robot tries to retrieve the robot's settings
for a published app, Application Proxy replies with a robots.txt file that includes User-agent: * Disallow: / .
DDOS prevention
Applications published through Application Proxy are protected against Distributed Denial of Service (DDOS)
attacks.
The Application Proxy service monitors the amount of traffic attempting to reach your applications and network. If
the number of devices requesting remote access to your applications spikes, Microsoft throttles access to your
network.
Microsoft watches traffic patterns for individual applications and for your subscription as a whole. If one
application receives higher than normal requests, then requests to access that application are denied for a short
period of time. If you receive higher than normal requests across your whole subscription, then requests to access
any of your apps are denied. This preventative measure keeps your application servers from being overloaded by
remote access requests, so that your on-premises users can keep accessing their apps.
Under the hood

Azure AD Application Proxy consists of two parts:
The cloud-based service: This service runs in Azure, and is where the external client/user connections are made.
The on-premises connector: An on-premises component, the connector listens for requests from the Azure AD
Application Proxy service and handles connections to the internal applications.
A flow between the connector and the Application Proxy service is established when:
The connector is first set up.
The connector pulls configuration information from the Application Proxy service.
A user accesses a published application.
NOTE
All communications occur over SSL, and they always originate at the connector to the Application Proxy service. The service is
outbound only.
The connector uses a client certificate to authenticate to the Application Proxy service for nearly all calls. The only
exception to this process is the initial setup step, where the client certificate is established.
Installing the connector
When the connector is first set up, the following flow events take place:
1. The connector registration to the service happens as part of the installation of the connector. Users are
prompted to enter their Azure AD admin credentials. The token acquired from this authentication is then
presented to the Azure AD Application Proxy service.
2. The Application Proxy service evaluates the token. It checks whether the user is a company administrator in the
tenant. If the user is not an administrator, the process is terminated.
3. The connector generates a client certificate request and passes it, along with the token, to the Application Proxy
service. The service in turn verifies the token and signs the client certificate request.
4. The connector uses the client certificate for future communication with the Application Proxy service.
5. The connector performs an initial pull of the system configuration data from the service using its client
certificate, and it is now ready to take requests.
Updating the configuration settings
Whenever the Application Proxy service updates the configuration settings, the following flow events take place:
1. The connector connects to the configuration endpoint within the Application Proxy service by using its client
certificate.
2. After the client certificate is validated, the Application Proxy service returns configuration data to the connector
(for example, the connector group that the connector should be part of).
3. If the current certificate is more than 180 days old, the connector generates a new certificate request, which
effectively updates the client certificate every 180 days.
Accessing published applications
When users access a published application, the following events take place between the Application Proxy service
and the Application Proxy connector:
1. The service authenticates the user for the app
2. The service places a request in the connector queue
3. A connector processes the request from the queue
4. The connector waits for a response
5. The service streams data to the user
To learn more about what takes place in each of these steps, keep reading.
1. The service authenticates the user for the app
If you configured the app to use Passthrough as its preauthentication method, the steps in this section are skipped.
If you configured the app to preauthenticate with Azure AD, users are redirected to the Azure AD STS to
authenticate, and the following steps take place:
1. Application Proxy checks for any conditional access policy requirements for the specific application. This step
ensures that the user has been assigned to the application. If two-step verification is required, the
authentication sequence prompts the user for a second authentication method.
2. After all checks have passed, the Azure AD STS issues a signed token for the application and redirects the
user back to the Application Proxy service.
3. Application Proxy verifies that the token was issued to correct the application. It performs other checks also,
such as ensuring that the token was signed by Azure AD, and that it is still within the valid window.
4. Application Proxy sets an encrypted authentication cookie to indicate that authentication to the application
has occurred. The cookie includes an expiration timestamp that's based on the token from Azure AD and
other data, such as the user name that the authentication is based on. The cookie is encrypted with a private
key known only to the Application Proxy service.
5. Application Proxy redirects the user back to the originally requested URL.
If any part of the preauthentication steps fails, the user’s request is denied, and the user is shown a message
indicating the source of the problem.
2. The service places a request in the connector queue
Connectors keep an outbound connection open to the Application Proxy service. When a request comes in, the
service queues up the request on one of the open connections for the connector to pick up.
The request includes items from the application, such as the request headers, data from the encrypted cookie, the
user making the request, and the request ID. Although data from the encrypted cookie is sent with the request, the
authentication cookie itself is not.
3. The connector processes the request from the queue.
Based on the request, Application Proxy performs one of the following actions:
If the request is a simple operation (for example, there is no data within the body as is with a RESTful GET
request), the connector makes a connection to the target internal resource and then waits for a response.
If the request has data associated with it in the body (for example, a RESTful POST operation), the connector
makes an outbound connection by using the client certificate to the Application Proxy instance. It makes this
connection to request the data and open a connection to the internal resource. After it receives the request
from the connector, the Application Proxy service begins accepting content from the user and forwards data
to the connector. The connector, in turn, forwards the data to the internal resource.
4. The connector waits for a response.
After the request and transmission of all content to the back end is complete, the connector waits for a response.
After it receives a response, the connector makes an outbound connection to the Application Proxy service, to
return the header details and begin streaming the return data.
5. The service streams data to the user.
Some processing of the application may occur here. If you configured Application Proxy to translate headers or
URLs in your application, that processing happens as needed during this step.
Next steps
Network topology considerations when using Azure AD Application Proxy
Network topology considerations when using Azure
Active Directory Application Proxy
This article explains network topology considerations when using Azure Active Directory (Azure AD) Application
Proxy for publishing and accessing your applications remotely.
Traffic flow
When an application is published through Azure AD Application Proxy, traffic from the users to the applications
flows through three connections:
1. The user connects to the Azure AD Application Proxy service public endpoint on Azure
2. The Application Proxy service connects to the Application Proxy connector
3. The Application Proxy connector connects to the target application
Tenant location and Application Proxy service

When you sign up for an Azure AD tenant, the region of your tenant is determined by the country you specify.
When you enable Application Proxy, the Application Proxy service instances for your tenant are chosen or created
in the same region as your Azure AD tenant, or the closest region to it.
For example, if your Azure AD tenant’s region is the European Union (EU), all your Application Proxy connectors
use service instances in Azure datacenters in the EU. When your users access published applications, their traffic
goes through the Application Proxy service instances in this location.
Considerations for reducing latency

All proxy solutions introduce latency into your network connection. No matter which proxy or VPN solution you
choose as your remote access solution, it always includes a set of servers enabling the connection to inside your
corporate network.
Organizations typically include server endpoints in their perimeter network. With Azure AD Application Proxy,
however, traffic flows through the proxy service in the cloud while the connectors reside on your corporate
network. No perimeter network is required.
The next sections contain additional suggestions to help you reduce latency even further.
Connector placement
Application Proxy chooses the location of instances for you, based on your tenant location. However, you get to
decide where to install the connector, giving you the power to define the latency characteristics of your network
traffic.
When setting up the Application Proxy service, ask the following questions:
Where is the app located?
Where are most users who access the app located?
Where is the Application Proxy instance located?
Do you already have a dedicated network connection to Azure datacenters set up, like Azure ExpressRoute or a
similar VPN?
The connector has to communicate with both Azure and your applications (steps 2 and 3 in the Traffic flow
diagram), so the placement of the connector affects the latency of those two connections. When evaluating the
placement of the connector, keep in mind the following points:
If you want to use Kerberos constrained delegation (KCD) for single sign-on, then the connector needs a line of
sight to a datacenter. Additionally, the connector server needs to be domain joined.
When in doubt, install the connector closer to the application.
General approach to minimize latency
You can minimize the latency of the end-to-end traffic by optimizing each network connection. Each connection
can be optimized by:
Reducing the distance between the two ends of the hop.
Choosing the right network to traverse. For example, traversing a private network rather than the public
Internet may be faster, due to dedicated links.
If you have a dedicated VPN or ExpressRoute link between Azure and your corporate network, you may want to
use that.
Focus your optimization strategy

There's little that you can do to control the connection between your users and the Application Proxy service. Users
may access your apps from a home network, a coffee shop, or a different country. Instead, you can optimize the
connections from the Application Proxy service to the Application Proxy connectors to the apps. Consider
incorporating the following patterns in your environment.
Pattern 1: Put the connector close to the application
Place the connector close to the target application in the customer network. This configuration minimizes step 3 in
the topography diagram, because the connector and application are close.
If your connector needs a line of sight to the domain controller, then this pattern is advantageous. Most of our
customers use this pattern, because it works well for most scenarios. This pattern can also be combined with
pattern 2 to optimize traffic between the service and the connector.
Pattern 2: Take advantage of ExpressRoute with public peering
If you have ExpressRoute set up with public peering, you can use the faster ExpressRoute connection for traffic
between Application Proxy and the connector. The connector is still on your network, close to the app.
Pattern 3: Take advantage of ExpressRoute with private peering
If you have a dedicated VPN or ExpressRoute set up with private peering between Azure and your corporate
network, you have another option. In this configuration, the virtual network in Azure is typically considered as an
extension of the corporate network. So you can install the connector in the Azure datacenter, and still satisfy the
low latency requirements of the connector-to-app connection.
Latency is not compromised because traffic is flowing over a dedicated connection. You also get improved
Application Proxy service-to-connector latency because the connector is installed in an Azure datacenter close to
your Azure AD tenant location.
Other approaches
Although the focus of this article is connector placement, you can also change the placement of the application to
get better latency characteristics.
Increasingly, organizations are moving their networks into hosted environments. This enables them to place their
apps in a hosted environment that is also part of their corporate network, and still be within the domain. In this
case, the patterns discussed in the preceding sections can be applied to the new application location. If you're
considering this option, see Azure AD Domain Services.
Additionally, consider organizing your connectors using connector groups to target apps that are in different
locations and networks.
Common use cases

In this section, we walk through a few common scenarios. Assume that the Azure AD tenant (and therefore proxy
service endpoint) is located in the United States (US). The considerations discussed in these use cases also apply to
other regions around the globe.
For these scenarios, we call each connection a "hop" and number them for easier discussion:
Hop 1: User to the Application Proxy service
Hop 2: Application Proxy service to the Application Proxy connector
Hop 3: Application Proxy connector to the target application
Use case 1
Scenario: The app is in an organization's network in the US, with users in the same region. No ExpressRoute or
VPN exists between the Azure datacenter and the corporate network.
Recommendation: Follow pattern 1, explained in the previous section. For improved latency, consider using
ExpressRoute, if needed.
This is a simple pattern. You optimize hop 3 by placing the connector near the app. This is also a natural choice,
because the connector typically is installed with line of sight to the app and to the datacenter to perform KCD
operations.
Use case 2
Scenario: The app is in an organization's network in the US, with users spread out globally. No ExpressRoute or
VPN exists between the Azure datacenter and the corporate network.
Recommendation: Follow pattern 1, explained in the previous section.
Again, the common pattern is to optimize hop 3, where you place the connector near the app. Hop 3 is not typically
expensive, if it is all within the same region. However, hop 1 can be more expensive depending on where the user
is, because users across the world must access the Application Proxy instance in the US. It's worth noting that any
proxy solution has similar characteristics regarding users being spread out globally.
Use case 3
Scenario: The app is in an organization's network in the US. ExpressRoute with public peering exists between
Azure and the corporate network.
Recommendation: Follow patterns 1 and 2, explained in the previous section.
First, place the connector as close as possible to the app. Then, the system automatically uses ExpressRoute for hop
2.
If the ExpressRoute link is using public peering, the traffic between the proxy and the connector flows over that link.
Hop 2 has optimized latency.
Use case 4
Scenario: The app is in an organization's network in the US. ExpressRoute with private peering exists between
Azure and the corporate network.
Recommendation: Follow pattern 3, explained in the previous section.
Place the connector in the Azure datacenter that is connected to the corporate network through ExpressRoute
private peering.
The connector can be placed in the Azure datacenter. Since the connector still has a line of sight to the application
and the datacenter through the private network, hop 3 remains optimized. In addition, hop 2 is optimized further.
Use case 5
Scenario: The app is in an organization's network in the EU, with the Application Proxy instance and most users in
the US.
Recommendation: Place the connector near the app. Because US users are accessing an Application Proxy
instance that happens to be in the same region, hop 1 is not too expensive. Hop 3 is optimized. Consider using
ExpressRoute to optimize hop 2.
You can also consider using one other variant in this situation. If most users in the organization are in the US, then
chances are that your network extends to the US as well. Place the connector in the US, and use the dedicated
internal corporate network line to the application in the EU. This way hops 2 and 3 are optimized.
Next steps
Enable Application Proxy
Enable conditional access
Compare remote access solutions
Azure Active Directory Application Proxy is one of two remote access solutions that Microsoft offers. The other is
Web Application Proxy, the on-premises version. These two solutions replace earlier products that Microsoft
offered: Microsoft Forefront Threat Management Gateway (TMG) and Unified Access Gateway (UAG). Use this article
to understand how these four solutions compare to each other. For those of you still using the deprecated TMG or
UAG solutions, use this article to help plan your migration to one of the Application Proxy.
Feature comparison
Use this table to understand how Threat Management Gateway (TMG), Unified Access Gateway (UAG), Web
Application Proxy (WAP), and Azure AD Application Proxy (AP) compare to each other.
FEATURE TMG UAG WAP AP
Certificate Yes Yes - -

authentication
Selectively publish Yes Yes Yes Yes

browser apps
Preauthentication and Yes Yes Yes Yes

single sign-on
Layer 2/3 firewall Yes Yes - -
Forward proxy Yes - - -

capabilities
VPN capabilities Yes Yes - -
Rich protocol support - Yes Yes, if running over Yes, if running over
HTTP HTTP or through
Remote Desktop
Gateway
Serves as ADFS proxy - Yes Yes -

server
One portal for - Yes - Yes

application access
Response body link Yes Yes - Yes

translation
Authentication with - Yes - Yes, with PingAccess

headers
Cloud-scale security - - - Yes

FEATURE TMG UAG WAP AP
Conditional access - Yes - Yes
No components in - - - Yes
the demilitarized zone
(DMZ)
No inbound - - - Yes
connections
For most scenarios, we recommend Azure AD Application as the modern solution. Web Application Proxy is only
preferred in scenarios that require a proxy server for AD FS, and you can't use custom domains in Azure Active
Directory.
Azure AD Application Proxy offers unique benefits when compared to similar products, including:
Extending Azure AD to on-premises resources
Cloud-scale security and protection
Features like conditional access and Multi-Factor Authentication are easy to enable
No componenet in the demilitarized zone
No inbound connections required
One access panel that your users can go to for all their applications, including O365, Azure AD integrated SaaS
apps, and your on-premises web apps.
Next steps
Use Azure AD Application to provide secure remote access to on-premises applications
Transition from Forefront TMG and UAG to Application Proxy.
Publish applications on separate networks and
locations using connector groups
Customers utilize Azure AD's Application Proxy for more and more scenarios and applications. So we've made
App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so
that you can assign specific connectors to serve specific applications. This capability gives you more control and
ways to optimize your Application Proxy deployment.
Each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same
connector group act as a separate unit for high-availability and load balancing. All connectors belong to a
connector group. If you don't create groups, then all your connectors are in a default group. Your admin can
create new groups and assign connectors to them in the Azure portal.
All applications are assigned to a connector group. If you don't create groups, then all your applications are
assigned to a default group. But if you organize your connectors into groups, you can set each application to work
with a specific connector group. In this case, only the connectors in that group serve the application upon request.
This feature is useful if your applications are hosted in different locations. You can create connector groups based
on location, so that applications are always served by connectors that are physically close to them.
TIP
If you have a large Application Proxy deployment, don't assign any applications to the default connector group. That way,
new connectors don't receive any live traffic until you assign them to an active connector group. This configuration also
enables you to put connectors in an idle mode by moving them back to the default group, so that you can perform
maintenance without impacting your users.
Prerequisites
To group your connectors, you have to make sure you installed multiple connectors. When you install a new
connector, it automatically joins the Default connector group.
Create connector groups

Use these steps to create as many connector groups as you want.
2. Select Azure Active Directory > Enterprise applications > Application proxy.
3. Select New connector group. The New Connector Group blade appears.
4. Give your new connector group a name, then use the dropdown menu to select which connectors belong
in this group.
5. Select Save.
Assign applications to your connector groups
Use these steps for each application that you've published with Application Proxy. You can assign an application
to a connector group when you first publish it, or you can use these steps to change the assignment whenever
you want.
1. From the management dashboard for your directory, select Enterprise applications > All applications >
the application you want to assign to a connector group > Application Proxy.
2. Use the Connector Group dropdown menu to select the group you want the application to use.
3. Select Save to apply the change.
Use cases for connector groups

Connector groups are useful for various scenarios, including:
Sites with multiple interconnected datacenters
Many organizations have a number of interconnected datacenters. In this case, you want to keep as much traffic
within the datacenter as possible because cross-datacenter links are expensive and slow. You can deploy
connectors in each datacenter to serve only the applications that reside within the datacenter. This approach
minimizes cross-datacenter links and provides an entirely transparent experience to your users.
Applications installed on isolated networks
Applications can be hosted in networks that are not part of the main corporate network. You can use connector
groups to install dedicated connectors on isolated networks to also isolate applications to the network. This
usually happens when a third-party vendor maintains a specific application for your organization.
Connector groups allow you to install dedicated connectors for those networks that publish only specific
applications, making it easier and more secure to outsource application management to third-party vendors.
Applications installed on IaaS
For applications installed on IaaS for cloud access, connector groups provide a common service to secure the
access to all the apps. Connector groups don't create additional dependency on your corporate network, or
fragment the app experience. Connectors can be installed on every cloud datacenter and serve only applications
that reside in that network. You can install several connectors to achieve high availability.
Take as an example an organization that has several virtual machines connected to their own IaaS hosted virtual
network. To allow employees to use these applications, these private networks are connected to the corporate
network using site-to-site VPN. This provides a good experience for employees that are located on-premises. But,
it may not be ideal for remote employees, because it requires additional on-premises infrastructure to route
access, as you can see in the diagram below:
With Azure AD Application Proxy connector groups, you can enable a common service to secure the access to all
applications without creating additional dependency on your corporate network:
Multi-forest – different connector groups for each forest

Most customers who have deployed Application Proxy are using its single-sign-on (SSO) capabilities by
performing Kerberos Constrained Delegation (KCD). To achieve this, the connector’s machines need to be joined
to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities. But for
companies who have distinct multi-forest environments with no trust between them, a single connector cannot be
used for all forests.
In this case, specific connectors can be deployed per forest, and set to serve applications that were published to
serve only the users of that specific forest. Each connector group represents a different forest. While the tenant
and most of the experience is unified for all forests, users can be assigned to their forest applications using Azure
AD groups.
Disaster Recovery sites
There are two different approaches you can take with a disaster recovery (DR) site, depending on how your sites
are implemented:
If your DR site is built in active-active mode where it is exactly like the main site and has the same networking
and AD settings, you can create the connectors on the DR site in the same connector group as the main site.
This enables Azure AD to detect failovers for you.
If your DR site is separate from the main site, you can create a different connector group in the DR site, and
either 1) have backup applications or 2) manually divert the existing application to the DR connector group as
needed.
Serve multiple companies from a single tenant
There are many different ways to implement a model in which a single service provider deploys and maintains
Azure AD related services for multiple companies. Connector groups help the admin segregate the connectors
and applications into different groups. One way, which is suitable for small companies, is to have a single Azure
AD tenant while the different companies have their own domain name and networks. This is also true for M&A
scenarios and situations where a single IT division serves several companies for regulatory or business reasons.
Sample configurations
Some examples that you can implement, include the following connector groups.
Default configuration – no use for connector groups
If you don’t use connector groups, your configuration would look like this:
This configuration is sufficient for small deployments and tests. It will also work well if your organization has a flat
network topology.
Default configuration and an isolated network
This configuration is an evolution of the default one, in which there is a specific app that runs in an isolated
network such as IaaS virtual network:
Recommended configuration – several specific groups and a default group for idle
The recommended configuration for large and complex organizations is to have the default connector group as a
group that doesn’t serve any applications and is used for idle or newly installed connectors. All applications are
served using customized connector groups. This enables all the complexity of the scenarios described above.
In the example below, the company has two datacenters, A and B, with two connectors that serve each site. Each
site has different applications that run on it.
Next steps
Work with existing on-premises proxy servers
This article explains how to configure Azure Active Directory (Azure AD) Application Proxy connectors to work with
outbound proxy servers. It is intended for customers with network environments that have existing proxies.
We start by looking at these main deployment scenarios:
Configure connectors to bypass your on-premises outbound proxies.
Configure connectors to use an outbound proxy to access Azure AD Application Proxy.
For more information about how connectors work, see Understand Azure AD Application Proxy connectors.
Bypass outbound proxies

Connectors have underlying OS components that make outbound requests. These components automatically
attempt to locate a proxy server on the network using Web Proxy Auto-Discovery (WPAD).
The OS components attempt to locate a proxy server by carrying out a DNS lookup for wpad.domainsuffix. If the
lookup resolves in DNS, an HTTP request is then made to the IP address for wpad.dat. This request becomes the
proxy configuration script in your environment. The connector uses this script to select an outbound proxy server.
However, connector traffic might still not go through, because of additional configuration settings needed on the
proxy.
You can configure the connector to bypass your on-premises proxy to ensure that it uses direct connectivity to the
Azure services. We recommend this approach, as long as your network policy allows for it, because it means that
you have one less configuration to maintain.
To disable outbound proxy usage for the connector, edit the C:\Program Files\Microsoft AAD App Proxy
Connector\ApplicationProxyConnectorService.exe.config file and add the system.net section shown in this code
sample:
<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<system.net>
<defaultProxy enabled="false"></defaultProxy>
</system.net>
<runtime>
<gcServer enabled="true"/>
</runtime>
<appSettings>
<add key="TraceFilename" value="AadAppProxyConnector.log" />
</appSettings>
</configuration>
To ensure that the Connector Updater service also bypasses the proxy, make a similar change to the
ApplicationProxyConnectorUpdaterService.exe.config file. This file is located at C:\Program Files\Microsoft AAD
App Proxy Connector Updater.
Be sure to make copies of the original files, in case you need to revert to the default .config files.
Use the outbound proxy server

Some environments require all outbound traffic to go through an outbound proxy, without exception. As a result,
bypassing the proxy is not an option.
You can configure the connector traffic to go through the outbound proxy, as shown in the following diagram:
As a result of having only outbound traffic, there's no need to configure inbound access through your firewalls.
NOTE
Application Proxy does not support authentication to other proxies. The connector/updater network service accounts should
be able to connect to the proxy without being challenged for authentication.
Step 1: Configure the connector and related services to go through the outbound proxy
If WPAD is enabled in the environment and configured appropriately, the connector automatically discovers the
outbound proxy server and attempt to use it. However, you can explicitly configure the connector to go through an
outbound proxy.
To do so, edit the C:\Program Files\Microsoft AAD App Proxy
Connector\ApplicationProxyConnectorService.exe.config file and add the system.net section shown in this code
sample. Change proxyserver:8080 to reflect your local proxy server name or IP address, and the port that it's
listening on.
<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<system.net>
<defaultProxy>
<proxy proxyaddress="http://proxyserver:8080" bypassonlocal="True" usesystemdefault="True"/>
</defaultProxy>
</system.net>
<runtime>
<gcServer enabled="true"/>
</runtime>
<appSettings>
<add key="TraceFilename" value="AadAppProxyConnector.log" />
</appSettings>
</configuration>
Next, configure the Connector Updater service to use the proxy by making a similar change to the C:\Program
Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config file.
Step 2: Configure the proxy to allow traffic from the connector and related services to flow through
There are four aspects to consider at the outbound proxy:
Proxy outbound rules
Proxy authentication
Proxy ports
SSL inspection
Proxy outbound rules
Allow access to the following endpoints for connector service access:
*.msappproxy.net
*.servicebus.windows.net
For initial registration, allow access to the following endpoints:
login.windows.net
login.microsoftonline.com
If you can't allow connectivity by FQDN and need to specify IP ranges instead, use these options:
Allow the connector outbound access to all destinations.
Allow the connector outbound access to all of the Azure datacenter IP ranges. The challenge with using the list
of Azure datacenter IP ranges is that it's updated weekly. You need to put a process in place to ensure that your
access rules are updated accordingly. Only using a subset of the IP addresses may cause your configuration to
break.
Proxy authentication
Proxy authentication is not currently supported. Our current recommendation is to allow the connector
anonymous access to the Internet destinations.
Proxy ports
The connector makes outbound SSL-based connections by using the CONNECT method. This method essentially
sets up a tunnel through the outbound proxy. Configure the proxy server to allow tunneling to ports 443 and 80.
NOTE
When Service Bus runs over HTTPS, it uses port 443. However, by default, Service Bus attempts direct TCP connections and
falls back to HTTPS only if direct connectivity fails.
SSL inspection
Do not use SSL inspection for the connector traffic, because it causes problems for the connector traffic. The
connector uses a certificate to authenticate to the Application Proxy service, and that certificate can be lost during
SSL inspection.
Troubleshoot connector proxy problems and service connectivity issues

Now you should see all traffic flowing through the proxy. If you have problems, the following troubleshooting
information should help.
The best way to identify and troubleshoot connector connectivity issues is to take a network capture while starting
the connector service. Here are some quick tips on capturing and filtering network traces.
You can use the monitoring tool of your choice. For the purposes of this article, we used Microsoft Message
Analyzer. You can download it from Microsoft.
The following examples are specific to Message Analyzer, but the principles can be applied to any analysis tool.
Take a capture of connector traffic
For initial troubleshooting, perform the following steps:
1. From services.msc, stop the Azure AD Application Proxy Connector service.
2. Run Message Analyzer as an administrator.

3. Select Start local trace.
4. Start the Azure AD Application Proxy Connector service.

5. Stop the network capture.
Check if the connector traffic bypasses outbound proxies

If you configured your Application Proxy connector to bypass the proxy servers and connect directly to the
Application Proxy service, you want to look in the network capture for failed TCP connection attempts.
Use the Message Analyzer filter to identify these attempts. Enter property.TCPSynRetransmit in the filter box and
select Apply.
A SYN packet is the first packet sent to establish a TCP connection. If this packet doesn’t return a response, the SYN
is reattempted. You can use the preceding filter to see any retransmitted SYNs. Then, you can check whether these
SYNs correspond to any connector-related traffic.
If you expect the connector to make direct connections to the Azure services, SynRetransmit responses on port
443 are an indication that you have a network or firewall problem.
Check if the connector traffic uses outbound proxies
If you configured your Application Proxy connector traffic to go through the proxy servers, you want to look for
failed https connections to your proxy.
To filter the network capture for these connection attempts, enter
(https.Request or https.Response) and tcp.port==8080 in the Message Analyzer filter, replacing 8080 with your
proxy service port. Select Apply to see the filter results.
The preceding filter shows just the HTTPs requests and responses to/from the proxy port. You're looking for the
CONNECT requests that show communication with the proxy server. Upon success, you get an HTTP OK (200)
response.
If you see other response codes, such as 407 or 502, that means that the proxy is requiring authentication or not
allowing the traffic for some other reason. At this point, you engage your proxy server support team.
Next steps
If you have problems with connector connectivity issues, ask your question in the Azure Active Directory
forum or create a ticket with our support team.
Working with claims-aware apps in Application Proxy
Claims-aware apps perform a redirection to the Security Token Service (STS). The STS requests credentials from the
user in exchange for a token and then redirects the user to the application. There are a few ways to enable
Application Proxy to work with these redirects. Use this article to configure your deployment for claims-aware apps.
Prerequisites
Make sure that the STS that the claims-aware app redirects to is available outside of your on-premises network.
You can make the STS available by exposing it through a proxy or by allowing outside connections.
Publish your application

1. Publish your application according to the instructions described in Publish applications with Application Proxy.
2. Navigate to the application page in the portal and select Single sign-on.
3. If you chose Azure Active Directory as your Preauthentication Method, select Azure AD single sign-on
disabled as your Internal Authentication Method. If you chose Passthrough as your Preauthentication
Method, you don't need to change anything.
Configure ADFS
You can configure ADFS for claims-aware apps in one of two ways. The first is by using custom domains. The
second is with WS-Federation.
Option 1: Custom domains
If all the internal URLs for your applications are fully qualified domain names (FQDNs), then you can configure
custom domains for your applications. Use the custom domains to create external URLs that are the same as the
internal URLs. When your external URLs match your internal URLs, then the STS redirections work whether your
users are on-premises or remote.
Option 2: WS -Federation
1. Open ADFS Management.
2. Go to Relying Party Trusts, right-click on the app you are publishing with Application Proxy, and choose
Properties.
3. On the Endpoints tab, under Endpoint type, select WS-Federation.

4. Under Trusted URL, enter the URL you entered in the Application Proxy under External URL and click OK.
Next steps
Enable single-sign on for applications that aren't claims-aware
Enable native client apps to interact with proxy applications
How to enable native client apps to interact with
proxy applications
In addition to web applications, Azure Active Directory Application Proxy can also be used to publish native client
apps that are configured with the Azure AD Authentication Library (ADAL). Native client apps differ from web apps
because they are installed on a device, while web apps are accessed through a browser.
Application Proxy supports native client apps by accepting Azure AD issued tokens sent in the header. The
Application Proxy service performs authentication on behalf of the users. This solution does not use application
tokens for authentication.
Use the Azure AD Authentication Library, which takes care of authentication and supports many client
environments, to publish native applications. Application Proxy fits into the Native Application to Web API scenario.
This article walks you through the four steps to publish a native application with Application Proxy and the Azure
AD Authentication Library.
Step 1: Publish your application

Publish your proxy application as you would any other application and assign users to access your application. For
more information, see Publish applications with Application Proxy.
Step 2: Configure your application

Configure your native application as follows:
2. Navigate to Azure Active Directory > App registrations.
3. Select New application registration.
4. Specify a name for your application, select Native as the application type, and provide the Redirect URI for
your application.
5. Select Create.
For more detailed information about creating a new app registration, see Integrating applications with Azure Active
Directory.
Step 3: Grant access to other applications

Enable the native application to be exposed to other applications in your directory:
1. Still in App registrations, select the new native application that you just created.
2. Select Required permissions.
3. Select Add.
4. Open the first step, Select an API.
5. Use the search bar to find the Application Proxy app that you published in the first section. Choose that app,
then click Select.
6. Open the second step, Select permissions.

7. Use the checkbox to grant your native application access to your proxy application, then click Select.
8. Select Done.
Step 4: Edit the Active Directory Authentication Library

Edit the native application code in the authentication context of the Active Directory Authentication Library (ADAL)
to include the following text:
// Acquire Access Token from AAD for Proxy Application
AuthenticationContext authContext = new AuthenticationContext("https://login.microsoftonline.com/<Tenant ID>");
AuthenticationResult result = authContext.AcquireToken("< External Url of Proxy App >",
"<App ID of the Native app>",
new Uri("<Redirect Uri of the Native App>"),
PromptBehavior.Never);
//Use the Access Token to access the Proxy Application

HttpClient httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
HttpResponseMessage response = await httpClient.GetAsync("< Proxy App API Url >");
The variables in the sample code should be replaced as follows:

Tenant ID can be found in the Azure portal. Navigate to Azure Active Directory > Properties and copy the
Directory ID.
External URL is the front-end URL you entered in the Proxy Application. To find this value, navigate to the
Application proxy section of the proxy app.
App ID of the native app can be found on the Properties page of the native application.
Redirect URI of the native app can be found on the Redirect URIs page of the native application.
Once the ADAL is edited with these parameters, your users should be able to authenticate to native client apps even
when they're outside of the corporate network.
Next steps
For more information about the native application flow, see Native application to web API
Learn about setting up Single sign-on for Application Proxy
Create an unattended installation script for the Azure
AD Application Proxy connector
This topic helps you create a Windows PowerShell script that enables unattended installation and registration for
your Azure AD Application Proxy connector.
This capability is useful when you want to:
Install the connector on Windows servers that don't have user interface enabled, or that you can't access with
Remote Desktop.
Install and register many connectors at once.
Integrate the connector installation and registration as part of another procedure.
Create a standard server image that contains the connector bits but is not registered.
For the Application Proxy connector to work, it has to be registered with your Azure AD directory using a global
administrator and password. Ordinarily this information is entered during Connector installation in a pop-up dialog
box, but you can use PowerShell to automate this process instead.
There are two steps for an unattended installation. First, install the connector. Second, register the connector with
Azure AD.
Install the connector

Use the following steps to install the connector without registering it:
1. Open a command prompt.
2. Run the following command, in which the /q means quiet installation. A quiet installation doesn't prompt
you to accept the End-User License Agreement.
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
Register the connector with Azure AD

There are two methods you can use to register the connector:
Register the connector using a Windows PowerShell credential object
Register the connector using a token created offline
Register the connector using a Windows PowerShell credential object
1. Create a Windows PowerShell Credentials object $cred that contains an administrative username and
password for your directory. Run the following command, replacing <username> and <password>:
$User = "<username>"
$PlainPassword = '<password>'
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User,
$SecurePassword
2. Go to C:\Program Files\Microsoft AAD App Proxy Connector and run the following script using the
$cred object that you created:
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -

moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred
Register the connector using a token created offline

1. Create an offline token using the AuthenticationContext class using the values in this code snippet:
using System;
using System.Diagnostics;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
class Program
{
#region constants
/// <summary>
/// The AAD authentication endpoint uri
/// </summary>
static readonly Uri AadAuthenticationEndpoint = new
Uri("https://login.microsoftonline.com/common/oauth2/token?api-version=1.0");
/// <summary>
/// The application ID of the connector in AAD
/// </summary>
static readonly string ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489";
/// <summary>
/// The reply address of the connector application in AAD
/// </summary>
static readonly Uri ConnectorRedirectAddress = new Uri("urn:ietf:wg:oauth:2.0:oob");
/// <summary>
/// The AppIdUri of the registration service in AAD
/// </summary>
static readonly Uri RegistrationServiceAppIdUri = new
Uri("https://proxy.cloudwebappproxy.net/registerapp");
#endregion
#region private members

private string token;
private string tenantID;
#endregion
public void GetAuthenticationToken()

{
AuthenticationContext authContext = new
AuthenticationContext(AadAuthenticationEndpoint.AbsoluteUri);
AuthenticationResult authResult = authContext.AcquireToken(RegistrationServiceAppIdUri.AbsoluteUri,

ConnectorAppId,
ConnectorRedirectAddress,
PromptBehavior.Always);
if (authResult == null || string.IsNullOrEmpty(authResult.AccessToken) ||

string.IsNullOrEmpty(authResult.TenantId))
{
Trace.TraceError("Authentication result, token or tenant id returned are null");
throw new InvalidOperationException("Authentication result, token or tenant id returned are
null");
}
token = authResult.AccessToken;
tenantID = authResult.TenantId;
}
2. Once you have the token, create a SecureString using the token:
$SecureToken = $Token | ConvertTo-SecureString -AsPlainText -Force
3. Run the following Windows PowerShell command, replacing <tenant GUID> with your directory ID:
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -
moduleName "AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId <tenant GUID>
Next steps
Publish applications using your own domain name
Set a custom home page for published apps by using
Azure AD Application Proxy
This article discusses how to configure apps to direct users to a custom home page. When you publish an
application with Application Proxy, you set an internal URL but sometimes that's not the page your users should
see first. Set a custom home page so that your users go to the right page when they access the apps. Your users
will see the custom home page that you set, whether they access the app from the Azure Active Directory Access
Panel or the Office 365 app launcher.
When users launch the app, they're directed by default to the root domain URL for the published app. The landing
page is typically set as the home page URL. Use the Azure AD PowerShell module to define custom home page
URLs when you want app users to land on a specific page within the app.
Here's one example of why a company would set a custom home page:
Inside your corporate network, users go to https://ExpenseApp/login/login.aspx to sign in and access your app.
Because you have other assets like images that Application Proxy needs to access at the top level of the folder
structure, you publish the app with https://ExpenseApp as the internal URL.
The default external URL is https://ExpenseApp-contoso.msappproxy.net, which doesn't take your users to the
sign-in page.
Set https://ExpenseApp-contoso.msappproxy.net/login/login.aspx as the home page URL.
NOTE
When you give users access to published apps, the apps are displayed in the Azure AD Access Panel and the Office 365 app
launcher.
Before you start

Before you set the home page URL, keep in mind the following requirements:
Ensure that the path you specify is a subdomain path of the root domain URL.
If the root-domain URL is, for example, https://apps.contoso.com/app1/, the home page URL that you
configure must start with https://apps.contoso.com/app1/.
If you make a change to the published app, the change might reset the value of the home page URL. When
you update the app in the future, you should recheck and, if necessary, update the home page URL.
Change the home page in the Azure portal

2. Navigate to Azure Active Directory > App registrations and choose your application from the list.
3. Select Properties from the settings.
4. Update the Home page URL field with your new path.
5. Select Save
Change the home page with PowerShell

Install the Azure AD PowerShell module
Before you define a custom home page URL by using PowerShell, install the Azure AD PowerShell module. You can
download the package from the PowerShell Gallery, which uses the Graph API endpoint.
To install the package, follow these steps:
1. Open a standard PowerShell window, and then run the following command:
Install-Module -Name AzureAD
If you're running the command as a non-admin, use the -scope currentuser option.
2. During the installation, select Y to install two packages from Nuget.org. Both packages are required.
Find the ObjectID of the app
Obtain the ObjectID of the app, and then search for the app by its home page.
1. In the same PowerShell window, import the Azure AD module.
Import-Module AzureAD
2. Sign in to the Azure AD module as the tenant administrator.
Connect-AzureAD
3. Find the app based on its home page URL. You can find the URL in the portal by going to Azure Active
Directory > Enterprise applications > All applications. This example uses sharepoint-iddemo.
Get-AzureADApplication | where { $_.Homepage -like “sharepoint-iddemo” } | fl DisplayName, Homepage,

ObjectID
4. You should get a result that's similar to the one shown here. Copy the ObjectID GUID to use in the next
section.
DisplayName : SharePoint
Homepage : https://sharepoint-iddemo.msappproxy.net/
ObjectId : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
Update the home page URL

Create the home page URL, and update your application with that value. Continue using the same PowerShell
window to run these commands. Or, if you're using a new PowerShell window, sign in to the Azure AD module
again using Connect-AzureAD .
1. Confirm that you have the correct app, and replace 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4 with the
ObjectID that you copied in the preceding section.
Get-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4.
Now that you've confirmed the app, you're ready to update the home page, as follows.
2. Create a blank application object to hold the changes that you want to make. This variable holds the values
that you want to update. Nothing is created in this step.
$appnew = New-Object “Microsoft.Open.AzureAD.Model.Application”
3. Set the home page URL to the value that you want. The value must be a subdomain path of the published
app. For example, if you change the home page URL from https://sharepoint-iddemo.msappproxy.net/ to
https://sharepoint-iddemo.msappproxy.net/hybrid/, app users go directly to the custom home page.
$homepage = “https://sharepoint-iddemo.msappproxy.net/hybrid/”
4. Make the update by using the GUID (ObjectID) that you copied in "Step 1: Find the ObjectID of the app."
Set-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4 -Homepage $homepage
5. To confirm that the change was successful, restart the app.
Get-AzureADApplication -ObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
NOTE
Any changes that you make to the app might reset the home page URL. If your home page URL resets, repeat the steps in
this section to set it back.
Next steps
Enable remote access to SharePoint with Azure AD Application Proxy
Enable Application Proxy in the Azure portal
Redirect hardcoded links for apps published with
Azure AD Application Proxy
Azure AD Application Proxy makes your on-premises apps available to users who are remote or on their own
devices. Some apps, however, were developed with local links embedded in the HTML. These links don't work
correctly when the app is used remotely. When you have several on-premises applications point to each other, your
users expect the links to keep working when they're not at the office.
The best way to make sure that links work the same both inside and outside of your corporate network is to
configure the external URLs of your apps to be the same as their internal URLs. Use custom domains to configure
your external URLs to have your corporate domain name instead of the default application proxy domain.
If you can't use custom domains in your tenant, then the link translation feature of Application Proxy keeps your
links working no matter where your users are. When you have apps that point directly to internal endpoints or
ports, you can map these internal URLs to the published external Application Proxy URLs. When link translation is
enabled, and Application Proxy searches through HTML, CSS, and select JavaScript tags for published internal links.
Then the Application Proxy service translates them so that your users get an uninterrupted experience.
NOTE
The link translation feature is for tenants that, for whatever reason, can't use custom domains to have the same internal and
external URLs for their apps. Before you enable this feature, see if custom domains in Azure AD Application Proxy can work
for you.
Or, if the application you need to configure with link translation is SharePoint, see Configure alternate access mappings for
SharePoint 2013 for another approach to mapping links.
How link translation works

After authentication, when the proxy server passes the application data to the user, Application Proxy scans the
application for hardcoded links and replaces them with their respective, published external URLs.
Application Proxy assumes that applications are encoded in UTF-8. If that's not the case, specify the encoding type
in an http response header, like Content-Type:text/html;charset=utf-8 .
Which links are affected?
The link translation feature only looks for links that are in code tags in the body of an app. Application Proxy has a
separate feature for translating cookies or URLs in headers.
There are two common types of internal links in on-premises applications:
Relative internal links that point to a shared resource in a local file structure like /claims/claims.html . These
links automatically work in apps that are published through Application Proxy, and continue to work with or
without link translation.
Hardcoded internal links to other on-premises apps like http://expenses or published files like
http://expenses/logo.jpg . The link translation feature works on hardcoded internal links, and changes them to
point to the external URLs that remote users need to go through.
How do apps link to each other?
Link translation is enabled for each application, so that you have control over the user experience at the per-app
level. Turn on link translation for an app when you want the links from that app to be translated, not links to that
app.
For example, suppose that you have three applications published through Application Proxy that all link to each
other: Benefits, Expenses, and Travel. There's a fourth app, Feedback, that isn't published through Application Proxy.
When you enable link translation for the Benefits app, the links to Expenses and Travel are redirected to the external
URLs for those apps, but the link to Feedback is not redirected because there is no external URL. Links from
Expenses and Travel back to Benefits don't work, because link translation has not been enabled for those two apps.
Which links aren't translated?

To improve performance and security, some links aren't translated:
Links not inside of code tags.
Links not in HTML, CSS, or JavaScript.
Internal links opened from other programs. Links sent through email or instant message, or included in other
documents, won't be translated. The users need to know to go to the external URL.
If you need to support one of these two scenarios, use the same internal and external URLs instead of link
translation.
Enable link translation

Getting started with link translation is as easy as clicking a button:
2. Go to Azure Active Directory > Enterprise applications > All applications > select the app you want to
manage > Application proxy.
3. Turn Translate URLs in application body to Yes.
.
4. Select Save to apply your changes.
Now, when your users access this application, the proxy will automatically scan for internal URLs that have been
published through Application Proxy on your tenant.
Send feedback
We want your help to make this feature work for all your apps. We search over 30 tags in HTML and CSS, and are
considering which JavaScript cases to support. If you have an example of generated links that aren't being
translated, send a code snippet to Application Proxy Feedback.
Next steps
Use custom domains with Azure AD Application Proxy to have the same internal and external URL
Configure alternate access mappings for SharePoint 2013
Publish Remote Desktop with Azure AD Application
Proxy
Remote Desktop Service and Azure AD Application Proxy work together to improve the productivity of workers
who are away from the corporate network.
The intended audience for this article is:
Current Application Proxy customers who want to offer more applications to their end users by publishing on-
premises applications through Remote Desktop Services.
Current Remote Desktop Services customers who want to reduce the attack surface of their deployment by
using Azure AD Application Proxy. This scenario gives a limited set of two-step verification and conditional
access controls to RDS.
How Application Proxy fits in the standard RDS deployment

A standard RDS deployment includes various Remote Desktop role services running on Windows Server. Looking
at the Remote Desktop Services architecture, there are multiple deployment options. Unlike other RDS deployment
options, the RDS deployment with Azure AD Application Proxy (shown in the following diagram) has a permanent
outbound connection from the server running the connector service. Other deployments leave open inbound
connections through a load balancer.
In an RDS deployment, the RD Web role and the RD Gateway role run on Internet-facing machines. These
endpoints are exposed for the following reasons:
RD Web provides the user a public endpoint to sign in and view the various on-premises applications and
desktops they can access. Upon selecting a resource, an RDP connection is created using the native app on the
OS.
RD Gateway comes into the picture once a user launches the RDP connection. The RD Gateway handles
encrypted RDP traffic coming over the internet and translates it to the on-premises server that the user is
connecting to. In this scenario, the traffic the RD Gateway is receiving comes from the Azure AD Application
Proxy.
TIP
If you haven't deployed RDS before, or want more information before you begin, learn how to seamlessly deploy RDS with
Azure Resource Manager and Azure Marketplace.
Requirements
Both the RD Web and RD Gateway endpoints must be located on the same machine, and with a common
root. RD Web and RD Gateway are published as a single application with Application Proxy so that you can
have a single sign-on experience between the two applications.
You should already have deployed RDS, and enabled Application Proxy.
This scenario assumes that your end users go through Internet Explorer on Windows 7 or Windows 10
desktops that connect through the RD Web page. If you need to support other operating systems, see
Support for other client configurations.
On Internet Explorer, enable the RDS ActiveX add-on.
Deploy the joint RDS and Application Proxy scenario

After setting up RDS and Azure AD Application Proxy for your environment, follow the steps to combine the two
solutions. These steps walk through publishing the two web-facing RDS endpoints (RD Web and RD Gateway) as
applications, and then directing traffic on your RDS to go through Application Proxy.
Publish the RD host endpoint
1. Publish a new Application Proxy application with the following values:
Internal URL: https://<rdhost>.com/, where <rdhost> is the common root that RD Web and RD Gateway
share.
External URL: This field is automatically populated based on the name of the application, but you can
modify it. Your users will go to this URL when they access RDS.
Preauthentication method: Azure Active Directory
Translate URL headers: No
2. Assign users to the published RD application. Make sure they all have access to RDS, too.
3. Leave the single sign-on method for the application as Azure AD single sign-on disabled. Your users are
asked to authenticate once to Azure AD and once to RD Web, but have single sign-on to RD Gateway.
4. Go to Azure Active Directory > App Registrations > Your application > Settings.
5. Select Properties and update the Home-page URL field to point to your RD Web endpoint (like
https://<rdhost>.com/RDWeb).
Direct RDS traffic to Application Proxy
Connect to the RDS deployment as an administrator and change the RD Gateway server name for the deployment.
This configuration ensures that connections go through the Azure AD Application Proxy service.
1. Connect to the RDS server running the RD Connection Broker role.
2. Launch Server Manager.
3. Select Remote Desktop Services from the pane on the left.
4. Select Overview.
5. In the Deployment Overview section, select the drop-down menu and choose Edit deployment properties.
6. In the RD Gateway tab, change the Server name field to the External URL that you set for the RD host endpoint
in Application Proxy.
7. Change the Logon method field to Password Authentication.
8. Run this command for each collection. Replace <yourcollectionname> and <proxyfrontendurl> with your
own information. This command enables single sign-on between RD Web and RD Gateway, and optimizes
performance:
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-

authentication server address:s:<proxyfrontendurl>`nrequire pre-authentication:i:1"
For example:
Set-RDSessionCollectionConfiguration -CollectionName "QuickSessionCollection" -CustomRdpProperty "pre-

authentication server address:s:https://remotedesktoptest-aadapdemo.msappproxy.net/`nrequire pre-
authentication:i:1"
9. To verify the modification of the custom RDP properties as well as view the RDP file contents that will be
downloaded from RDWeb for this collection, run the following command:
(get-wmiobject -Namespace root\cimv2\terminalservices -Class
Win32_RDCentralPublishedRemoteDesktop).RDPFileContents
Now that you've configured Remote Desktop, Azure AD Application Proxy has taken over as the internet-facing
component of RDS. You can remove the other public internet-facing endpoints on your RD Web and RD Gateway
machines.
Test the scenario

Test the scenario with Internet Explorer on a Windows 7 or 10 computer.
1. Go to the external URL you set up, or find your application in the MyApps panel.
2. You are asked to authenticate to Azure Active Directory. Use an account that you assigned to the application.
3. You are asked to authenticate to RD Web.
4. Once your RDS authentication succeeds, you can select the desktop or application you want, and start working.
Support for other client configurations

The configuration outlined in this article is for users on Windows 7 or 10, with Internet Explorer plus the RDS
ActiveX add-on. If you need to, however, you can support other operating systems or browsers. The difference is in
the authentication method that you use.
AUTHENTICATION METHOD SUPPORTED CLIENT CONFIGURATION
Pre-authentication Windows 7/10 using Internet Explorer + RDS ActiveX add-on
Passthrough Any other operating system that supports the Microsoft

Remote Desktop application
The pre-authentication flow offers more security benefits than the passthrough flow. With pre-authentication you
can use Azure AD authentication features like single sign-on, conditional access, and two-step verification for your
on-premises resources. You also ensure that only authenticated traffic reaches your network.
To use passthrough authentication, there are just two modifications to the steps listed in this article:
1. In Publish the RD host endpoint step 1, set the Preauthentication method to Passthrough.
2. In Direct RDS traffic to Application Proxy, skip step 8 entirely.
Next steps
Enable remote access to SharePoint with Azure AD Application Proxy
Security considerations for accessing apps remotely by using Azure AD Application Proxy
Enable remote access to SharePoint with Azure AD
Application Proxy
This article discusses how to integrate an on-premises SharePoint server with Azure Active Directory (Azure AD)
Application Proxy.
To enable remote access to SharePoint with Azure AD Application Proxy, follow the sections in this article step by
step.
Prerequisites
This article assumes that you already have SharePoint 2013 or newer in your environment. In addition, consider
the following prerequisites:
SharePoint includes native Kerberos support. Therefore, users who are accessing internal sites remotely
through Azure AD Application Proxy can assume to have a single sign-on (SSO) experience.
This scenario includes configuration changes to your SharePoint server. We recommend using a staging
environment. This way, you can make updates to your staging server first, and then facilitate a testing cycle
before going into production.
We require SSL on the published URL. You need to have SSL enabled on your internal site to ensure that
links are sent/mapped correctly. If you haven't configured SSL, see Configure SSL for SharePoint 2013 for
instructions. Also, make sure that the connector machine trusts the certificate that you issue. (The certificate
does not need to be publicly issued.)
Step 1: Set up single sign-on to SharePoint

For on-premises applications that use Windows authentication, you can achieve single sign-on (SSO) with the
Kerberos authentication protocol and a feature called Kerberos constrained delegation (KCD). KCD, when
configured, allows the Application Proxy connector to obtain a Windows token for a user, even if the user hasn’t
signed in to Windows directly. To learn more about KCD, see Kerberos Constrained Delegation Overview.
To set up KCD for a SharePoint server, use the procedures in the following sequential sections:
Ensure that SharePoint is running under a service account
First, make sure that SharePoint is running under a defined service account--not local system, local service, or
network service. Do this so that you can attach service principal names (SPNs) to a valid account. SPNs are how
the Kerberos protocol identifies different services. And you will need the account later to configure the KCD.
NOTE
You need to have a previously created Azure AD account for the service. We suggest that you allow for an automatic
password change. For more information about the full set of steps and troubleshooting issues, see Configure automatic
password change in SharePoint 2013.
To ensure that your sites are running under a defined service account, perform the following steps:
1. Open the SharePoint 2013 Central Administration site.
2. Go to Security and select Configure service accounts.
3. Select Web Application Pool - SharePoint - 80. The options may be slightly different based on the name
of your web pool, or if the web pool uses SSL by default.
4. If Select an account for this component field is set to Local Service or Network Service, you need to
create an account. If not, you're finished and can move to the next section.
5. Select Register new managed account. After your account is created, you must set Web Application Pool
before you can use the account.
Configure SharePoint for Kerberos
You use KCD to perform single sign-on to the SharePoint server.
To configure your SharePoint site for Kerberos authentication:
2. Go to Application Management, select Manage web applications, and select your SharePoint site. In
this example, it is SharePoint - 80.
3. Click Authentication Providers on the toolbar.

4. In the Authentication Providers box, click Default Zone to view the settings.
5. In the Edit Authentication dialog box, scroll down until you see Claims Authentication Types. Ensure that
both Enable Windows Authentication and Integrated Windows Authentication are selected.
6. In the drop-down box for the Integrated Windows Authentication field, make sure that Negotiate
(Kerberos) is selected.
7. At the bottom of the Edit Authentication dialog box, click Save.
Set a service principal name for the SharePoint service account
Before you configure KCD, you need to identify the SharePoint service running as the service account that you've
configured. Identify the service by setting an SPN. For more information, see Service Principal Names.
The SPN format is:
<service class>/<host>:<port>
In the SPN format:

service class is a unique name for the service. For SharePoint, you use HTTP.
host is the fully qualified domain or NetBIOS name of the host that the service is running on. For a
SharePoint site, this text might need to be the URL of the site, depending on the version of IIS that you're
using.
port is optional.
If the FQDN of the SharePoint server is:
sharepoint.demo.o365identity.us
Then the SPN is:
HTTP/sharepoint.demo.o365identity.us demo
You might also need to set SPNs for specific sites on your server. For more information, see Configure Kerberos
authentication. Pay close attention to the "Create Service Principal Names for your Web applications using
Kerberos authentication" section.
The easiest way for you to set SPNs is to follow the SPN formats that may already be present for your sites. Copy
those SPNs to register against the service account. To do this:
1. Browse to the site with the SPN from another machine. When you do, the relevant set of Kerberos tickets is
cached on the machine. These tickets contain the SPN of the target site that you browsed to.
2. You can pull the SPN for that site by using a tool called Klist. In a command window that's running in the
same context as the user who accessed the site in the browser, run the following command:
Klist
Klist then returns the set of target SPNs. In this example, the highlighted value is the SPN that's needed:
3. Now that you have the SPN, make sure that it's configured correctly on the service account that you set up
for the web application earlier. Run the following command from the command prompt as an
administrator of the domain:
setspn -S http/sharepoint.demo.o365identity.us demo\sp_svc
This command sets the SPN for the SharePoint service account running as demo\sp_svc.
Replace http/sharepoint.demo.o365identity.us with the SPN for your server and demo\sp_svc with the
service account in your environment. The Setspn command searches for the SPN before it adds it. In this
case, you might see a Duplicate SPN Value error. If you see this error, make sure that the value is
associated with the service account.
You can verify that the SPN was added by running the Setspn command with the -l option. To learn more about
this command, see Setspn.
Ensure that the connector is set as a trusted delegate to SharePoint
Configure the KCD so that the Azure AD Application Proxy service can delegate user identities to the SharePoint
service. Configure KCD by enabling the Application Proxy connector to retrieve Kerberos tickets for your users
who have been authenticated in Azure AD. Then that server passes the context to the target application, or
SharePoint in this case.
To configure the KCD, repeat the following steps for each connector machine:
1. Log in as a domain administrator to a DC, and then open Active Directory Users and Computers.
2. Find the computer that the connector is running on. In this example, it's the same SharePoint server.
3. Double-click the computer, and then click the Delegation tab.
4. Ensure that the delegation settings are set to Trust this computer for delegation to the specified
services only. Then, select Use any authentication protocol.
5. Click the Add button, click Users or Computers, and locate the service account.
6. In the list of SPNs, select the one that you created earlier for the service account.
7. Click OK. Click OK again to save the changes.
Step 2: Enable remote access to SharePoint

Now that you’ve enabled SharePoint for Kerberos and configured KCD, you're ready to publish the SharePoint
farm for remote access through Azure AD Application Proxy.
1. Publish your SharePoint site with the following settings. For step-by-step instructions, see Publishing
applications using Azure AD Application Proxy.
Internal URL: the URL of the SharePoint site internally, such as https://SharePoint/. In this example,
make sure to use https
Preauthentication Method: Azure Active Directory
Translate URL in Headers: NO
TIP
SharePoint uses the Host Header value to look up the site. It also generates links based on this value. The net effect
is that any link that SharePoint generates is a published URL that is correctly set to use the external URL. Setting the
value to YES also enables the connector to forward the request to the back-end application. However, setting the
value to NO means that the connector will not send the internal host name. Instead, the connector sends the host
header as the published URL to the back-end application.
2. Once your app is published, configure the single sign-on settings with the following steps:
a. On the application page in the portal, select Single sign-on.
b. For Single Sign-on Mode, select Integrated Windows Authentication.
c. Set Internal Application SPN to the value that you set earlier. For this example, that would be
http/sharepoint.demo.o365identity.us.
3. To finish setting up your application, go to the Users and groups section and assign users to access this
application.
Step 3: Ensure that SharePoint knows about the external URL
Your last step is to ensure that SharePoint can find the site based on the external URL, so that it renders links
based on that external URL. You do this by configuring alternate access mappings for the SharePoint site.
2. Under System Settings, select Configure Alternate Access Mappings. The Alternate Access Mappings
box opens.
3. In the drop-down list beside Alternate Access Mapping Collection, select Change Alternate Access
Mapping Collection.
4. Select your site--for example, SharePoint - 80.
5. You can choose to add the published URL as either an internal URL or a public URL. This example uses a public
URL as the extranet.
6. Click Edit Public URLs in the Extranet path, and then enter the External URL that was created when you
published the application. For example, enter https://sharepoint-iddemo.msappproxy.net.
7. Click Save.
You can now access the SharePoint site externally via Azure AD Application Proxy.
Next steps
Working with custom domains in Azure AD Application Proxy
Access your on-premises applications through
Microsoft Teams
Azure Active Directory Application Proxy gives you single sign-on to on-premises applications no matter where you
are. Microsoft Teams streamlines your collaborative efforts in one place. Integrating the two together means that
your users can be productive with their teammates in any situation.
Your users can add cloud apps to their Teams channels using tabs, but what about the SharePoint sites or planning
tool that are hosted on-premises? Application Proxy is the solution. They can add apps published through
Application Proxy to their channels using the same external URLs they always use to access their apps remotely.
And because Application Proxy authenticates through Azure Active Directory, your users get a single sign-on
experience.
Install the Application Proxy connector and publish your app

If you haven't already, configure Application Proxy for your tenant and install the connector. Then, publish your on-
premises application for remote access. When you're publishing the app, make note of the external URL because it's
used to add the app to Teams.
If you already have your apps published but don't remember their external URLs, look them up in the Azure portal.
Sign in, then navigate to Azure Active Directory > Enterprise applications > All applications > select your app
> Application proxy.
Add your app to Teams

Once you publish the app through Application Proxy, let your users know that they can add it as a tab directly in
their Teams channels, and then the app is available for everyone in the team to use. Have them follow these three
steps:
1. Navigate to the Teams channel where you want to add this app and select + to add a tab.
2. Select Website from the tab options.

3. Give the tab a name and set the URL to the Application Proxy external URL.
Once one member of a team adds the tab, it shows up for everyone in the channel. Any users who have access to
the app get single sign-on access with the credentials they use for Microsoft Teams. Any users who don't have
access to the app can see the tab in Teams, but are blocked until you give them permissions to the on-premises app
and the Azure portal published version of the app.
Next steps
Learn how to publish on-premises SharePoint sites with Application Proxy.
Configure your apps to use custom domains for their external URL.
Troubleshoot Application Proxy problems and error
messages
If errors occur in accessing a published application or in publishing applications, check the following options to
see if Microsoft Azure AD Application Proxy is working correctly:
Open the Windows Services console and verify that the Microsoft AAD Application Proxy Connector
service is enabled and running. You may also want to look at the Application Proxy service properties page, as
shown in the following image:
Open Event Viewer and look for Application Proxy connector events in Applications and Services Logs >
Microsoft > AadApplicationProxy > Connector > Admin.
If needed, more detailed logs are available by turning on the Application Proxy connector session logs.
For more information about the Azure AD Troubleshooting tool, see Troubleshooting tool to validate connector
networking prerequisites.
The page is not rendered correctly

You may have problems with your application rendering or functioning incorrectly without receiving specific error
messages. This can occur if you published the article path, but the application requires content that exists outside
that path.
For example, if you publish the path https://yourapp/app but the application calls images in
https://yourapp/media, they won't be rendered. Make sure that you publish the application using the highest level
path you need to include all relevant content. In this example, it would be http://yourapp/.
If you change your path to include referenced content, but still need users to land on a deeper link in the path, see
the blog post Setting the right link for Application Proxy applications in the Azure AD access panel and Office 365
app launcher.
Connector errors
Use the Azure AD Application Proxy Connector Ports Test Tool to verify that your connector can reach the
Application Proxy service. At a minimum, make sure that the Central US region and the region closest to you have
all green checkmarks. Beyond that, more green checkmarks means greater resiliency.
If registration fails during the Connector wizard installation, there are two ways to view the reason for the failure.
Either look in the event log under Applications and Services
Logs\Microsoft\AadApplicationProxy\Connector\Admin, or run the following Windows PowerShell
command:
Get-EventLog application –source “Microsoft AAD Application Proxy Connector” –EntryType “Error” –Newest 1
Once you find the Connector error from the event log, use this table of common errors to resolve the problem:
ERROR RECOMMENDED STEPS
Connector registration failed: Make sure you enabled If you closed the registration window without signing in to
Application Proxy in the Azure Management Portal and that Azure AD, run the Connector wizard again and register the
you entered your Active Directory user name and password Connector.
correctly. Error: 'One or more errors occurred.'
If the registration window opens and then immediately closes
without allowing you to log in, you will probably get this
error. This error occurs when there is a networking error on
your system. Make sure that it is possible to connect from a
browser to a public website and that the ports are open as
specified in Application Proxy prerequisites.
Clear error is presented in the registration window. Cannot If you see this error and then the window closes, you entered
proceed the wrong username or password. Try again.
Connector registration failed: Make sure you enabled You are trying to sign in using a Microsoft Account and not a
Application Proxy in the Azure Management Portal and that domain that is part of the organization ID of the directory
you entered your Active Directory user name and password you are trying to access. Make sure that the admin is part of
correctly. Error: 'AADSTS50059: No tenant-identifying the same domain name as the tenant domain, for example, if
information found in either the request or implied by any the Azure AD domain is contoso.com, the admin should be
provided credentials and search by service principal URI has admin@contoso.com.
failed.
Failed to retrieve the current execution policy for running If the Connector installation fails, check to make sure that
PowerShell scripts. PowerShell execution policy is not disabled.
1. Open the Group Policy Editor.

2. Go to Computer Configuration > Administrative
Templates > Windows Components > Windows
PowerShell and double-click Turn on Script Execution.
3. The execution policy can be set to either Not Configured
or Enabled. If set to Enabled, make sure that under Options,
the Execution Policy is set to either Allow local scripts and
remote signed scripts or to Allow all scripts.
Connector failed to download the configuration. The Connector’s client certificate, which is used for
authentication, expired. This may also occur if you have the
Connector installed behind a proxy. In this case, the
Connector cannot access the Internet and will not be able to
provide applications to remote users. Renew trust manually
using the Register-AppProxyConnector cmdlet in Windows
PowerShell. If your Connector is behind a proxy, it is
necessary to grant Internet access to the Connector accounts
“network services” and “local system.” This can be
accomplished either by granting them access to the Proxy or
by setting them to bypass the proxy.
Connector registration failed: Make sure you are a Global The alias you're trying to log in with isn't an admin on this
Administrator of your Active Directory to register the domain. Your Connector is always installed for the directory
Connector. Error: 'The registration request was denied.' that owns the user’s domain. Make sure that the admin
account you are trying to sign in with has global permissions
to the Azure AD tenant.
Kerberos errors
This table covers the more common errors that come from Kerberos setup and configuration, and includes
suggestions for resolution.
Failed to retrieve the current execution policy for running If the Connector installation fails, check to make sure that
PowerShell scripts. PowerShell execution policy is not disabled.
1. Open the Group Policy Editor.

2. Go to Computer Configuration > Administrative
Templates > Windows Components > Windows
PowerShell and double-click Turn on Script Execution.
3. The execution policy can be set to either Not Configured
or Enabled. If set to Enabled, make sure that under Options,
the Execution Policy is set to either Allow local scripts and
remote signed scripts or to Allow all scripts.
12008 - Azure AD exceeded the maximum number of This error may indicate incorrect configuration between Azure
permitted Kerberos authentication attempts to the backend AD and the backend application server, or a problem in time
server. and date configuration on both machines. The backend server
declined the Kerberos ticket created by Azure AD. Verify that
Azure AD and the backend application server are configured
correctly. Make sure that the time and date configuration on
the Azure AD and the backend application server are
synchronized.
13016 - Azure AD cannot retrieve a Kerberos ticket on behalf There is a problem with the STS configuration. Fix the UPN
of the user because there is no UPN in the edge token or in claim configuration in the STS.
the access cookie.
13019 - Azure AD cannot retrieve a Kerberos ticket on behalf This event may indicate incorrect configuration between
of the user because of the following general API error. Azure AD and the domain controller server, or a problem in
time and date configuration on both machines. The domain
controller declined the Kerberos ticket created by Azure AD.
Verify that Azure AD and the backend application server are
configured correctly, especially the SPN configuration. Make
sure the Azure AD is domain joined to the same domain as
the domain controller to ensure that the domain controller
establishes trust with Azure AD. Make sure that the time and
date configuration on the Azure AD and the domain
controller are synchronized.
13020 - Azure AD cannot retrieve a Kerberos ticket on behalf This event may indicate incorrect configuration between
of the user because the backend server SPN is not defined. Azure AD and the domain controller server, or a problem in
time and date configuration on both machines. The domain
controller declined the Kerberos ticket created by Azure AD.
configured correctly, especially the SPN configuration. Make
sure the Azure AD is domain joined to the same domain as
the domain controller to ensure that the domain controller
establishes trust with Azure AD. Make sure that the time and
date configuration on the Azure AD and the domain
controller are synchronized.
13022 - Azure AD cannot authenticate the user because the This event may indicate incorrect configuration between
backend server responds to Kerberos authentication attempts Azure AD and the backend application server, or a problem in
with an HTTP 401 error. time and date configuration on both machines. The backend
server declined the Kerberos ticket created by Azure AD.
configured correctly. Make sure that the time and date
configuration on the Azure AD and the backend application
server are synchronized.
End-user errors
This list covers errors that your end users might encounter when they try to access the app and fail.
The website cannot display the page. Your user may get this error when trying to access the app
you published if the application is an IWA application. The
defined SPN for this application may be incorrect. For IWA
apps, make sure that the SPN configured for this application
is correct.
The website cannot display the page. Your user may get this error when trying to access the app
you published if the application is an OWA application. This
could be caused by one of the following:
The defined SPN for this application is incorrect. Make sure
that the SPN configured for this application is correct.
The user who tried to access the application is using a
Microsoft account rather than the proper corporate account
to sign in, or the user is a guest user. Make sure the user
signs in using their corporate account that matches the
domain of the published application. Microsoft Account users
and guest cannot access IWA applications.
The user who tried to access the application is not properly
defined for this application on the on-prem side. Make sure
that this user has the proper permissions as defined for this
backend application on the on-prem machine.
This corporate app can’t be accessed. You are not authorized Your users may get this error when trying to access the app
to access this application. Authorization failed. Make sure to you published if they use Microsoft accounts instead of their
assign the user with access to this application. corporate account to sign in. Guest users may also get this
error. Microsoft Account users and guests cannot access IWA
applications. Make sure the user signs in using their corporate
account that matches the domain of the published
application.
You may not have assigned the user for this application. Go
to the Application tab, and under Users and Groups, assign
this user or user group to this application.
This corporate app can’t be accessed right now. Please try Your users may get this error when trying to access the app
again later…The connector timed out. you published if they are not properly defined for this
application on the on-prem side. Make sure that your users
have the proper permissions as defined for this backend
application on the on-prem machine.
This corporate app can’t be accessed. You are not authorized Your users may get this error when trying to access the app
to access this application. Authorization failed. Make sure that you published if they weren't explicitly assigned with a
the user has a license for Azure Active Directory Premium or Premium/Basic license by the subscriber’s administrator. Go
Basic. to the subscriber’s Active Directory Licenses tab and make
sure that this user or user group is assigned a Premium or
Basic license.
My error wasn't listed here

If you encounter an error or problem with Azure AD Application Proxy that isn't listed in this troubleshooting
guide, we'd like to hear about it. Send an email to our feedback team with the details of the error you
encountered.
See also
Enable Application Proxy for Azure Active Directory
Publish applications with Application Proxy
Enable single sign-on
Enable conditional access
Assign a user or group to an enterprise app in Azure
Active Directory
To assign a user or group to an enterprise app, you must have the appropriate permissions to manage the
enterprise app, and you must be global admin for the directory.
NOTE
For Microsoft Applications (such as Office 365 apps), use PowerShell to assign users to an enterprise app.
How do I assign user access to an enterprise app in the Azure portal?

2. Select More services, enter Azure Active Directory in the text box, and then select Enter.
3. On the Azure Active Directory - *directoryname* blade (that is, the Azure AD blade for the directory you
are managing), select Enterprise applications.
4. On the Enterprise applications blade, select All applications. This lists the apps you can manage.
5. On the Enterprise applications - All applications blade, select an app.
6. On the appname blade (that is, the blade with the name of the selected app in the title), select Users &
Groups.
7. On the appname - User & Group Assignment blade, select the Add command.
8. On the Add Assignment blade, select Users and groups.
9. On the Users and groups blade, select one or more users or groups from the list and then select the Select
button at the bottom of the blade.
10. On the Add Assignment blade, select Role. Then, on the Select Role blade, select a role to apply to the
selected users or groups, and then select the OK button at the bottom of the blade.
11. On the Add Assignment blade, select the Assign button at the bottom of the blade. The assigned users or
groups have the permissions defined by the selected role for this enterprise app.
How do I assign a user to an enterprise app using PowerShell?
1. Open an elevated Windows PowerShell command prompt.
NOTE
You need to install the AzureAD module (use the command Install-Module -Name AzureAD ). If prompted to
install a NuGet module or the new Azure Active Directory V2 PowerShell module, type Y and press ENTER.
2. Run Connect-AzureAD and sign in with a Global Admin user account.

3. Use the following script to assign a user and role to an application:
# Assign the values to the variables

$username = "<You user's UPN>"
$app_name = "<Your App's display name>"
$app_role_name = "<App role display name>"
# Get the user to assign, and the service principal for the app to assign to
$user = Get-AzureADUser -ObjectId "$username"
$sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
$appRole = $sp.AppRoles | Where-Object { $_.DisplayName -eq $app_role_name }
# Assign the user to the app role

New-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId
$sp.ObjectId -Id $appRole.Id
For more information about how to assign a user to an application role visit the documentation for New-
AzureADUserAppRoleAssignment
Example
This example assigns the user Britta Simon to the Microsoft Workplace Analytics application using PowerShell.
1. In PowerShell, assign the corresponding values to the variables $username, $app_name and
$app_role_name.

$username = "britta.simon@contoso.com"
$app_name = "Workplace Analytics"
2. In this example, we don't know what is the exact name of the application role we want to assign to Britta
Simon. Run the following commands to get the user ($user) and the service principal ($sp) using the user
UPN and the service principal display names.
# Get the user to assign, and the service principal for the app to assign to
$user = Get-AzureADUser -ObjectId "$username"
$sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
3. Run the command $sp.AppRoles to display the roles available for the Workplace Analytics application. In
this example, we want to assign Britta Simon the Analyst (Limited access) Role.
4. Assign the role name to the $app_role_name variable.

$app_role_name = "Analyst (Limited access)"
5. Run the following command to assign the user to the app role:
# Assign the user to the app role

New-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId
$sp.ObjectId -Id $appRole.Id
Next steps
See all of my groups
Remove a user or group assignment from an enterprise app
Disable user sign-ins for an enterprise app
Change the name or logo of an enterprise app
Change the name or logo of an enterprise app in
It's easy to change the name or logo for a custom enterprise application in Azure Active Directory (Azure AD). You
must have the appropriate permissions to make these changes, and you must be the creator of the custom app.
How do I change an enterprise app's name or logo?

4. On the Enterprise applications blade, select All applications. You'll see a list of the apps you can manage.
6. On the appname blade (that is, the blade with the name of the selected app in the title), select Properties.
7. On the appname - Properties blade, browse for a file to use as a new logo, or edit the app name, or both.
8. Select the Save command.
Next steps
Assign a user or group to an enterprise app
Disable user sign-ins for an enterprise app in Azure
Active Directory
It's easy to disable an enterprise application so that no users may sign in to it in Azure Active Directory (Azure AD).
You must have the appropriate permissions to manage the enterprise app, and you must be global admin for the
directory.
How do I disable user sign-ins?

3. On the Azure Active Directory - directoryname blade (that is, the Azure AD blade for the directory you
4. On the Enterprise applications blade, select All applications. You see a list of the apps you can manage.
6. On the appname blade (that is, the blade with the name of the selected app in the title), select Properties.
7. On the appname - Properties blade, select No for Enabled for users to sign-in?.
Next steps
See all my groups
Remove a user or group assignment from an
enterprise app in Azure Active Directory
It's easy to remove a user or a group from being assigned access to one of your enterprise applications in Azure
Active Directory (Azure AD). You must have the appropriate permissions to manage the enterprise app, and you
must be global admin for the directory.
How do I remove a user or group assignment?

4. On the Enterprise applications blade, select All applications. You'll see a list of the apps you can manage.
6. On the appname blade (that is, the blade with the name of the selected app in the title), select Users &
Groups.
7. On the appname - User & Group Assignment blade, select one of more users or groups and then select
the Remove command. Confirm your decision at the prompt.
Next steps
View all the enterprise apps that I can manage in
You can manage your enterprise applications in the Azure Active Directory (Azure AD). This includes viewing the
apps you can manage, assigning users or groups to an app, maintaining properties for the app such as the
application name/logo, and even disabling an application so that no users can sign in to it.
How do I view all my apps?

3. On the Azure Active Directory - directoryname blade (that is, the Azure AD blade for the directory you are
managing), select Enterprise applications.
4. On the Enterprise applications blade, select All applications. From this blade you can select apps to manage,
change the displayed columns, or filter the list to find that app you want (for example, to view only disabled
apps).
Next steps
Managing user account provisioning for enterprise
apps in the Azure portal
This article describes how to use the Azure portal to manage automatic user account provisioning and de-
provisioning for applications that support it, particularly ones that have been added from the "featured" category of
the Azure Active Directory application gallery. To learn more about automatic user account provisioning and how it
works, see Automate User Provisioning and Deprovisioning to SaaS Applications with Azure Active Directory.
Finding your apps in the portal

All applications that are configured for single sign-on in a directory, by a directory administrator using the Azure
Active Directory application gallery, can be viewed and managed in the Azure portal. The applications can be found
in the More Services > Enterprise Applications section of the portal. Enterprise apps are apps that are deployed
and used within your organization.
Selecting the All applications link on the left shows a list of all apps that have been configured, including apps that
had been added from the gallery. Selecting an app loads the resource blade for that app, where reports can be
viewed for that app and a variety of settings can be managed.
User account provisioning settings can be managed by selecting Provisioning on the left.
Provisioning modes
The Provisioning blade begins with a Mode menu, which shows what provisioning modes are supported for an
enterprise application, and allows them to be configured. The available options include:
Automatic - This option appears if Azure AD supports automatic API-based provisioning and/or de-
provisioning of user accounts to this application. Selecting this mode displays an interface that guides
administrators through configuring Azure AD to connect to the application's user management API, creating
account mappings and workflows that define how user account data should flow between Azure AD and the
app, and managing the Azure AD provisioning service.
Manual - This option is shown if Azure AD does not support automatic provisioning of user accounts to this
application. This option means that user account records stored in the application must be managed using an
external process, based on the user management and provisioning capabilities provided by that application
(which can include SAML Just-In-Time provisioning).
Configuring automatic user account provisioning

Selecting the Automatic option displays a screen that is divided in four sections:
Admin Credentials
This is where the credentials required for Azure AD to connect to the application's user management API are
entered. The input required varies depending on the application. To learn about the credential types and
requirements for specific applications, see the configuration tutorial for that specific application.
Selecting the Test Connection button allows you to test the credentials by having Azure AD attempt to connect to
the app's provisioning app using the supplied credentials.
Mappings
This is where admins can view and edit what user attributes flow between Azure AD and the target application,
when user accounts are provisioned or updated.
There is a preconfigured set of mappings between Azure AD user objects and each SaaS app’s user objects. Some
apps manage other types of objects, such as Groups or Contacts. Selecting one of these mappings in the table
shows the mapping editor to the right, where they can be viewed and customized.
Supported customizations include:
Enabling and disabling mappings for specific objects, such as the Azure AD user object to the SaaS app's user
object.
Editing which attributes flow from the Azure AD user object to the app's user object. For more information on
attribute mapping, see Understanding attribute mapping types.
Filter the provisioning actions that Azure AD performs on the targeted application. Instead of having Azure AD
fully-synchronize objects, you can limit the actions performed. For example, by only selecting Update, Azure AD
only updates existing user accounts in an application and does not create new ones. By only selecting Create,
Azure only creates new user accounts but does not update existing ones. This feature allows admins to create
different mappings for account creation and update workflows.
Settings
This section allows admins to start and stop the Azure AD provisioning service for the selected application, as well
as optionally clear the provisioning cache and restart the service.
If provisioning is being enabled for the first time for an application, turn on the service by changing the
Provisioning Status to On. This causes the Azure AD provisioning service to perform an initial sync, where it reads
the users assigned in the Users and groups section, queries the target application for them, and then performs the
provisioning actions defined in the Azure AD Mappings section. During this process, the provisioning service
stores cached data about what user accounts it is managing, so non-managed accounts inside the target
applications that were never in scope for assignment aren't affected by de-provisioning operations. After the initial
sync, the provisioning service automatically synchronizes user and group objects on a ten minute interval.
Changing the Provisioning Status to Off simply pauses the provisioning service. In this state, Azure does not
create, update, or remove any user or group objects in the app. Changing the state back to on causes the service to
pick up where it left off.
Selecting the Clear current state and restart synchronization checkbox and saving stops the provisioning
service, dumps the cached data about what accounts Azure AD is managing, restarts the services and performs the
initial synchronization again. This option allows admins to start the provisioning deployment process over again.
Synchronization Details
This section provides addition details about the operation of the provisioning service, including the first and last
times the provisioning service ran against the application, and how many user and group objects are being
managed.
Links are provided to the Provisioning activity report, which provides a log of all users and groups created,
updated, and removed between Azure AD and the target application, and to the Provisioning error report which
provides more detailed error messages for user and group objects that failed to be read, created, updated, or
removed.
Feedback
We hope you like your Azure AD experience. Please keep the feedback coming! Post your feedback and ideas for
improvement in the Admin Portal section of our feedback forum. We’re excited about building cool new stuff
every day, and do use your guidance to shape and define what we build next.
Managing single sign-on for enterprise apps
This article describes how to use the Azure portal to manage single sign-on settings for enterprise applications.
Enterprise apps are apps that are deployed and used within your organization. This article applies particularly to
apps that were added from the Azure Active Directory application gallery.
Finding your apps in the portal

All enterprise apps that are set up for single sign-on can be viewed and managed in the Azure portal. The
applications can be found in the More Services > Enterprise Applications section of the portal.
Select All applications to view a list of all apps that have been configured. Selecting an app displays the resources
for that app, where reports can be viewed for that app and a variety of settings can be managed.
To manage single sign-on settings, select Single sign-on.
Single sign-on modes
Single sign-on begins with a Mode menu, which allows the single sign-on mode to be configured. The available
options include:
SAML-based sign-on - This option is available if the application supports full federated single sign-on with
Azure Active Directory using the SAML 2.0 protocol, WS-Federation, or OpenID connect protocols.
Password-based sign-on - This option is available if Azure AD supports password form filling for this
application.
Linked sign-on - Formerly known as "Existing single sign-on", this option allows administrators to place a link
to this application in their user's Azure AD Access Panel or Office 365 application launcher.
For more information about these modes, see How does single sign-on with Azure Active Directory work.
SAML-based sign-on
The SAML-based sign-on option is divided in four sections:
Domains and URLs
This is where all details about the application's domain and URLs are added to your Azure AD directory. All inputs
required to make single sign-on work app are displayed directly on the screen, whereas all optional inputs can be
viewed by selecting the Show advanced URL settings checkbox. The full list of supported inputs includes:
sign-on URL – Where the user goes to sign in to the application. If the application is configured to perform
service-provider-initiated single sign-on, when a user opens this URL, the service provider redirects to Azure AD
to authenticate and sign the user in.
If this field is populated, then Azure AD uses the URL to start the application from Office 365 and the
Azure AD Access Panel.
If this field is omitted, then Azure AD instead performs identity-provider-initiated sign-on when the app
is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL.
Identifier - This URI should uniquely identify the application for which single sign-on is being configured. This
is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the
application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by
the application.
Reply URL - The reply URL is where the application expects to receive the SAML token. This is also referred to
as the Assertion Consumer Service (ACS) URL. After these have been entered, click Next to proceed to the next
screen. This screen provides information about what needs to be configured on the application side to enable it
to accept a SAML token from Azure AD.
Relay State - The relay state is an optional parameter that can help tell the application where to redirect the
user after authentication is completed. Typically the value is a valid URL at the application, however some
applications use this field differently (see the app's single sign-on documentation for details). The ability to set
the relay state is a new feature that is unique to the new Azure portal.
User Attributes
This is where admins can view and edit the attributes that are sent in the SAML token that Azure AD issues to the
application each time users sign in.
The only editable attribute supported is the User Identifier attribute. The value of this attribute is the field in Azure
AD that uniquely identifies each user within the application. For example, if the app was deployed using the "Email
address" as the username and unique identifier, then the value would be set to the "user.mail" field in Azure AD.
SAML Signing Certificate
This section shows the details of the certificate that Azure AD uses to sign the SAML tokens that are issued to the
application each time the user authenticates. It allows the properties of the current certificate to be inspected,
including the expiration date.
Application Configuration
The final section provides the documentation and/or controls required to configure the application itself to use
Azure Active Directory as an identity provider.
The Configure Application fly-out menu provides new concise, embedded instructions for configuring the
application. This is another new feature unique to the new Azure portal.
NOTE
For a complete example of embedded documentation, see the Salesforce.com application. Documentation for additional apps
is being continually added.
If supported for the application, selecting the password-based SSO mode and selecting Save instantly configures it
to do password-based SSO. For more information about deploying password-based SSO, see How does single
sign-on with Azure Active Directory work.
Linked sign-on
If supported for the application, selecting the linked SSO mode allows you to enter the URL that you want the
Azure AD Access Panel or Office 365 to redirect to when users click on this app. For more information about linked
SSO (formerly known as "existing SSO"), see How does single sign-on with Azure Active Directory work.
Feedback
We hope you like using the improved Azure AD experience. Please keep the feedback coming! Post your feedback
and ideas for improvement in the Admin Portal section of our feedback forum. We’re excited about building cool
new stuff every day, and use your guidance to shape and define what we build next.
Advanced certificate signing options in the SAML
token for gallery apps in Azure Active Directory
Today Azure Active Directory (Azure AD) supports thousands of pre-integrated applications in the Azure Active
Directory App Gallery. This number includes more than 500 applications that support single sign-on by using the
SAML 2.0 protocol. When a user authenticates to an application through Azure AD by using SAML, Azure AD sends
a token to the application (via an HTTP POST). Then, the application validates and uses the token to log in the user
instead of prompting for a username and password. These SAML tokens are signed with the unique certificate that's
generated in Azure AD and by specific standard algorithms.
Azure AD uses some of the default settings for the gallery applications. The default values are set up based on the
application's requirements.
Azure AD supports advanced certificate signing settings. To select these options, first select the Show advanced
certificate signing settings check box:
After you select this check box, you can set up certificate signing options and the certificate signing algorithm.
Certificate signing options

Azure AD supports three certificate signing options:
Sign SAML assertion. This default option is set for most of the gallery applications. If this option is selected,
Azure AD as an IdP signs the SAML assertion and certificate with the X509 certificate of the application. Also,
it uses the signing algorithm, which is selected in the Signing Algorithm drop-down list.
Sign SAML response. If this option is selected, Azure AD as an IdP signs the SAML response with the X509
certificate of the application. Also, it uses the signing algorithm, which is selected in the Signing Algorithm
drop-down list.
Sign SAML response and assertion. If this option is selected, Azure AD as an IdP signs the entire SAML
token with the X509 certificate of the application. Also, it uses the signing algorithm, which is selected in the
Signing Algorithm drop-down list.
Certificate signing algorithms

Azure AD supports two signing algorithms to sign the SAML response:
SHA-256. Azure AD uses this default algorithm to sign the SAML response. It's the newest algorithm and is
treated as more secure than SHA-1. Most of the applications support the SHA-256 algorithm. If an
application supports only SHA-1 as the signing algorithm, you can change it. Otherwise, we recommend that
you use the SHA-256 algorithm for signing the SAML response.
SHA-1. This is the older algorithm, and it's treated as less secure than SH-256. If an application supports only
this signing algorithm, you can select this option in the Signing Algorithm drop-down list. Azure AD then
signs the SAML response with the SHA-1 algorithm.
Next steps
Configure single sign-on to applications that are not in the Azure Active Directory App Gallery
Troubleshoot SAML-based single sign-on
Hide an application from user's experience in Azure
Active Directory
If you have an application that you do not want to show on users’ access panels or Office 365 launchers, there are
options to hide this app tile. The following two options are available for hiding applications from user's app
launchers.
Hide a third-party application from users access panels and Office 365 app launchers
Hide all Office 365 applications from users access panels
By hiding the app users still have permissions to the app but will not see them appear on their app launchers. You
must have the appropriate permissions to manage the enterprise app, and you must be a global admin for the
directory.
Hiding an application from user's end user experiences

You can use the steps below, depending on your situation, to hide applications from the access panel.
How do I hide a third-party app from user’s access panel and O365 app launchers?
Use the following steps to hide an application from a user's access panel and Office 365 app launchers.
3. On the Azure Active Directory - *directoryname* screen (that is, the Azure AD screen for the directory you
4. On the Enterprise applications screen, select All applications. You see a list of the apps you can manage.
5. On the Enterprise applications - All applications screen, select an app.
6. On the appname screen (that is, the screen with the name of the selected app in the title), select Properties.
7. On the appname - Properties screen, select Yes for Visible to users?.

How do I hide Office 365 applications from user's access panel?
Use the following steps to hide all Office 365 applications from the access panel. These apps will still be visible in
the Office 365 portal.
3. On the Azure Active Directory - *directoryname* screen (that is, the Azure AD screen for the directory you
are managing), select User settings.
4. On the User settings screen, under Enterprise applications select Yes for Users can only see Office 365
apps in the Office 365 portal.
Next steps
See all my groups
Configure sign-in auto-acceleration for an application
by using a Home Realm Discovery policy
The following document provides an introduction to Home Realm Discovery and auto-acceleration.
Home Realm Discovery

Home Realm Discovery (HRD) is the process that allows Azure Active Directory (Azure AD) to determine, at sign-in
time, where a user needs to authenticate. When a user signs in to an Azure AD tenant to access a resource, or to the
Azure AD common sign-in page, they type a user name (UPN). Azure AD uses that to discover where the user needs
to sign in.
The user might need to be taken to one of the following locations to be authenticated:
The home tenant of the user (might be the same tenant as the resource that the user is attempting to access).
Microsoft account. The user is a guest in the resource tenant.
Another identity provider that's federated with the Azure AD tenant.
An on-premises identity provider such as Active Directory Federation Services (AD FS).
Auto-acceleration
Some organizations configure their Azure Active Directory tenant to federate with another IdP, such as AD FS for
user authentication.
In these cases, when a user signs into an application, they are first first presented with an Azure AD sign-in page.
After they have typed their UPN, they are then taken to the IdP sign-in page. Under certain circumstances,
administrators might want to direct users to the sign-in page when they're signing in to specific applications.
This means users can skip the initial Azure Active Directory page. This process is referred to as “sign-in auto-
acceleration.”
In cases where the tenant is federated to another IdP for sign-in, auto-acceleration makes user sign-in more
streamlined. You can configure auto-acceleration for individual applications.
NOTE
If you configure an application for auto-acceleration, guest users cannot sign in. If you take a user straight to a federated IdP
for authentication, there is no way to for them to get back to the Azure Active Directory sign-in page. Guest users, who
might need to be directed to other tenants or an external IdP such as a Microsoft account, can't sign in to that application
because they're skipping the Home Realm Discovery step.
There are two ways to control auto-acceleration to a federated IdP:

Use a domain hint on authentication requests for an application.
Configure a Home Realm Discovery policy to enable auto-acceleration.
Domain hints
Domain hints are directives that are included in the authentication request from an application. They can be used to
accelerate the user to their federated IdP sign-in page. Or they can be used by a multi-tenant application to
accelerate the user straight to the branded Azure AD sign-in page for their tenant.
For example, the application "largeapp.com" might enable their customers to access the application at a custom
URL "contoso.largeapp.com." The app might also include a domain hint to contoso.com in the authentication
request.
Domain hint syntax varies depending on the protocol that's used, and it's typically configured in the application.
WS-Federation: whr=contoso.com in the query string.
SAML: Either a SAML authentication request that contains a domain hint or a query string whr=contoso.com.
Open ID Connect: A query string domain_hint=contoso.com.
If a domain hint is included in the authentication request from the application, and the tenant is federated with that
domain, Azure AD attempts to redirect sign-in to the IdP that's configured for that domain.
If the domain hint doesn’t refer to a verified federated domain, it is ignored and normal Home Realm Discovery is
invoked.
For more information about auto-acceleration using the domain hints that are supported by Azure Active Directory,
see the Enterprise Mobility + Security blog.
NOTE
If a domain hint is included in an authentication request, its presence overrides any HRD policy that is set for the application.
Home Realm Discovery policy

Some applications do not provide a way to configure the authentication request they emit. In these cases, it’s not
possible to use domain hints to control auto-acceleration. Auto-acceleration can be configured via policy to achieve
the same behavior.
Set HRD policy
There are three steps to setting sign-in auto-acceleration on an application:
1. Creating an HRD policy for auto-acceleration.
2. Locating the service principle to which to attach the policy.
3. Attaching the policy to the service principle. Policies might have been created in a tenant, but they don’t have
any effect until they are attached to an entity.
An HRD policy can be attached to a service principal, and only one HRD policy can be active on a given entity at any
one time.
You can use either the Microsoft Azure Active Directory Graph API directly, or the Azure Active Directory
PowerShell cmdlets to set up auto-acceleration using HRD policy.
The Graph API that manipulates policy is described in the Operations on policy article on MSDN.
Following is an example HRD policy definition:
{
"HomeRealmDiscoveryPolicy":
{
"AccelerateToFederatedDomain":true,
"PreferredDomain":"federated.example.edu"
}
}
The policy type is "HomeRealmDiscoveryPolicy."

If AccelerateToFederatedDomain is false, the policy has no effect.
PreferredDomain should indicate a domain to which to accelerate. It can be omitted if the tenant has only one
federated domain. If it is omitted, and there is more than one verified federated domain, the policy has no effect.
If PreferredDomain is specified, it must match a verified, federated domain for the tenant. All users of the
application must be able to sign in to that domain.
Priority and evaluation of HRD policies
HRD policies can be created and then assigned to specific organizations and service principals. This means that it is
possible for multiple policies to apply to a specific application. The HRD policy that takes effect follows these rules:
If a domain hint is present in the authentication request, then any HRD policy is ignored. The behavior that's
specified by the domain hint is used.
Otherwise, if a policy is explicitly assigned to the service principal, it is enforced.
If there is no domain hint, and no policy is explicitly assigned to the service principal, a policy that's explicitly
assigned to the parent organization of the service principal is enforced.
If there is no domain hint, and no policy has been assigned to the service principal or the organization, the
default HRD behavior is used.
Tutorial for setting sign-in auto-acceleration on an application by using

an HRD policy
We'll use Azure AD PowerShell cmdlets to walk through a few scenarios, including:
Setting up auto-acceleration for an application for a tenant with a single federated domain.
Setting up auto-acceleration for an application to one of several domains that are verified for your tenant.
Listing the applications for which a policy is configured.
Prerequisites
In the following examples, you create, update, link, and delete policies on application service principals in Azure AD.
1. To begin, download the latest Azure AD PowerShell cmdlet preview.
2. After you have downloaded the Azure AD PowerShell cmdlets, run the Connect command to sign in to Azure
AD with your admin account:
3. Run the following command to see all the policies in your organization:
Get-AzureADPolicy
If nothing is returned, it means you have no policies created in your tenant.
Example: Set auto -acceleration for an application
In this example, you create a policy that auto-accelerates users to an AD FS sign-in screen when they are signing in
to an application. Users can sign in to AD FS without having to enter a username on the Azure AD sign-in page first.
Step 1: Create an HRD policy
New-AzureADPoly -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFederatedDomain`":true}}") -

DisplayName BasicAutoAccelerationPolicy -Type HomeRealmDiscoveryPolicy
If you have a single federated domain that authenticates users for applications, you need to create only one HRD
policy.
To see your new policy and get its ObjectID, run the following command:
Get-AzureADPolicy
To enable auto-acceleration after you have an HRD policy, you can assign it to multiple application service
principles.
Step 2: Locate the service principal to which to assign the policy
You need the ObjectID of the service principals to which you want to assign the policy. There are several ways to
find the ObjectID of service principals.
You can use the portal, or you can query Microsoft Graph. You can also go to the Graph Explorer Tool and sign in to
your Azure AD account to see all your organization's service principals. Because you are using PowerShell, you can
use the get-AzureADServicePrincipal cmdlet to list the service principles and their IDs.
Step 3: Assign the policy to your service principal
After you have the ObjectID of the service principal of the application for which you want to configure auto-
acceleration, run the following command. This command associates the HRD policy that you created in step 1 with
the service principal that you located in step 2.
Add-AzureADServicePrincipalPolicy -Id <ObjectID of the Service Principal> -RefObjectId <ObjectId of the Policy>
You can repeat this command for each service principal to which you want to add the policy.
Step 4: Check which application service principals your auto-acceleration policy is assigned to
To check which applications have auto-acceleration policy configured, use the Get-AzureADPolicyAppliedObject
cmdlet. Pass it the ObjectID of the policy that you want to check on.
Get-AzureADPolicyAppliedObject -ObjectId <ObjectId of the Policy>
Step 5: You're done!

Try the application to check that the new policy is working.
Example: List the applications for which an auto -acceleration policy is configured
Step 1: List all policies that were created in your organization
Get-AzureADPolicy
Note the ObjectID of the policy that you want to list assignments for.
Step 2: List the service principals to which the policy is assigned
Example: Remove an auto -acceleration policy for an application

Step 1: Get the ObjectID
Use the previous example to get the ObjectID of the policy, and that of the application service principal from which
you want to remove it.
Step 2: Remove the policy assignment from the application service principal
Remove-AzureADApplicationPolicy -ObjectId <ObjectId of the Service Principal> -PolicyId <ObjectId of the

policy>
Step 3: Check removal by listing the service principals to which the policy is assigned
Next steps
For more information about how authentication works in Azure AD, see Authentication scenarios for Azure AD.
For more information about user single sign-on, see Application access and single sign-on with Azure Active
Directory.
Visit the Active Directory developer's guide for an overview of all developer-related content.
Managing access to apps
Ongoing access management, usage evaluation, and reporting continue to be a challenge after an app is
integrated into your organization's identity system. In many cases, IT Administrators or helpdesk have to take an
ongoing active role in managing access to your apps. Sometimes, assignment is performed by a general or
divisional IT team. Often, the assignment decision is intended to be delegated to the business decision maker,
requiring their approval before IT makes the assignment. Other organizations invest in integration with an existing
automated identity and access management system, like Role-Based Access Control (RBAC) or Attribute-Based
Access Control (ABAC). Both the integration and rule development tend to be specialized and expensive.
Monitoring or reporting on either management approach is its own separate, costly, and complex investment.
How does Azure Active Directory help?

Azure AD supports extensive access management for configured applications, enabling organizations to easily
achieve the right access policies ranging from automatic, attribute-based assignment (ABAC or RBAC scenarios)
through delegation and including administrator management. With Azure AD you can easily achieve complex
policies, combining multiple management models for a single application and can even re-use management rules
across applications with the same audiences.
Adding new or existing applications
Azure AD's application assignment focuses on two primary assignment modes:
Individual assignment An IT admin with directory Global Administrator permissions can select individual
user accounts and grant them access to the application.
Group-based assignment (paid Azure AD only) An IT admin with directory Global Administrator
permissions can assign a group to the application. Specific users' access is determined by whether they are
members of the group at the time they attempt to access the application. In other words, an administrator can
effectively create an assignment rule stating "any current member of the assigned group has access to the
application". Using this assignment option, administrators can benefit from any of Azure AD group
management options, including attribute-based dynamic groups, external system groups (for example, on-
premises Active Directory or Workday), or Administrator-managed or self-service-managed groups. A single
group can be easily assigned to multiple apps, ensuring that applications with assignment affinity can share
assignment rules, reducing the overall management complexity. Please note that nested group memberships
are not supported for group-based assignment to applications at this time.
Using these two assignment modes, administrators can achieve any desirable assignment management approach.
With Azure AD, usage and assignment reporting is fully integrated, enabling administrators to easily report on
assignment state, assignment errors, and even usage.
Complex application assignment with Azure AD

Consider an application like Salesforce. In many organizations, Salesforce is primarily used by the marketing and
sales organizations. Often, members of the marketing team have highly privileged access to Salesforce, while
members of the sales team have limited access. In many cases, a broad population of information workers have
restricted access to the application. Exceptions to these rules complicate matters. It is often the prerogative of the
marketing or sales leadership teams to grant a user access or change their roles independently of these generic
rules.
With Azure AD, applications like Salesforce can be pre-configured for single sign-on (SSO) and automated
provisioning. Once the application is configured, an Administrator can take the one-time action to create and
assign the appropriate groups. In this example, an administrator could execute the following assignments:
Dynamic groups can be defined to automatically represent all members of the marketing and sales teams
using attributes like department or role:
All members of marketing groups would be assigned to the "marketing" role in Salesforce
All members of sales team groups would be assigned to the "sales" role in Salesforce. A further
refinement could use multiple groups that represent regional sales teams assigned to different
Salesforce roles.
To enable the exception mechanism, a self-service group could be created for each role. For example, the
"Salesforce marketing exception" group can be created as a self-service group. The group can be assigned to
the Salesforce marketing role and the marketing leadership team can be made owners. Members of the
marketing leadership team could add or remove users, set a join policy, or even approve or deny individual
users' requests to join. This is supported through an information worker appropriate experience that does not
require specialized training for owners or members.
In this case, all assigned users would be automatically provisioned to Salesforce, as they are added to different
groups their role assignment would be updated in Salesforce. Users would be able to discover and access
Salesforce through the Microsoft application access panel, Office web clients, or even by navigating to their
organizational Salesforce login page. Administrators would be able to easily view usage and assignment status
using Azure AD reporting.
Administrators can employ Azure AD conditional access to set access policies for specific roles. These policies can
include whether access is permitted outside the corporate environment and even Multi-Factor Authentication or
device requirements to achieve access in various cases.
How can I get started?

First, if you aren't already using Azure AD and you are an IT admin:
Try it out! - you can sign up for a free 30-day trial today and deploy your first cloud solution in under 5 minutes
using this link
Azure AD features that enable account sharing include:
Group assignment
Adding applications to Azure AD
Getting started with assignment
Application assignment FAQ
App usage dashboard/reports
Where can I learn more?

Protecting apps with conditional access
Self-service group management/SSAA
What is application access and single sign-on with
Azure Active Directory?
Single sign-on means being able to access all of the applications and resources that you need to do business, by
signing in only once using a single user account. Once signed in, you can access all of the applications you need
without being required to authenticate (for example, type a password) a second time.
Many organizations rely upon software as a service (SaaS) applications such as Office 365, Box and Salesforce for
end-user productivity. Historically, IT staff needs to individually create and update user accounts in each SaaS
application, and users have to remember a password for each SaaS application.
Azure Active Directory extends on-premises Active Directory into the cloud, enabling users to use their primary
organizational account to not only sign in to their domain-joined devices and company resources, but also all of
the web and SaaS applications needed for their job.
So not only do users not have to manage multiple sets of usernames and passwords, their applications access can
be automatically provisioned or de-provisioned based on their organization group members, and also their status
as an employee. Azure Active Directory introduces security and access governance controls that enable you to
centrally manage users' access across SaaS applications.
Azure AD enables easy integration to many of today’s popular SaaS applications; it provides identity and access
management, and enables users to single sign-on to applications directly, or discover and launch them from a
portal such as Office 365 or the Azure AD access panel.
The architecture of the integration consists of the following four main building blocks:
Single sign-on enables users to access their SaaS applications based on their organizational account in Azure
AD. Single sign-on is what enables users to authenticate to an application using their single organizational
account.
User provisioning enables user provisioning and de-provisioning into target SaaS based on changes made in
Windows Server Active Directory and/or Azure AD. A provisioned account is what enables a user to be
authorized to use an application, after they have authenticated through single sign-on.
Centralized application access management in the Azure portal enables single point of SaaS application access
and management, with the ability to delegate application access decision making and approvals to anyone in
the organization
Unified reporting and monitoring of user activity in Azure AD
How does single sign-on with Azure Active Directory work?

When a user “signs in” to an application, they go through an authentication process where they are required to
prove that they are who they say they are. Without single sign-on, this is typically done by entering a password
that is stored at the application, and the user is required to know this password.
Azure AD supports three different ways to sign in to applications:
Federated single sign-on enables applications to redirect to Azure AD for user authentication instead of
prompting for its own password. This is supported for applications that support protocols such as SAML 2.0,
WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.
Password-based single sign-on enables secure application password storage and replay using a web
browser extension or mobile app. This leverages the existing sign-in process provided by the application, but
enables an administrator to manage the passwords and does not require the user to know the password.
Existing single sign-on enables Azure AD to leverage any existing single sign-on that has been set up for the
application, but enables these applications to be linked to the Office 365 or Azure AD access panel portals, and
also enables additional reporting in Azure AD when the applications are launched there.
Once a user has authenticated with an application, they also need to have an account record provisioned at the
application that tells the application where there permissions and level of access are inside the application. The
provisioning of this account record can either occur automatically, or it can occur manually by an administrator
before the user is provided single sign-on access.
More details on these single sign-on modes and provisioning below.
Federated single sign-on
Federated single sign-on enables the users in your organization to be automatically signed in to a third-party SaaS
application by Azure AD using the user account information from Azure AD.
In this scenario, when you have already been logged into Azure AD, and you want to access resources that are
controlled by a third-party SaaS application, federation eliminates the need for a user to be reauthenticated.
Azure AD can support federated single sign-on with applications that support the SAML 2.0, WS-Federation, or
OpenID connect protocols.
See also: Managing Certificates for Federated Single Sign-On
Password-based single sign-on
Configuring password-based single sign-on enables the users in your organization to be automatically signed in
to a third-party SaaS application by Azure AD using the user account information from the third-party SaaS
application. When you enable this feature, Azure AD collects and securely stores the user account information and
the related password.
Azure AD can support password-based single sign-on for any cloud-based app that has an HTML-based sign-in
page. By using a custom browser plugin, AAD automates the user’s sign-in process via securely retrieving
application credentials such as the username and the password from the directory, and enters these credentials
into the application’s sign-in page on behalf of the user. There are two use cases:
1. Administrator manages credentials – Administrators can create and manage application credentials, and
assign those credentials to users or groups who need access to the application. In these cases, the end user
does not need to know the credentials, but still gains single sign-on access to the application simply by clicking
on it in their access panel or via a provided link. This enables both, lifecycle management of the credentials by
the administrator, as well as convenience for end users whereby they do not need to remember or manage
app-specific passwords. The credentials are obfuscated from the end user during the automated sign-in
process; however they are technically discoverable by the user using web-debugging tools, and users and
administrators should follow the same security policies as if the credentials were presented directly by the user.
Administrator-provided credentials are useful when providing account access that is shared among many
users, such as social media or document sharing applications.
2. User manages credentials – Administrators can assign applications to end users or groups, and allow the end
users to enter their own credentials directly upon accessing the application for the first time in their access
panel. This creates a convenience for end users whereby they do not need to continually enter the app-specific
passwords each time they access the application. This use case can also be used as a stepping stone to
administrative management of the credentials, whereby the administrator can set new credentials for the
application at a future date without changing the app access experience of the end user.
In both cases, credentials are stored in an encrypted state in the directory, and are only passed over HTTPS during
the automated sign-in process. Using password-based single sign-on, Azure AD offers a convenient identity access
management solution for apps that are not capable of supporting federation protocols.
Password-based SSO relies on a browser extension to securely retrieve the application and user-specific
information from Azure AD and apply it to the service. Most third-party SaaS applications that are supported by
Azure AD support this feature.
For password-based SSO, the end user’s browsers can be:
Internet Explorer 8, 9, 10, 11 -- on Windows 7 or later
Edge on Windows 10 Anniversary Edition or later
Chrome -- on Windows 7 or later, and on MacOS X or later
Firefox 26.0 or later -- on Windows XP SP2 or later, and on Mac OS X 10.6 or later
Existing single sign-on
When configuring single sign-on for an application, the Azure portal provides a third option of “Existing Single
Sign-On”. This option simply allows the administrator to create a link to an application, and place it on the access
panel for selected users.
For example, if there is an application that is configured to authenticate users using Active Directory Federation
Services 2.0, an administrator can use the “Existing Single Sign-On” option to create a link to it on the access panel.
When users access the link, they are authenticated using Active Directory Federation Services 2.0, or whatever
existing single sign-on solution is provided by the application.
User provisioning
For select applications, Azure AD enables automated user provisioning and de-provisioning of accounts in third-
party SaaS applications from within the Azure Management Portal, using your Windows Server Active Directory or
Azure AD identity information. When a user is given permissions in Azure AD for one of these applications, an
account can be automatically created (provisioned) in the target SaaS application.
When a user is deleted or their information changes in Azure AD, these changes are also reflected in the SaaS
application. This means, configuring automated identity lifecycle management enables administrators to control
and provide automated provisioning and de-provisioning from SaaS applications. In Azure AD, this automation of
identity lifecycle management is enabled by user provisioning.
To learn more, see Automated User Provisioning and Deprovisioning to SaaS Applications
Get started with the Azure AD application gallery

Ready to get started? To deploy single sign-on between Azure AD and SaaS applications that your organization
uses, follow these guidelines.
Using the Azure AD application gallery
The Azure Active Directory Application Gallery provides a listing of applications that are known to support a form
of single sign-on with Azure Active Directory.
Here are some tips for finding apps by what capabilities they support:
Azure AD supports automatic provisioning and de-provisioning for all “Featured” apps in the Azure Active
Directory Application Gallery.
A list of federated applications that specifically support federated single sign-on using a protocol such as SAML,
WS-Federation, or OpenID Connect can be found here.
Once you’ve found your application, you can get started by follow the step-by-step instructions presented in the
app gallery and in the Azure management portal to enable single sign-on.
Application not in the gallery?
If your application is not found in the Azure AD application gallery, then you have these options:
Add an unlisted app you are using - Use the Custom category in the app gallery within the Azure
management portal to connect an unlisted application that your organization is using. You can add any
application that supports SAML 2.0 as a federated app, or any application that has an HTML-based sign-in page
as a password SSO app. For more details, see this article on adding your own application.
Add your own app you are developing - If you have developed the application yourself, follow the
guidelines in the Azure AD developer documentation to implement federated single sign-on or provisioning
using the Azure AD graph API. For more information, see these resources:
Authentication Scenarios for Azure AD
https://github.com/AzureADSamples/WebApp-MultiTenant-OpenIdConnect-DotNet
https://github.com/AzureADSamples/WebApp-WebAPI-MultiTenant-OpenIdConnect-DotNet
https://github.com/AzureADSamples/NativeClient-WebAPI-MultiTenant-WindowsStore
Request an app integration - Request support for the application you need using the Azure AD feedback
forum.
Using the Azure portal
You can use the Active Directory extension in the Azure portal to configure the application single sign-on. As a first
step, you need to select a directory from the Active Directory section in the portal:
To manage your third-party SaaS applications, you can switch into the Applications tab of the selected directory.
This view enables administrators to:
Add new applications from the Azure AD gallery, as well as apps you are developing
Delete integrated applications
Manage the applications they have already integrated
Typical administrative tasks for a third-party SaaS application are:
Enabling single sign-on with Azure AD, using password SSO or, if available for the target SaaS, federated SSO
Optionally, enabling user provisioning for user provisioning and de-provisioning (identity lifecycle
management)
For applications where user provisioning is enabled, selecting which users have access to that application
For gallery apps that support federated single sign-on, configuration typically requires you to provide additional
configuration settings such as certificates and metadata to create a federated trust between the third-party app
and Azure AD. The configuration wizard walks you through the details and provides you with easy access to the
SaaS application-specific data and instructions.
For gallery apps that support automatic user provisioning, this requires you to give Azure AD permissions to
manage your accounts in the SaaS application. At a minimum, you need to provide credentials Azure AD should
use when authenticating over to the target application. Whether additional configuration settings need to be
provided depends on the requirements of the application.
Deploying Azure AD integrated applications to users

Azure AD provides several customizable ways to deploy applications to end users in your organization:
Azure AD access panel
Office 365 application launcher
Direct sign-on to federated apps
Deep links to federated, password-based, or existing apps
Which method(s) you choose to deploy in your organization is your discretion.
Azure AD access panel
The Access Panel at https://myapps.microsoft.com is a web-based portal that allows an end user with an
organizational account in Azure Active Directory to view and launch cloud-based applications to which they have
been granted access by the Azure AD administrator. If you are an end user with Azure Active Directory Premium,
you can also utilize self-service group management capabilities through the Access Panel.
The Access Panel is separate from the Azure portal and does not require users to have an Azure subscription or
Office 365 subscription.
For more information on the Azure AD access panel, see the introduction to the access panel.
Office 365 application launcher
For organizations that have deployed Office 365, applications assigned to users through Azure AD will also appear
in the Office 365 portal at https://portal.office.com/myapps. This makes it easy and convenient for users in an
organization to launch their apps without having to use a second portal, and is the recommended app launching
solution for organizations using Office 365.
For more information about the Office 365 application launcher, see Have your app appear in the Office 365 app
launcher.
Direct sign-on to federated apps
Most federated applications that support SAML 2.0, WS-Federation, or OpenID connect also support the ability for
users to start at the application, and then get signed in through Azure AD either by automatic redirection or by
clicking on a link to sign in. This is known as service provider -initiated sign-on, and most federated applications in
the Azure AD application gallery support this (see the documentation linked from the app’s single sign-on
configuration wizard in the Azure management portal for details).
Direct sign-on links for federated, password-based, or existing apps

Azure AD also supports direct single sign-on links to individual applications that support password-based single
sign-on, existing single sign-on, and any form of federated single sign-on.
These links are specifically crafted URLs that send a user through the Azure AD sign in process for a specific
application without requiring the user launch them from the Azure AD access panel or Office 365. These Single
Sign-On URLs can be found under the Dashboard tab of any pre-integrated application in the Active Directory
section of the Azure management portal, as shown in the screenshot below.
These links can be copied and pasted anywhere you want to provide a sign-in link to the selected application. This
could be in an email, or in any custom web-based portal that you have set up for user application access. Here's an
example of an Azure AD direct single sign-on URL for Twitter:
https://myapps.microsoft.com/signin/Twitter/230848d52c8745d4b05a60d29a40fced
Similar to organization-specific URLs for the access panel, you can further customize this URL by adding one of the
active or verified domains 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/contosobuild.com/signin/Twitter/230848d52c8745d4b05a60d29a40fced
When an authorized user clicks on one of these application-specific links, they first see their organizational sign-in
page (assuming they are not already signed in), and after sign-in are redirected to their app without stopping at
the access panel first. If the user is missing pre-requisites to access the application, such as the password-based
single sign browser extension, then the link will prompt the user to install the missing extension. The link URL also
remains constant if the single sign-on configuration for the application changes.
These links use the same access control mechanisms as the access panel and Office 365, 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.
Related articles
List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory
Finding unsanctioned cloud applications with Cloud App Discovery
Introduction to Managing Access to Apps
Comparing Capabilities for Managing External Identities in Azure AD
Manage certificates for federated single sign-on in
This article covers common questions and information related to the certificates that Azure Active Directory (Azure
AD) creates to establish federated single sign-on (SSO) to your SaaS applications. Add applications from the Azure
AD app gallery or by using a non-gallery application template. Configure the application by using the federated
SSO option.
This article is relevant only to apps that are configured to use Azure AD SSO through SAML federation, as shown in
the following example:
Auto-generated certificate for gallery and non-gallery applications

When you add a new application from the gallery and configure a SAML-based sign-on, Azure AD generates a
certificate for the application that is valid for three years. You can download this certificate from the SAML Signing
Certificate section. For gallery applications, this section might show an option to download the certificate or
metadata, depending on the requirement of the application.
Customize the expiration date for your federation certificate and roll it
over to a new certificate
By default, certificates are set to expire after three years. You can choose a different expiration date for your
certificate by completing the following steps. The screenshots use Salesforce for the sake of example, but these
steps can apply to any federated SaaS app.
1. In the Azure portal, click Enterprise application in the left pane and then click New application on the
Overview page:
2. Search for the gallery application and then select the application that you want to add. If you cannot find the
required application, add the application by using the Non-gallery application option. This feature is
available only in the Azure AD Premium (P1 and P2) SKU.
3. Click the Single sign-on link in the left pane and change Single Sign-on Mode to SAML-based Sign-on.
This step generates a three-year certificate for your application.
4. To create a new certificate, click the Create new certificate link in the SAML Signing Certificate section.
5. The Create a new certificate link opens the calendar control. You can set any date and time up to three
years from the current date. The selected date and time is the new expiration date and time of your new
certificate. Click Save.
6. Now the new certificate is available to download. Click the Certificate link to download it. At this point, your
certificate is not active. When you want to roll over to this certificate, select the Make new certificate
active check box and click Save. From that point, Azure AD starts using the new certificate for signing the
response.
7. To learn how to upload the certificate to your particular SaaS application, click the View application
configuration tutorial link.
Renew a certificate that will soon expire

The following renewal steps should result in no significant downtime for your users. The screenshots in this section
feature Salesforce as an example, but these steps can apply to any federated SaaS app.
1. On the Azure Active Directory application Single sign-on page, generate the new certificate for your
application. You can do this by clicking the Create new certificate link in the SAML Signing Certificate
section.
2. Select the desired expiration date and time for your new certificate and click Save.
3. Download the certificate in the SAML Signing certificate option. Upload the new certificate to the SaaS
application's single sign-on configuration screen. To learn how to do this for your particular SaaS
application, click the View application configuration tutorial link.
4. To activate the new certificate in Azure AD, select the Make new certificate active check box and click the
Save button at the top of the page. This rolls over the new certificate on the Azure AD side. The status of the
certificate changes from New to Active. From that point, Azure AD starts using the new certificate for
signing the response.
Related articles
List of tutorials on how to integrate SaaS apps with Azure Active Directory
Application access and single sign-on with Azure Active Directory
Troubleshooting SAML-based single sign-on
Use Tenant Restrictions to manage access to SaaS
cloud applications
Large organizations that emphasize security want to move to cloud services like Office 365, but need to know that
their users only can access approved resources. Traditionally, companies restrict domain names or IP addresses
when they want to manage access. This approach fails in a world where SaaS apps are hosted in a public cloud,
running on shared domain names like outlook.office.com and login.microsoftonline.com. Blocking these addresses
would keep users from accessing Outlook on the web entirely, instead of merely restricting them to approved
identities and resources.
Azure Active Directory's solution to this challenge is a feature called Tenant Restrictions. Tenant Restrictions enables
organizations to control access to SaaS cloud applications, based on the Azure AD tenant the applications use for
single sign-on. For example, you may want to allow access to your organization’s Office 365 applications, while
preventing access to other organizations’ instances of these same applications.
Tenant Restrictions gives organizations the ability to specify the list of tenants that their users are permitted to
access. Azure AD then only grants access to these permitted tenants.
This article focuses on Tenant Restrictions for Office 365, but the feature should work with any SaaS cloud app that
uses modern authentication protocols with Azure AD for single sign-on. If you use SaaS apps with a different Azure
AD tenant from the tenant used by Office 365, make sure that all required tenants are permitted. For more
information about SaaS cloud apps, see the Active Directory Marketplace.
How it works
The overall solution comprises the following components:
1. Azure AD – If the Restrict-Access-To-Tenants: <permitted tenant list> is present, Azure AD only issues
security tokens for the permitted tenants.
2. On-premises proxy server infrastructure – a proxy device capable of SSL inspection, configured to insert
the header containing the list of permitted tenants into traffic destined for Azure AD.
3. Client software – to support Tenant Restrictions, client software must request tokens directly from Azure
AD, so that traffic can be intercepted by the proxy infrastructure. Tenant Restrictions is currently supported
by browser-based Office 365 applications and by Office clients when modern authentication (like OAuth 2.0)
is used.
4. Modern Authentication – cloud services must use modern authentication to use Tenant Restrictions and
block access to all non-permitted tenants. Office 365 cloud services must be configured to use modern
authentication protocols by default. For the latest information on Office 365 support for modern
authentication, read Updated Office 365 modern authentication.
The following diagram illustrates the high-level traffic flow. SSL inspection is only required on traffic to Azure AD,
not to the Office 365 cloud services. This distinction is important because the traffic volume for authentication to
Azure AD is typically much lower than traffic volume to SaaS applications like Exchange Online and SharePoint
Online.
Set up Tenant Restrictions
There are two steps to get started with Tenant Restrictions. The first step is to make sure that your clients can
connect to the right addresses. The second is to configure your proxy infrastructure.
URLs and IP addresses
To use Tenant Restrictions, your clients must be able to connect to the following Azure AD URLs to authenticate:
login.microsoftonline.com, login.microsoft.com, and login.windows.net. Additionally, to access Office 365, your
clients must also be able to connect to the FQDNs/URLs and IP addresses defined in Office 365 URLs and IP address
ranges.
Proxy configuration and requirements
The following configuration is required to enable Tenant Restrictions through your proxy infrastructure. This
guidance is generic, so you should refer to your proxy vendor’s documentation for specific implementation steps.
Prerequisites
The proxy must be able to perform SSL interception, HTTP header insertion, and filter destinations using
FQDNs/URLs.
Clients must trust the certificate chain presented by the proxy for SSL communications. For example, if
certificates from an internal PKI are used, the internal issuing root certificate authority certificate must be
trusted.
This feature is included in Office 365 subscriptions, but if you want to use Tenant Restrictions to control
access to other SaaS apps then Azure AD Premium 1 licenses are required.
Configuration
For each incoming request to login.microsoftonline.com, login.microsoft.com, and login.windows.net, insert two
HTTP headers: Restrict-Access-To-Tenants and Restrict-Access-Context.
The headers should include the following elements:
For Restrict-Access-To-Tenants, a value of <permitted tenant list>, which is a comma-separated list of tenants
you want to allow users to access. Any domain that is registered with a tenant can be used to identify the tenant
in this list. For example, to permit access to both Contoso and Fabrikam tenants, the name/value pair looks like:
Restrict-Access-To-Tenants: contoso.onmicrosoft.com,fabrikam.onmicrosoft.com
For Restrict-Access-Context, a value of a single directory ID, declaring which tenant is setting the Tenant
Restrictions. For example, to declare Contoso as the tenant that set the Tenant Restrictions policy, the
name/value pair looks like: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d
TIP
You can find your directory ID in the Azure portal. Sign in as an administrator, select Azure Active Directory, then select
Properties.
To prevent users from inserting their own HTTP header with non-approved tenants, the proxy needs to replace the
Restrict-Access-To-Tenants header if it is already present in the incoming request.
Clients must be forced to use the proxy for all requests to login.microsoftonline.com, login.microsoft.com, and
login.windows.net. For example, if PAC files are used to direct clients to use the proxy, end users should not be able
to edit or disable the PAC files.
The user experience

This section shows the experience for both end users and admins.
End-user experience
An example user is on the Contoso network, but is trying to access the Fabrikam instance of a shared SaaS
application like Outlook online. If Contoso is a non-permitted tenant for that instance, the user sees the following
page:
Admin experience
While configuration of Tenant Restrictions is done on the corporate proxy infrastructure, admins can access the
Tenant Restrictions reports in the Azure portal directly. To view the reports, go to the Azure Active Directory
Overview page, then look under ‘Other capabilities’.
The admin for the tenant specified as the Restricted-Access-Context tenant can use this report to see all sign-ins
blocked because of the Tenant Restrictions policy, including the identity used and the target directory ID.
Like other reports in the Azure portal, you can use filters to specify the scope of your report. You can filter on a
specific user, application, client, or time interval.
Office 365 support

Office 365 applications must meet two criteria to fully support Tenant Restrictions:
1. The client used supports modern authentication
2. Modern authentication is enabled as the default authentication protocol for the cloud service.
Refer to Updated Office 365 modern authentication for the latest information on which Office clients currently
support modern authentication. That page also includes links to instructions for enabling modern authentication on
specific Exchange Online and Skype for Business Online tenants. Modern authentication is already enabled by
default in SharePoint Online.
Tenant Restrictions is currently supported by Office 365 browser-based applications (the Office Portal, Yammer,
SharePoint sites, Outlook on the Web, etc.). For thick clients (Outlook, Skype for Business, Word, Excel, PowerPoint,
etc.) Tenant Restrictions can only be enforced when modern authentication is used.
Outlook and Skype for Business clients that support modern authentication are still able to use legacy protocols
against tenants where modern authentication is not enabled, effectively bypassing Tenant Restrictions. For Outlook
on Windows, customers may choose to implement restrictions preventing end users from adding non-approved
mail accounts to their profiles. For example, see the Prevent adding non-default Exchange accounts group policy
setting. For Outlook on non-Windows platforms, and for Skype for Business on all platforms, full support for Tenant
Restrictions is not currently available.
Testing
If you want to try out Tenant Restrictions before implementing it for your whole organization, there are two options:
a host-based approach using a tool like Fiddler, or a staged rollout of proxy settings.
Fiddler for a host-based approach
Fiddler is a free web debugging proxy that can be used to capture and modify HTTP/HTTPS traffic, including
inserting HTTP headers. To configure Fiddler to test Tenant Restrictions, perform the following steps:
1. Download and install Fiddler.
2. Configure Fiddler to decrypt HTTPS traffic, per Fiddler’s help documentation.
3. Configure Fiddler to insert the Restrict-Access-To-Tenants and Restrict-Access-Context headers using custom
rules:
a. In the Fiddler Web Debugger tool, select the Rules menu and select Customize Rules… to open the
CustomRules file.
b. Add the following lines at the beginning of the OnBeforeRequest function. Replace <tenant domain> with
a domain registered with your tenant, for example, contoso.onmicrosoft.com. Replace <directory ID> with
your tenant's Azure AD GUID identifier.
if (oSession.HostnameIs("login.microsoftonline.com") || oSession.HostnameIs("login.microsoft.com") ||
oSession.HostnameIs("login.windows.net")){ oSession.oRequest["Restrict-Access-To-Tenants"] = "
<tenant domain>"; oSession.oRequest["Restrict-Access-Context"] = "<directory ID>";}
If you need to allow multiple tenants, use a comma to separate the tenant names. For example:
oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";
4. Save and close the CustomRules file.

After you configure Fiddler, you can capture traffic by going to the File menu and selecting Capture Traffic.
Staged rollout of proxy settings
Depending on the capabilities of your proxy infrastructure, you may be able to stage the rollout of settings to your
users. Here are a couple high-level options for consideration:
1. Use PAC files to point test users to a test proxy infrastructure, while normal users continue to use the production
proxy infrastructure.
2. Some proxy servers may support different configurations using groups.
Refer to your proxy server documentation for specific details.
Next steps
Read about Updated Office 365 modern authentication
Review the Office 365 URLs and IP address ranges
Using System for Cross-Domain Identity
Management to automatically provision users and
groups from Azure Active Directory to applications
Overview
Azure Active Directory (Azure AD) can automatically provision users and groups to any application or identity store
that is fronted by a web service with the interface defined in the System for Cross-Domain Identity Management
(SCIM) 2.0 protocol specification. Azure Active Directory can send requests to create, modify, or delete assigned
users and groups to the web service. The web service can then translate those requests into operations on the
target identity store.
Figure 1: Provisioning from Azure Active Directory to an identity store via a web service
This capability can be used in conjunction with the “bring your own app” capability in Azure AD to enable single
sign-on and automatic user provisioning for applications that provide or are fronted by a SCIM web service.
There are two use cases for using SCIM in Azure Active Directory:
Provisioning users and groups to applications that support SCIM Applications that support SCIM 2.0 and
use OAuth bearer tokens for authentication works with Azure AD without configuration.
Build your own provisioning solution for applications that support other API-based provisioning For
non-SCIM applications, you can create a SCIM endpoint to translate between the Azure AD SCIM endpoint and
any API the application supports for user provisioning. To help you develop a SCIM endpoint, we provide
Common Language Infrastructure (CLI) libraries along with code samples that show you how to do provide a
SCIM endpoint and translate SCIM messages.
Provisioning users and groups to applications that support SCIM

Azure AD can be configured to automatically provision assigned users and groups to applications that implement a
System for Cross-domain Identity Management 2 (SCIM) web service and accept OAuth bearer tokens for
authentication. Within the SCIM 2.0 specification, applications must meet these requirements:
Supports creating users and/or groups, as per section 3.3 of the SCIM protocol.
Supports modifying users and/or groups with patch requests as per section 3.5.2 of the SCIM protocol.
Supports retrieving a known resource as per section 3.4.1 of the SCIM protocol.
Supports querying users and/or groups, as per section 3.4.2 of the SCIM protocol. By default, users are queried
by externalId and groups are queried by displayName.
Supports querying user by ID and by manager as per section 3.4.2 of the SCIM protocol.
Supports querying groups by ID and by member as per section 3.4.2 of the SCIM protocol.
Accepts OAuth bearer tokens for authorization as per section 2.1 of the SCIM protocol.
Check with your application provider, or your application provider's documentation for statements of compatibility
with these requirements.
Getting started
Applications that support the SCIM profile described in this article can be connected to Azure Active Directory using
the "non-gallery application" feature in the Azure AD application gallery. Once connected, Azure AD runs a
synchronization process every 20 minutes where it queries the application's SCIM endpoint for assigned users and
groups, and creates or modifies them according to the assignment details.
To connect an application that supports SCIM:
2. Browse to Azure Active Directory > Enterprise Applications, and select **New application > All > Non-
gallery application.
3. Enter a name for your application, and click Add icon to create an app object.
Figure 2: Azure AD application gallery

4. In the resulting screen, select the Provisioning tab in the left column.
5. In the Provisioning Mode menu, select Automatic.
Figure 3: Configuring provisioning in the Azure portal
6. In the Tenant URL field, enter the URL of the application's SCIM endpoint. Example:
https://api.contoso.com/scim/v2/
7. If the SCIM endpoint requires an OAuth bearer token from an issuer other than Azure AD, then copy the
required OAuth bearer token into the optional Secret Token field. If this field is left blank, then Azure AD
included an OAuth bearer token issued from Azure AD with each request. Apps that use Azure AD as an identity
provider can validate this Azure AD -issued token.
8. Click the Test Connection button to have Azure Active Directory attempt to connect to the SCIM endpoint. If
the attempts fail, error information is displayed.
9. If the attempts to connect to the application succeed, then click Save to save the admin credentials.
10. In the Mappings section, there are two selectable sets of attribute mappings: one for user objects and one
for group objects. Select each one to review the attributes that are synchronized from Azure Active Directory
to your app. The attributes selected as Matching properties are used to match the users and groups in your
app for update operations. Select the Save button to commit any changes.
NOTE
You can optionally disable syncing of group objects by disabling the "groups" mapping.
11. Under Settings, the Scope field defines which users and or groups are synchronized. Selecting "Sync only
assigned users and groups" (recommended) will only sync users and groups assigned in the Users and
groups tab.
12. Once your configuration is complete, change the Provisioning Status to On.
13. Click Save to start the Azure AD provisioning service.
14. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users and/or groups you wish to sync.
Once the initial synchronization has started, you can use the Audit logs tab to monitor progress, which shows all
actions performed by the provisioning service on your app. For more information on how to read the Azure AD
provisioning logs, see Reporting on automatic user account provisioning.
NOTE
The initial sync takes longer to perform than subsequent syncs, which occur approximately every 20 minutes as long as the
service is running.
Building your own provisioning solution for any application

By creating a SCIM web service that interfaces with Azure Active Directory, you can enable single sign-on and
automatic user provisioning for virtually any application that provides a REST or SOAP user provisioning API.
Here’s how it works:
1. Azure AD provides a common language infrastructure library named
Microsoft.SystemForCrossDomainIdentityManagement. System integrators and developers can use this library
to create and deploy a SCIM-based web service endpoint capable of connecting Azure AD to any application’s
identity store.
2. Mappings are implemented in the web service to map the standardized user schema to the user schema and
protocol required by the application.
3. The endpoint URL is registered in Azure AD as part of a custom application in the application gallery.
4. Users and groups are assigned to this application in Azure AD. Upon assignment, they are put into a queue to be
synchronized to the target application. The synchronization process handling the queue runs every 20 minutes.
Code Samples
To make this process easier, a set of code samples are provided that create a SCIM web service endpoint and
demonstrate automatic provisioning. One sample is of a provider that maintains a file with rows of comma-
separated values representing users and groups. The other is of a provider that operates on the Amazon Web
Services Identity and Access Management service.
Prerequisites
Visual Studio 2013 or later
Azure SDK for .NET
Windows machine that supports the ASP.NET framework 4.5 to be used as the SCIM endpoint. This machine
must be accessible from the cloud
An Azure subscription with a trial or licensed version of Azure AD Premium
The Amazon AWS sample requires libraries from the AWS Toolkit for Visual Studio. For more information, see
the README file included with the sample.
Getting Started
The easiest way to implement a SCIM endpoint that can accept provisioning requests from Azure AD is to build and
deploy the code sample that outputs the provisioned users to a comma-separated value (CSV) file.
To create a sample SCIM endpoint:
1. Download the code sample package at https://github.com/Azure/AzureAD-BYOA-Provisioning-
Samples/tree/master
2. Unzip the package and place it on your Windows machine at a location such as C:\AzureAD-BYOA-Provisioning-
Samples.
3. In this folder, launch the FileProvisioningAgent solution in Visual Studio.
4. Select Tools > Library Package Manager > Package Manager Console, and execute the following
commands for the FileProvisioningAgent project to resolve the solution references:
Install-Package Microsoft.SystemForCrossDomainIdentityManagement Install-Package
Microsoft.IdentityModel.Clients.ActiveDirectory Install-Package Microsoft.Owin.Diagnostics Install-Package
Microsoft.Owin.Host.SystemWeb
5. Build the FileProvisioningAgent project.
6. Launch the Command Prompt application in Windows (as an Administrator), and use the cd command to
change the directory to your \AzureAD-BYOA-Provisioning-Samples\ProvisioningAgent\bin\Debug
folder.
7. Run the following command, replacing with the IP address or domain name of the Windows machine:
FileAgnt.exe http://<ip-address>:9000 TargetFile.csv
8. In Windows under Windows Settings > Network & Internet Settings, select the Windows Firewall >
Advanced Settings, and create an Inbound Rule that allows inbound access to port 9000.
9. If the Windows machine is behind a router, the router needs to be configured to perform Network Access
Translation between its port 9000 that is exposed to the internet, and port 9000 on the Windows machine. This
is required for Azure AD to be able to access this endpoint in the cloud.
To register the sample SCIM endpoint in Azure AD:
2. Browse to Azure Active Directory > Enterprise Applications, and select **New application > All > Non-
gallery application.
3. Enter a name for your application, and click Add icon to create an app object. The application object created is
intended to represent the target app you would be provisioning to and implementing single sign-on for, and not
just the SCIM endpoint.
4. In the resulting screen, select the Provisioning tab in the left column.
5. In the Provisioning Mode menu, select Automatic.
Figure 4: Configuring provisioning in the Azure portal
6. In the Tenant URL field, enter the internet-exposed URL and port of your SCIM endpoint. This would be
something like http://testmachine.contoso.com:9000 or http://:9000/, where is the internet exposed IP
address.
7. If the SCIM endpoint requires an OAuth bearer token from an issuer other than Azure AD, then copy the
required OAuth bearer token into the optional Secret Token field. If this field is left blank, then Azure AD will
include an OAuth bearer token issued from Azure AD with each request. Apps that use Azure AD as an identity
provider can validate this Azure AD -issued token.
8. Click the Test Connection button to have Azure Active Directory attempt to connect to the SCIM endpoint. If
the attempts fail, error information is displayed.
9. If the attempts to connect to the application succeed, then click Save to save the admin credentials.
10. In the Mappings section, there are two selectable sets of attribute mappings: one for user objects and one for
group objects. Select each one to review the attributes that are synchronized from Azure Active Directory to
your app. The attributes selected as Matching properties are used to match the users and groups in your app
for update operations. Select the Save button to commit any changes.
11. Under Settings, the Scope field defines which users and or groups are synchronized. Selecting "Sync only
assigned users and groups" (recommended) will only sync users and groups assigned in the Users and groups
tab.
12. Once your configuration is complete, change the Provisioning Status to On.
13. Click Save to start the Azure AD provisioning service.
14. If syncing only assigned users and groups (recommended), be sure to select the Users and groups tab and
assign the users and/or groups you wish to sync.
Once the initial synchronization has started, you can use the Audit logs tab to monitor progress, which shows all
actions performed by the provisioning service on your app. For more information on how to read the Azure AD
provisioning logs, see Reporting on automatic user account provisioning.
The final step in verifying the sample is to open the TargetFile.csv file in the \AzureAD-BYOA-Provisioning-
Samples\ProvisioningAgent\bin\Debug folder on your Windows machine. Once the provisioning process is run,
this file shows the details of all assigned and provisioned users and groups.
Development libraries
To develop your own web service that conforms to the SCIM specification, first familiarize yourself with the
following libraries provided by Microsoft to help accelerate the development process:
1. Common Language Infrastructure (CLI) libraries are offered for use with languages based on that
infrastructure, such as C#. One of those libraries,
Microsoft.SystemForCrossDomainIdentityManagement.Service, declares an interface,
Microsoft.SystemForCrossDomainIdentityManagement.IProvider, shown in the following illustration: A
developer using the libraries would implement that interface with a class that may be referred to,
generically, as a provider. The libraries enable the developer to deploy a web service that conforms to the
SCIM specification. The web service can be either hosted within Internet Information Services, or any
executable Common Language Infrastructure assembly. Request is translated into calls to the provider’s
methods, which would be programmed by the developer to operate on some identity store.
2. Express route handlers are available for parsing node.js request objects representing calls (as defined by the
SCIM specification), made to a node.js web service.
Building a Custom SCIM Endpoint
Using the CLI libraries, developers using those libraries can host their services within any executable Common
Language Infrastructure assembly, or within Internet Information Services. Here is sample code for hosting a
service within an executable assembly, at the address http://localhost:9000:
private static void Main(string[] arguments)

{
// Microsoft.SystemForCrossDomainIdentityManagement.IMonitor,
// Microsoft.SystemForCrossDomainIdentityManagement.IProvider and
// Microsoft.SystemForCrossDomainIdentityManagement.Service are all defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Service.dll.
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor =
new DevelopersMonitor();
Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider =
new DevelopersProvider(arguments[1]);
Microsoft.SystemForCrossDomainIdentityManagement.Service webService = null;
try
{
webService = new WebService(monitor, provider);
webService.Start("http://localhost:9000");
Console.ReadKey(true);
}
finally
{
if (webService != null)
{
{
webService.Dispose();
webService = null;
}
}
}
public class WebService : Microsoft.SystemForCrossDomainIdentityManagement.Service

{
private Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor;
private Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider;
public WebService(
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitoringBehavior,
Microsoft.SystemForCrossDomainIdentityManagement.IProvider providerBehavior)
{
this.monitor = monitoringBehavior;
this.provider = providerBehavior;
}
public override IMonitor MonitoringBehavior

{
get
{
return this.monitor;
}
set
{
this.monitor = value;
}
}
public override IProvider ProviderBehavior

{
get
{
return this.provider;
}
set
{
this.provider = value;
}
}
}
This service must have an HTTP address and server authentication certificate of which the root certification
authority is one of the following:
CNNIC
Comodo
CyberTrust
DigiCert
GeoTrust
GlobalSign
Go Daddy
Verisign
WoSign
A server authentication certificate can be bound to a port on a Windows host using the network shell utility:
netsh http add sslcert ipport=0.0.0.0:443 certhash=0000000000003ed9cd0c315bbb6dc1c08da5e6 appid={00112233-4455-
6677-8899-AABBCCDDEEFF}
Here, the value provided for the certhash argument is the thumbprint of the certificate, while the value provided for
the appid argument is an arbitrary globally unique identifier.
To host the service within Internet Information Services, a developer would build a CLA code library assembly with
a class named Startup in the default namespace of the assembly. Here is a sample of such a class:
public class Startup

{
// Microsoft.SystemForCrossDomainIdentityManagement.IWebApplicationStarter,
// Microsoft.SystemForCrossDomainIdentityManagement.IMonitor and
// Microsoft.SystemForCrossDomainIdentityManagement.Service are all defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Service.dll.
Microsoft.SystemForCrossDomainIdentityManagement.IWebApplicationStarter starter;
public Startup()
{
Microsoft.SystemForCrossDomainIdentityManagement.IMonitor monitor =
new DevelopersMonitor();
Microsoft.SystemForCrossDomainIdentityManagement.IProvider provider =
new DevelopersProvider();
this.starter =
new Microsoft.SystemForCrossDomainIdentityManagement.WebApplicationStarter(
provider,
monitor);
}
public void Configuration(

Owin.IAppBuilder builder) // Defined in in Owin.dll.
{
this.starter.ConfigureApplication(builder);
}
}
Handling endpoint authentication

Requests from Azure Active Directory include an OAuth 2.0 bearer token. Any service receiving the request should
authenticate the issuer as being Azure Active Directory on behalf of the expected Azure Active Directory tenant, for
access to the Azure Active Directory Graph web service. In the token, the issuer is identified by an iss claim, like,
"iss":"https://sts.windows.net/cbb1a5ac-f33b-45fa-9bf5-f37db0fed422/". In this example, the base address of the
claim value, https://sts.windows.net, identifies Azure Active Directory as the issuer, while the relative address
segment, cbb1a5ac-f33b-45fa-9bf5-f37db0fed422, is a unique identifier of the Azure Active Directory tenant on
behalf of which the token was issued. If the token was issued for accessing the Azure Active Directory Graph web
service, then the identifier of that service, 00000002-0000-0000-c000-000000000000, should be in the value of
the token’s aud claim.
Developers using the CLA libraries provided by Microsoft for building a SCIM service can authenticate requests
from Azure Active Directory using the Microsoft.Owin.Security.ActiveDirectory package by following these steps:
1. In a provider, implement the
Microsoft.SystemForCrossDomainIdentityManagement.IProvider.StartupBehavior property by having it
return a method to be called whenever the service is started:
public override Action\<Owin.IAppBuilder, System.Web.Http.HttpConfiguration.HttpConfiguration\>
StartupBehavior
{
get
{
return this.OnServiceStartup;
}
}
private void OnServiceStartup(

Owin.IAppBuilder applicationBuilder, // Defined in Owin.dll.
System.Web.Http.HttpConfiguration configuration) // Defined in System.Web.Http.dll.
{
}
2. Add the following code to that method to have any request to any of the service’s endpoints authenticated
as bearing a token issued by Azure Active Directory on behalf of a specified tenant, for access to the Azure
AD Graph web service:
private void OnServiceStartup(

Owin.IAppBuilder applicationBuilder IAppBuilder applicationBuilder,
System.Web.Http.HttpConfiguration HttpConfiguration configuration)
{
// IFilter is defined in System.Web.Http.dll.
System.Web.Http.Filters.IFilter authorizationFilter =
new System.Web.Http.AuthorizeAttribute(); // Defined in
System.Web.Http.dll.configuration.Filters.Add(authorizationFilter);
// SystemIdentityModel.Tokens.TokenValidationParameters is defined in
// System.IdentityModel.Token.Jwt.dll.
SystemIdentityModel.Tokens.TokenValidationParameters tokenValidationParameters =
new TokenValidationParameters()
{
ValidAudience = "00000002-0000-0000-c000-000000000000"
};
// WindowsAzureActiveDirectoryBearerAuthenticationOptions is defined in
// Microsoft.Owin.Security.ActiveDirectory.dll
Microsoft.Owin.Security.ActiveDirectory.
WindowsAzureActiveDirectoryBearerAuthenticationOptions authenticationOptions =
new WindowsAzureActiveDirectoryBearerAuthenticationOptions() {
TokenValidationParameters = tokenValidationParameters,
Tenant = "03F9FCBC-EA7B-46C2-8466-F81917F3C15E" // Substitute the appropriate tenant’s
// identifier for this one.
};
applicationBuilder.UseWindowsAzureActiveDirectoryBearerAuthentication(authenticationOptions);
}
User and group schema

Azure Active Directory can provision two types of resources to SCIM web services. Those types of resources are
users and groups.
User resources are identified by the schema identifier, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User,
which is included in this protocol specification: http://tools.ietf.org/html/draft-ietf-scim-core-schema. The default
mapping of the attributes of users in Azure Active Directory to the attributes of
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User resources is provided in table 1, below.
Group resources are identified by the schema identifier,
http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/Group. Table 2, below, shows the default
mapping of the attributes of groups in Azure Active Directory to the attributes of
http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/Group resources.
Table 1: Default user attribute mapping
URN:IETF:PARAMS:SCIM:SCHEMAS:EXTENSION:ENTERPRISE:2.0:USE
AZURE ACTIVE DIRECTORY USER R
IsSoftDeleted active
displayName displayName
Facsimile-TelephoneNumber phoneNumbers[type eq "fax"].value
givenName name.givenName
jobTitle title
mail emails[type eq "work"].value
mailNickname externalId
manager manager
mobile phoneNumbers[type eq "mobile"].value
objectId id
postalCode addresses[type eq "work"].postalCode
proxy-Addresses emails[type eq "other"].Value
physical-Delivery-OfficeName addresses[type eq "other"].Formatted
streetAddress addresses[type eq "work"].streetAddress
surname name.familyName
telephone-Number phoneNumbers[type eq "work"].value
user-PrincipalName userName
Table 2: Default group attribute mapping

HTTP://SCHEMAS.MICROSOFT.COM/2006/11/RESOURCEMANAGEM
AZURE ACTIVE DIRECTORY GROUP ENT/ADSCIM/GROUP
displayName externalId
mail emails[type eq "work"].value
mailNickname displayName
members members
HTTP://SCHEMAS.MICROSOFT.COM/2006/11/RESOURCEMANAGEM
AZURE ACTIVE DIRECTORY GROUP ENT/ADSCIM/GROUP
objectId id
proxyAddresses emails[type eq "other"].Value
User provisioning and de-provisioning

The following illustration shows the messages that Azure Active Directory sends to a SCIM service to manage the
lifecycle of a user in another identity store. The diagram also shows how a SCIM service implemented using the CLI
libraries provided by Microsoft for building such services translate those requests into calls to the methods of a
provider.
Figure 5: User provisioning and de-provisioning sequence

1. Azure Active Directory queries the service for a user with an externalId attribute value matching the
mailNickname attribute value of a user in Azure AD. The query is expressed as a Hypertext Transfer Protocol
(HTTP) request such as this example, wherein jyoung is a sample of a mailNickname of a user in Azure Active
Directory:
GET https://.../scim/Users?filter=externalId eq jyoung HTTP/1.1

Authorization: Bearer ...
If the service was built using the Common Language Infrastructure libraries provided by Microsoft for
implementing SCIM services, then the request is translated into a call to the Query method of the service’s
provider. Here is the signature of that method:
// System.Threading.Tasks.Tasks is defined in mscorlib.dll.
// Microsoft.SystemForCrossDomainIdentityManagement.Resource is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Schemas.
// Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource[]> Query(
Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters parameters,
string correlationIdentifier);
Here is the definition of the Microsoft.SystemForCrossDomainIdentityManagement.IQueryParameters

interface:
public interface IQueryParameters:

Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters
{
System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.IFilter> AlternateFilters
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IRetrievalParameters

{
system.Collections.Generic.IReadOnlyCollection<string> ExcludedAttributePaths
{ get; }
System.Collections.Generic.IReadOnlyCollection<string> RequestedAttributePaths
{ get; }
string SchemaIdentifier
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IFilter

{
Microsoft.SystemForCrossDomainIdentityManagement.IFilter AdditionalFilter
{ get; set; }
string AttributePath
{ get; }
Microsoft.SystemForCrossDomainIdentityManagement.ComparisonOperator FilterOperator
{ get; }
string ComparisonValue
{ get; }
}
public enum Microsoft.SystemForCrossDomainIdentityManagement.ComparisonOperator

{
Equals
}
In the following sample of a query for a user with a given value for the externalId attribute, values of the
arguments passed to the Query method are:
parameters.AlternateFilters.Count: 1
parameters.AlternateFilters.ElementAt(0).AttributePath: "externalId"
parameters.AlternateFilters.ElementAt(0).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(0).ComparisonValue: "jyoung"
correlationIdentifier: System.Net.Http.HttpRequestMessage.GetOwinEnvironment["owin.RequestId"]
2. If the response to a query to the web service for a user with an externalId attribute value that matches the
mailNickname attribute value of a user does not return any users, then Azure Active Directory requests that
the service provision a user corresponding to the one in Azure Active Directory. Here is an example of such a
request:
POST https://.../scim/Users HTTP/1.1
Content-type: application/json
{
"schemas":
[
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0User"],
"externalId":"jyoung",
"userName":"jyoung",
"active":true,
"addresses":null,
"displayName":"Joy Young",
"emails": [
{
"type":"work",
"value":"jyoung@Contoso.com",
"primary":true}],
"meta": {
"resourceType":"User"},
"name":{
"familyName":"Young",
"givenName":"Joy"},
"phoneNumbers":null,
"preferredLanguage":null,
"title":null,
"department":null,
"manager":null}
The Common Language Infrastructure libraries provided by Microsoft for implementing SCIM services
would translate that request into a call to the Create method of the service’s provider. The Create method
has this signature:

// Microsoft.SystemForCrossDomainIdentityManagement.Resource is defined in
// Microsoft.SystemForCrossDomainIdentityManagement.Schemas.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource> Create(
Microsoft.SystemForCrossDomainIdentityManagement.Resource resource,
In a request to provision a user, the value of the resource argument is an instance of the
Microsoft.SystemForCrossDomainIdentityManagement. Core2EnterpriseUser class, defined in the
Microsoft.SystemForCrossDomainIdentityManagement.Schemas library. If the request to provision the user
succeeds, then the implementation of the method is expected to return an instance of the
Microsoft.SystemForCrossDomainIdentityManagement. Core2EnterpriseUser class, with the value of the
Identifier property set to the unique identifier of the newly provisioned user.
3. To update a user known to exist in an identity store fronted by an SCIM, Azure Active Directory proceeds by
requesting the current state of that user from the service with a request such as:
GET ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

In a service built using the Common Language Infrastructure libraries provided by Microsoft for
implementing SCIM services, the request is translated into a call to the Retrieve method of the service’s
provider. Here is the signature of the Retrieve method:
// Microsoft.SystemForCrossDomainIdentityManagement.Resource and
// Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters
// are defined in Microsoft.SystemForCrossDomainIdentityManagement.Schemas.
System.Threading.Tasks.Task<Microsoft.SystemForCrossDomainIdentityManagement.Resource>
Retrieve(
Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters
parameters,
public interface
Microsoft.SystemForCrossDomainIdentityManagement.IResourceRetrievalParameters:
IRetrievalParameters
{
Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier
ResourceIdentifier
{ get; }
}
public interface Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier
{
string Identifier
{ get; set; }
string Microsoft.SystemForCrossDomainIdentityManagement.SchemaIdentifier
{ get; set; }
}
In the example of a request to retrieve the current state of a user, the values of the properties of the object
provided as the value of the parameters argument are as follows:
Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
4. If a reference attribute is to be updated, then Azure Active Directory queries the service to determine
whether or not the current value of the reference attribute in the identity store fronted by the service already
matches the value of that attribute in Azure Active Directory. For users, the only attribute of which the
current value is queried in this way is the manager attribute. Here is an example of a request to determine
whether the manager attribute of a particular user object currently has a certain value:
GET ~/scim/Users?filter=id eq 54D382A4-2050-4C03-94D1-E769F1D15682 and manager eq 2819c223-7f76-453a-

919d-413861904646&attributes=id HTTP/1.1
The value of the attributes query parameter, id, signifies that if a user object exists that satisfies the
expression provided as the value of the filter query parameter, then the service is expected to respond with a
urn:ietf:params:scim:schemas:core:2.0:User or urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
resource, including only the value of that resource’s id attribute. The value of the id attribute is known to the
requestor. It is included in the value of the filter query parameter; the purpose of asking for it is actually to
request a minimal representation of a resource that satisfying the filter expression as an indication of
whether or not any such object exists.
implementing SCIM services, then the request is translated into a call to the Query method of the service’s
provider. The value of the properties of the object provided as the value of the parameters argument are as
follows:
parameters.AlternateFilters.Count: 2
parameters.AlternateFilters.ElementAt(x).AttributePath: "id"
parameters.AlternateFilters.ElementAt(x).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(x).ComparisonValue: "54D382A4-2050-4C03-94D1-
E769F1D15682"
parameters.AlternateFilters.ElementAt(y).AttributePath: "manager"
parameters.AlternateFilters.ElementAt(y).ComparisonOperator: ComparisonOperator.Equals
parameters.AlternateFilter.ElementAt(y).ComparisonValue: "2819c223-7f76-453a-919d-413861904646"
parameters.RequestedAttributePaths.ElementAt(0): "id"
parameters.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
Here, the value of the index x may be 0 and the value of the index y may be 1, or the value of x may be 1 and
the value of y may be 0, depending on the order of the expressions of the filter query parameter.
5. Here is an example of a request from Azure Active Directory to an SCIM service to update a user:
PATCH ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

Content-type: application/json
{
"schemas":
[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":
[
{
"op":"Add",
"path":"manager",
"value":
[
{
"$ref":"http://.../scim/Users/2819c223-7f76-453a-919d-413861904646",
"value":"2819c223-7f76-453a-919d-413861904646"}]}]}
The Microsoft Common Language Infrastructure libraries for implementing SCIM services would translate
the request into a call to the Update method of the service’s provider. Here is the signature of the Update
method:
// System.Threading.Tasks.Tasks and
// System.Collections.Generic.IReadOnlyCollection<T>
// are defined in mscorlib.dll.
// Microsoft.SystemForCrossDomainIdentityManagement.IPatch,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase,
// Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier,
// Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation,
// Microsoft.SystemForCrossDomainIdentityManagement.OperationName,
// Microsoft.SystemForCrossDomainIdentityManagement.IPath and
// Microsoft.SystemForCrossDomainIdentityManagement.OperationValue
// are all defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Update(
Microsoft.SystemForCrossDomainIdentityManagement.IPatch patch,
public interface Microsoft.SystemForCrossDomainIdentityManagement.IPatch

{
Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase
PatchRequest
{ get; set; }
ResourceIdentifier
{ get; set; }
}
public class PatchRequest2:

Microsoft.SystemForCrossDomainIdentityManagement.PatchRequestBase
{
public System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation>
Operations
{ get;}
public void AddOperation(

Microsoft.SystemForCrossDomainIdentityManagement.PatchOperation operation);
}
public class PatchOperation

{
public Microsoft.SystemForCrossDomainIdentityManagement.OperationName
Name
{ get; set; }
public Microsoft.SystemForCrossDomainIdentityManagement.IPath
Path
{ get; set; }
public System.Collections.Generic.IReadOnlyCollection
<Microsoft.SystemForCrossDomainIdentityManagement.OperationValue> Value
{ get; }
public void AddValue(

Microsoft.SystemForCrossDomainIdentityManagement.OperationValue value);
}
public enum OperationName

{
Add,
Remove,
Replace
}
public interface IPath

{
string AttributePath { get; }
System.Collections.Generic.IReadOnlyCollection<IFilter> SubAttributes { get; }
Microsoft.SystemForCrossDomainIdentityManagement.IPath ValuePath { get; }
}
public class OperationValue

{
public string Reference
{ get; set; }
public string Value

{ get; set; }
}
In the example of a request to update a user, the object provided as the value of the patch argument has
these property values:
ResourceIdentifier.Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
ResourceIdentifier.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
(PatchRequest as PatchRequest2).Operations.Count: 1
(PatchRequest as PatchRequest2).Operations.ElementAt(0).OperationName: OperationName.Add
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Path.AttributePath: "manager"
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.Count: 1
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Reference:
http://.../scim/Users/2819c223-7f76-453a-919d-413861904646
(PatchRequest as PatchRequest2).Operations.ElementAt(0).Value.ElementAt(0).Value: 2819c223-7f76-
453a-919d-413861904646
6. To de-provision a user from an identity store fronted by an SCIM service, Azure AD sends a request such as:
DELETE ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1

implementing SCIM services, then the request is translated into a call to the Delete method of the service’s
provider. That method has this signature:

// Microsoft.SystemForCrossDomainIdentityManagement.IResourceIdentifier,
// is defined in Microsoft.SystemForCrossDomainIdentityManagement.Protocol.
System.Threading.Tasks.Task Delete(
resourceIdentifier,
The object provided as the value of the resourceIdentifier argument has these property values in the
example of a request to de-provision a user:
ResourceIdentifier.Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
ResourceIdentifier.SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
Group provisioning and de-provisioning

The following illustration shows the messages that Azure AcD sends to a SCIM service to manage the lifecycle of a
group in another identity store. Those messages differ from the messages pertaining to users in three ways:
The schema of a group resource is identified as
http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/Group.
Requests to retrieve groups stipulate that the members attribute is to be excluded from any resource provided
in response to the request.
Requests to determine whether a reference attribute has a certain value are requests about the members
attribute.
Figure 6: Group provisioning and de-provisioning sequence
Related articles
Automate User Provisioning/Deprovisioning to SaaS Apps
Customizing Attribute Mappings for User Provisioning
Writing Expressions for Attribute Mappings
Scoping Filters for User Provisioning
Account Provisioning Notifications
List of Tutorials on How to Integrate SaaS Apps
Troubleshoot Azure Active Directory Application
Management and Development
This article will help you to find helpful documents related to troubleshooting some of the most common issues
related to managing Enterprise Applications and developing new applications with the Application Registry.
Problems with Application Development

The following links will bring you to a content map which will help you to resolve some of the most common issues
with application development with the Application Registry in Azure Active Directory.
Problems with Application Configuration and Registration
Problems with Application Management

faced when managing Enterprise Applications in Azure Active Directory.
Problems with Application Configuration
Problems with Sign-in
Problems with Provisioning
Problems Managing Access
Problems with the Access Panel
Problems with the Application Proxy
Problems with Conditional Access
Development
with application development with the Application Registry in Azure Active Directory.
Problems with Application Configuration and Registration
Problems configuring or registering my application
I don't know how to configure my application

The following documents can help you to resolve some of the most common issues in this category.
I don’t know what the authentication endpoints are for my application
I don't know how to configure single sign-on to my application
I don't know how to fill out a specific field on the application object
I don't know how to create and configure a multi-tenant application

I don’t know how to set up a multi-tenant application
I don't know how to add my multi-tenant application to the Azure AD application gallery
I don't know how to select or manage permissions for my application

I don't know which permissions to select for a given API
I'm having a problem using or finding a specific API

I can't find the API I need to use for my application
I don't know how to change the token lifetime defaults for my application
I am confused about how application consent works
I don't know how to grant permissions to my application
I don't understand the difference between delegated and application permissions
Problems developing my application
I don't know how to configure my application

I don't know how to change the token lifetime defaults for my application
I don't know how to select or manage permissions for my application

I am confused about how application consent works
I don't know how to grant permissions to my application
I don't understand the difference between delegated and application permissions
Management
faced when managing Enterprise Applications in Azure Active Directory.
Problems with Application Configuration
Problems with Sign-in
Problems with Provisioning
Problems Managing Access
Problems with the Access Panel
Problems with the Application Proxy
Problems with Conditional Access
Problems adding or configuring applications
I don't know how to configure single sign-on to an application

I don't know how to configure federated single sign-on for a non-gallery application
I don't know how to configure federated single sign-on for an Azure AD Gallery application
I don't know how to configure password single sign-on for a non-gallery application
I don't know how to configure password single sign-on for an Azure AD Gallery application
I don't know how to determine what single-sign on method to use
I'm having a problem when adding an application

I don't know how to choose which application type to use when adding an application
I encountered a problem when adding a non-gallery application
I encountered a problem when adding an Azure AD Gallery application
I'm having a problem when configuring single sign-on for an

application
I encountered a problem when configuring federated single sign-on for a non-gallery application
I encountered a problem when configuring federated single sign-on for an Azure AD Gallery application
I encountered a problem when configuring password single sign-on for a non-gallery application
I encountered a problem when configuring password single sign-on for an Azure AD Gallery application
Problems when signing in to applications
I can complete Azure AD sign in, but I'm seeing a prompt that I don't
expect
A user sees an unexpected consent prompt when signing in to an application
A user sees an unexpected error when performing consent to an application
I'm having other problems signing in

I can sign in to an application directly, but I can't sign in to it from a deeplink on my custom portal
I can sign in to an application directly, but I can't sign in to it from the access panel
I'm having problems signing in to a specific application

I can complete Azure AD sign in, but afterwards I'm seeing an error on the application's sign in page
I can’t sign in to a non-gallery application configured for password single sign-on
I can’t sign in to an Azure AD Gallery application configured for password single sign-on
I can't sign in to a Microsoft application
I can't sign in to a non-gallery application configured for federated single sign-on
I can't sign in to an Azure AD Gallery application configured for federated single sign-on
I can't sign in to an custom-developed application
I can't sign in to an on-premises application using the Azure AD application proxy
Problems configuring and provisioning users to an
application
I want to know when provisioning will finish

I don't know how to find out when a specific user will be able to access an application
Provisioning to my Azure AD Gallery application is working, but the provisioning process is taking hours or
more
I'm having problems configuring user provisioning to an application

I don't know how to configure user provisioning to an Azure AD Gallery application
I encountered a problem when configuring user provisioning to an Azure AD Gallery application
I've set up provisioning to my Azure AD Gallery application, but no users are being provisioned
Provisioning to my Azure AD Gallery application is working, but the wrong set of users are being provisioned
Problems managing application access and
permissions
I'm having a problem assigning or removing users or groups to an

application
I don't know how to assign users and groups to an application
I want to remove a user's access to an application but I don't know how
I'm having a problem configuring self-service application access

I don't know how to configure self-service application assignment
I'm seeing an unexpected application or application assignment

I don't know how a user was assigned to an application
I see an unexpected application in my applications list and want to know more about it
Problems using the application access panel website
or mobile application
I do not see the applications I expect on the application access panel

I don't know why an application I assigned is not appearing on the access panel
I don't know why an application is appearing on the access panel
I'm having problems signing in to the application access panel

I cannot sign in to the access panel website
I'm having problems using the application access panel browser

extension
I saw an error when installing the application access panel browser extension
I'm having problems with a feature on the application access panel

I don't know how to use self-service application access
I encountered a problem when using self-service application access
Problems configuring the Azure AD Application Proxy
I can load my application, but something on the page looks broken

I can get to my application, but the application page isn't displaying correctly
I can get to my application, but the application takes too long to load
I can get to my application, but the links on the application page do not work
I'm having a connectivity problem my application

I don't know what ports to open for my application
I encountered a problem because there was no working connector in a connector group for my application
I'm having a problem configuring the Azure AD Application Proxy in

the admin portal
I am having difficulty configuring an application Proxy application
I don't know how to configure single sign-on to my application Proxy application
I encountered a problem when creating my application in admin portal
I'm having a problem setting up back-end authentication to my

application
I don't know how to configure Kerberos Constrained Delegation
I don't know how to configure my application with PingAccess
I'm having a problem when signing in to my application

I get a "Can't Access this Corporate Application" error
I'm having a problem with the Application Proxy Agent Connector

I am having issues installing the Application Proxy Agent Connector
Problems configuring conditional access to one of my
applications
I've set up conditional access, but something isn't working

The below documents can help you to resolve some of the most common issues in this category.
Conditional Access isn't working because customer did not meet Device Registration pre-reqs
Tenant is getting blocked due to incorrect setting of Conditional Access policies
I'm having problems setting up conditional access

The below documents can help you to resolve some of the most common issues in this category.
How and when do off corpnet rules take effect?
How to increase the number of devices that user is allowed to register in Azure AD?
How to set up Conditional Access for Exchange Online?
How to set up Conditional Access for Windows 7 devices?
Which applications are supported with conditional access?
Develop line-of-business apps for Azure Active
Directory
This guide provides an overview of developing line-of-business (LoB) applications for Azure Active Directory
(AD).The intended audience is Active Directory/Office 365 global administrators.
Overview
Building applications integrated with Azure AD gives users in your organization single sign-on with Office 365.
Having the application in Azure AD gives you control over the authentication policy for the application. To learn
more about conditional access and how to protect apps with multi-factor authentication (MFA) see Configuring
access rules.
Register your application to use Azure Active Directory. Registering the application means that your developers can
use Azure AD to authenticate users and request access to user resources such as email, calendar, and documents.
Any member of your directory (not guests) can register an application, otherwise known as creating an application
object.
Registering an application allows any user to do the following:
Get an identity for their application that Azure AD recognizes
Get one or more secrets/keys that the application can use to authenticate itself to AD
Brand the application in the Azure portal with a custom name, logo, etc.
Apply Azure AD authorization features to their app, including:
Role-Based Access Control (RBAC)
Azure Active Directory as oAuth authorization server (secure an API exposed by the application)
Declare required permissions necessary for the application to function as expected, including:
- App permissions (global administrators only). For example: Role membership in another Azure AD
application or role membership relative to an Azure Resource, Resource Group, or Subscription
- Delegated permissions (any user). For example: Azure AD, Sign-in, and Read Profile
NOTE
By default, any member can register an application. To learn how to restrict permissions for registering applications to specific
members, see How applications are added to Azure AD.
Here’s what you, the global administrator, need to do to help developers make their application ready for
production:
Configure access rules (access policy/MFA)
Configure the app to require user assignment and assign users
Suppress the default user consent experience
Configure access rules

Configure per-application access rules to your SaaS apps. For example, you can require MFA or only allow access
to users on trusted networks. The details for this are available in the document Configuring access rules.
Configure the app to require user assignment and assign users

By default, users can access applications without being assigned. However, if the application exposes roles or if you
want the application to appear on a user’s access panel, you should require user assignment.
Requiring user assignment
If you’re an Azure AD Premium or Enterprise Mobility Suite (EMS) subscriber, we strongly recommend using
groups. Assigning groups to the application allows you to delegate ongoing access management to the owner of
the group. You can create the group or ask the responsible party in your organization to create the group using
your group management facility.
Assigning users to an application
Assigning groups to an application
Suppress user consent

By default, each user goes through a consent experience to sign in. The consent experience, asking users to grant
permissions to an application, can be disconcerting for users who are unfamiliar with making such decisions.
For applications that you trust, you can simplify the user experience by consenting to the application on behalf of
your organization.
For more information about user consent and the consent experience in Azure, see Integrating Applications with
Azure Active Directory.
Related Articles
Enable secure remote access to on-premises applications with Azure AD Application Proxy
Azure Conditional Access Preview for SaaS Apps
Managing access to apps with Azure AD
Article Index for Application Management in
This page provides a comprehensive list of every document written about the various application-related
features in Azure Active Directory (Azure AD).
There is a brief introduction to each major feature area, as well as guidance on which articles to read
depending on what information you're looking for.
Overview Articles
The articles below are good starting points for those who simply want a brief explanation of Azure AD
application management features.
ARTICLE GUIDE
An introduction to the application management problems Managing Applications with Azure Active Directory (AD)
that Azure AD solves
An overview of the various features in Azure AD related to Application Access and Single Sign-on in Azure Active
enabling single sign-on, defining who has access to apps, Directory
and how users launch apps
A look at the different steps involved when integrating Integrating Azure Active Directory with Applications
apps into your Azure AD
Enabling Single Sign-On to SaaS Apps
Managing Access to Apps
A technical explanation of how apps are represented in How and Why Applications are Added to Azure AD
Azure AD
Troubleshooting Articles
This section provides quick access to relevant troubleshooting guides. More information about each feature
area can be found on the rest of this page.
FEATURE AREA
Federated Single Sign-On Troubleshooting SAML-Based Single Sign-On
Password-Based Single Sign-On Troubleshooting the Access Panel Extension for Internet
Explorer
Application Proxy App Proxy Troubleshooting Guide
Single sign-on between on-prem AD and Azure AD Troubleshooting Password Synchronization
Troubleshooting Password Writeback

FEATURE AREA
Dynamic Group Memberships Troubleshooting Dynamic Group Memberships
Single Sign-On (SSO)

Federated Single Sign-On: Sign into many apps using one identity
Single sign-on allows users to access a variety of apps and services using only one set of credentials.
Federation is one method through which you can enable single sign-on. When users attempt to sign into
federated apps, they will get redirected to their organization's official sign-in page rendered by Azure Active
Directory, and are then redirected back to the app upon successful authentication.
ARTICLE GUIDE
An introduction to federation and other types of sign-on Single Sign-On with Azure AD
Thousands of SaaS apps that are pre-integrated with Getting started with the Azure AD application gallery
Azure AD with simplified single sign-on configuration
steps Full List of Pre-Integrated Apps that Support Federation
How to Add Your App to the Azure AD App Gallery
More than 150 app tutorials on how to configure single List of Tutorials on How to Integrate SaaS Apps with
sign-on for apps such as Salesforce, ServiceNow, Google Azure Active Directory
Apps, Workday, and many more
How to manually set up and customize your single sign- How to Configure Federated Single Sign-On to Apps that
on configuration are not in the Azure Active Directory Application Gallery
How to Customize Claims Issued in the SAML Token for

Pre-Integrated Apps
Troubleshooting guide for federated apps that use the Troubleshooting SAML-Based Single Sign-On
SAML protocol
How to configure your app's certificate's expiration date, Managing Certificates for Federated Single Sign-On in
and how to renew your certificates Azure Active Directory
Federated single sign-on is available for all editions of Azure AD for up to ten apps per user. Azure AD
Premium supports unlimited applications. If your organization has Azure AD Basic or Azure AD Premium,
then you can use groups to assign access to federated applications.
Password-Based Single Sign-On: Account sharing and SSO for non-federated apps
To enable single sign-on to applications that don't support federation, Azure AD offers password
management features that can securely store passwords to SaaS apps and automatically sign users into
those apps. You can easily distribute credentials for newly created accounts and share team accounts with
multiple people. Users don't necessarily need to know the credentials to the accounts that they're given
access to.
ARTICLE GUIDE
An introduction to how password-based SSO works and a Password-Based Single Sign-On with Azure AD
brief technical overview
ARTICLE GUIDE
A summary of the scenarios related to account sharing Sharing accounts with Azure AD
and how these problems are solved by Azure AD
Automatically change the password for certain apps at a Automated Password Rollover (preview)
regular interval
Deployment and troubleshooting guides for the Internet How to Deploy the Access Panel Extension for Internet
Explorer version of the Azure AD password management Explorer using Group Policy
extension
Troubleshooting the Access Panel Extension for Internet
Explorer
Password-based single sign-on is available for all editions of Azure AD for up to ten apps per user. Azure
AD Premium supports unlimited applications. If your organization has Azure AD Basic or Azure AD
Premium, then you can use groups to assign access to applications. Automated password rollover is an
Azure AD Premium feature.
App Proxy: Single sign-on and remote access to on-premises applications
If you have applications in your private network that need to be accessed by users and devices outside the
network, then you can use Azure AD Application Proxy to enable secure, remote access to those apps.
ARTICLE GUIDE
Overview of Azure AD Application Proxy and how it works Providing secure remote access to on-premises
applications
Tutorials on how to configure Application Proxy and how How to Set Up Azure AD App Proxy
to publish your first app
How to Silently Install the App Proxy Connector
How to Publish Applications using App Proxy
How to Use your own Domain Name
How to enable single sign-on and conditional access for Single-sign-on with Application Proxy
apps published with App Proxy
Conditional Access and Application Proxy
Guidance on how to use Application Proxy for the How to Support Native Client Applications
following scenarios
How to Support Claims-Aware Applications
How to Support Applications Published on Separate

Networks and Locations
Troubleshooting guide for Application Proxy App Proxy Troubleshooting Guide
Application Proxy is available for all editions of Azure AD for up to ten apps per user. Azure AD Premium
supports unlimited applications. If your organization has Azure AD Basic or Azure AD Premium, then you
can use groups to assign access to applications.
You may also be interested in Azure AD Domain Services, which allows you to migrate your on-premises
applications to Azure while still satisfying the identity needs of those applications.
Enabling single sign-on between Azure AD and on-premises AD
If your organization maintains a Windows Server Active Directory on premises along with your Azure Active
Directory in the cloud, then you will likely want to enable single sign-on between these two systems. Azure
AD Connect (the tool that integrates these two systems together) provides multiple options for setting up
single sign-on: establish federation with ADFS or another federation provider, or enable password
synchronization.
ARTICLE GUIDE
An overview on the single sign-on options offered in User Sign On Options in Azure AD Connect
Azure AD Connect, as well as information on managing
hybrid environments
General guidance for managing environments with both Azure AD Hybrid Identity Design Considerations
on-premises Active Directory and Azure Active Directory
Integrating your On-Premises Identities with Azure Active
Directory
Guidance on using Password Sync to enable SSO Implement Password Synchronization with Azure AD
Connect
Troubleshoot Password Synchronization
Guidance on using Password Writeback to enable SSO Getting Started with Password Management in Azure AD
Troubleshoot Password Writeback
Guidance on using third party identity providers to enable List of Compatible Third-Party Identity Providers That Can
SSO Be Used to Enable Single Sign-On
How Windows 10 users can enjoy the benefits of single Extending Cloud Capabilities to Windows 10 Devices
sign-on via Azure AD Join through Azure Active Directory Join
Azure AD Connect is available for all editions of Azure Active Directory. Azure AD Self-Service Password
Reset is available for Azure AD Basic and Azure AD Premium. Password Writeback to on-prem AD is an
Azure AD Premium feature.
Conditional Access: Enforce additional security requirements for high-risk apps
Once you set up single sign-on to your apps and resources, you can then further secure sensitive
applications by enforcing specific security requirements on every sign-in to that app. For instance, you can
use Azure AD to demand that all access to a particular app always require multi-factor authentication,
regardless of whether or not that app innately supports that functionality. Another common example of
conditional access is to require that users be connected to the organization's trusted network in order to
access a particularly sensitive application.
ARTICLE GUIDE
An introduction to the conditional access capabilities Managing Risk With Conditional Access
offered across Azure AD, Office365, and Intune
ARTICLE GUIDE
How to enable conditional access for the following types Conditional Access for SaaS Apps
of resources
Conditional Access for Office 365 services
Conditional Access for On-Premises Applications
Conditional Access for On-Premises Applications

Published via Azure AD App Proxy
How to register devices with Azure Active Directory in Overview of Azure Active Directory Device Registration
order to enable device-based conditional access policies
How to Enable Automatic Device Registration for Domain
Joined Windows Devices
— Steps for Windows 8.1 devices
— Steps for Windows 7 devices
| How to use the Microsoft Authenticator app for two-step verification |Microsoft Authenticator |
Conditional Access is an Azure AD Premium feature.
Apps & Azure AD

Cloud App Discovery: Find which SaaS apps are being used in your organization
Cloud App Discovery helps IT departments learn which SaaS apps are being used throughout the
organization. It can measure app usage and popularity so that IT can determine which apps will benefit the
most from being brought under IT control and being integrated with Azure AD.
ARTICLE GUIDE
A general overview of how it works Finding unsanctioned cloud applications with Cloud App
Discovery
A deeper dive into how it works, with answers to Security and Privacy Considerations
questions on privacy
Frequently Asked Questions FAQ for Cloud App Discovery
Tutorials for deploying Cloud App Discovery Group Policy Deployment Guide
System Center Deployment Guide
Installing on Proxy Servers with Custom Ports
The change log for updates to the Cloud App Discovery Change log
agent
Cloud App Discovery is an Azure AD Premium feature.

Automatically provision and deprovision user accounts in SaaS apps
Automate the creation, maintenance, and removal of user identities in SaaS applications such as Dropbox,
Salesforce, ServiceNow, and more. Match and sync existing identities between Azure AD and your SaaS
apps, and control access by automatically disabling accounts when users leave the organization.
ARTICLE GUIDE
Learn about how it works and find answers to common Automate User Provisioning & Deprovisioning to SaaS
questions Apps
Configure how information is mapped between Azure AD Customizing Attribute Mappings

and your SaaS app
Writing Expressions for Attribute Mappings
How to enable automated provisioning to any app that Set up Automated User Provisioning to any SCIM-Enabled
supports the SCIM protocol App
How to report on and troubleshoot user provisioning Reporting on automatic user provisioning
Provisioning notifications
Troubleshooting user provisioning
Limit who gets provisioned to an application based on Scoping Filters

their attribute values
Automated user provisioning is available for all editions of Azure AD for up to ten apps per user. Azure AD
Premium supports unlimited applications. If your organization has Azure AD Basic or Azure AD Premium,
then you can use groups to manage which users get provisioned.
Building applications that integrate with Azure AD
If your organization is developing or maintaining line-of-business (LoB) applications, or if you're an app
developer with customers who use Azure Active Directory, the following tutorials will help you integrate
your applications with Azure AD.
ARTICLE GUIDE
Guidance for both IT professionals and application The IT Pro's Guide for Developing Applications for Azure
developers on integrating apps with Azure AD AD
The Developer's Guide for Azure Active Directory
How to application vendors can add their apps to the Listing your Application in the Azure Active Directory
Azure AD App Gallery Application Gallery
How to manage access to developed applications using How to Enable User Assignment for Developed
Azure Active Directory Applications
Assigning Users to your App
Assigning Group to your App
If you're developing consumer-facing applications, you may be interested in using Azure Active Directory
B2C so that you don't have to develop your own identity system to manage your users. Learn more.
Managing Access to Applications

Using groups and self-service to manage who has access to which apps
To help you manage who should have access to which resources, Azure Active Directory allows you to set
assignments and permissions at scale using groups. IT may choose to enable self-service features so that
users can simply request permission when they need it.
ARTICLE GUIDE
An overview of Azure AD access management features Introduction to Managing Access to Apps
How Access Management Works in Azure AD
How to Use Groups to Manage Access to SaaS

Applications
Enable self-service management of apps and groups Self-Service Application Management
Self-Service Group Management
Instructions for setting up your groups in Azure AD How to Create Security Groups
How to Designate Owners for a Group
How to Use the "All Users" Group
Use dynamic groups to automatically populate group Dynamic Group Membership: Advanced Rules
membership using attribute-based membership rules
Troubleshooting Dynamic Group Memberships
Group-based application access management is available for Azure AD Basic and Azure AD Premium. Self-
service group management, self-service application management, and dynamic groups are Azure AD
Premium features.
B2B Collaboration: Enable partner access to applications
If your business has partnered with other companies, it's likely that you need to manage partner access to
your corporate applications. Azure Active Directory B2B Collaboration provides an easy and secure way to
share your apps with partners.
ARTICLE GUIDE
An overview of different Azure AD features that can help Comparing Capabilities for Managing External Identities in
you manage external users such as partners, customers, Azure AD
etc.
An introduction to B2B Collaboration and how to get Simple, Secure, Cloud Partner Integration with Azure AD
started
Azure Active Directory B2B Collaboration
A deeper dive into Azure AD B2B Collaboration and how B2B Collaboration: How it works
to use it
Current Limitations of Azure AD B2B Collaboration
Detailed walkthrough of using Azure AD B2B

Collaboration
Reference articles with technical details on how Azure AD CSV File Format for Adding Partner Users
B2B Collaboration works
User Attributes Affected by Azure AD B2B Collaboration
User Token Format for Partner Users
B2B Collaboration is currently available for all editions of Azure Active Directory.
Access Panel: A portal for accessing apps and self-service features
The Azure AD Access Panel is where end-users can launch their apps and access the self-service features
that allow them to manage their apps and group memberships. In addition to the Access Panel, other
options for accessing SSO-enabled apps are included in the list below.
ARTICLE GUIDE
A comparison of the different options available for Deploying Azure AD Integrated Applications to Users
deploying single sign-on apps to users
An overview of the Access Panel and its mobile equivalent Introduction to Access Panel and MyApps
MyApps — iOS
— Android
How to access Azure AD apps from the Office 365 website Using the Office 365 App Launcher
How to access Azure AD apps from the Intune Managed Intune Managed Browser
Browser mobile app — iOS
— Android
How to access Azure AD apps using deep links to initiate Getting Direct Sign-On Links to Your Apps
single sign-on
Access Panel is available for all editions of Azure Active Directory.

Reports: Easily audit app access changes and monitor sign-ins to apps
Azure Active Directory provides several reports and alerts to help you monitor your organization's access to
applications. You can receive alerts for anomalous sign-ins to your apps, and you can track when and why a
users' access to an application has changed.
ARTICLE GUIDE
An overview of the reporting features in Azure Active Getting Started with Azure AD Reporting
Directory
How to monitor the sign-ins and app-usage of your users View Your Access and Usage Reports
Track changes made to who can access a particular Azure Active Directory Audit Report Events
application
Export the data of these reports to your preferred tools Getting Started with the Azure AD Reporting API
using the Reporting API
To see which reports are included with different editions of Azure Active Directory, click here.
See also
Azure Active Directory B2C
Azure Active Directory Domain Services
Integrate your on-premises directories with Azure
Active Directory
Azure AD Connect will integrate your on-premises directories with Azure Active Directory. This allows you to
provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure AD.
This topic will guide you through the planning, deployment, and operation steps. It is a collection of links to the
topics related to this area.
IMPORTANT
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great time
to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these tools are
now deprecated are no longer supported as of April 13, 2017.
Why use Azure AD Connect

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common
identity for accessing both cloud and on-premises resources. Users and organizations can take advantage of the
following:
Users can use a single identity to access on-premises applications and cloud services such as Office 365.
Single tool to provide an easy deployment experience for synchronization and sign-in.
Provides the newest capabilities for your scenarios. Azure AD Connect replaces older versions of identity
integration tools such as DirSync and Azure AD Sync. For more information, see Hybrid Identity directory
integration tools comparison.
How Azure AD Connect works
Azure Active Directory Connect is made up of three primary components: the synchronization services, the optional
Active Directory Federation Services component, and the monitoring component named Azure AD Connect Health.
AD FS - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid environment
using an on-premises AD FS infrastructure. This can be used by organizations to address complex deployments,
such as domain join SSO, enforcement of AD sign-in policy, and smart card or 3rd party MFA.
the Azure portal to view this activity. For additional information, see Azure Active Directory Connect Health.

You can find the download for Azure AD Connect on Microsoft Download Center.
SOLUTION SCENARIO
Before you start - Hardware and prerequisites Steps to complete before you start to install Azure AD
Connect.
Express settings If you have a single forest AD then this is the recommended
option to use.
User sign in with the same password using password
synchronization.
Customized settings Used when you have multiple forests. Supports many on-
premises topologies.
Customize your sign-in option, such as ADFS for federation
or use a 3rd party identity provider.
Customize synchronization features, such as filtering and
writeback.
Upgrade from DirSync Used when you have an existing DirSync server already
running.
Upgrade from Azure AD Sync or Azure AD Connect There are several different methods depending on your
preference.
After installation you should verify it is working as expected and assign licenses to the users.
Next steps to Install Azure AD Connect
TOPIC LINK
Download Azure AD Connect Download Azure AD Connect
Install using Express settings Express installation of Azure AD Connect
Install using Customized settings Custom installation of Azure AD Connect
Upgrade from DirSync Upgrade from Azure AD sync tool (DirSync)
After installation Verify the installation and assign licenses
Learn more about Install Azure AD Connect

You also want to prepare for operational concerns. You might want to have a stand-by server so you easily can fall
over if there is a disaster. If you plan to make frequent configuration changes, you should plan for a staging mode
server.
TOPIC LINK
Supported topologies Topologies for Azure AD Connect
Design concepts Azure AD Connect design concepts
Accounts used for installation More about Azure AD Connect credentials and permissions
Operational planning Azure AD Connect sync: Operational tasks and considerations
User sign-in options Azure AD Connect User sign-in options
Configure sync features

Azure AD Connect comes with several features you can optionally turn on or are enabled by default. Some features
might sometimes require more configuration in certain scenarios and topologies.
Filtering is used when you want to limit which objects are synchronized to Azure AD. By default all users, contacts,
groups, and Windows 10 computers are synchronized. You can change the filtering based on domains, OUs, or
attributes.
Password synchronization synchronizes the password hash in Active Directory to Azure AD. The end-user can use
the same password on-premises and in the cloud but only manage it in one location. Since it uses your on-premises
Active Directory as the authority, you can also use your own password policy.
Password writeback will allow your users to change and reset their passwords in the cloud and have your on-
premises password policy applied.
Device writeback will allow a device registered in Azure AD to be written back to on-premises Active Directory so it
can be used for conditional access.
The prevent accidental deletes feature is turned on by default and protects your cloud directory from numerous
deletes at the same time. By default it allows 500 deletes per run. You can change this setting depending on your
organization size.
Automatic upgrade is enabled by default for express settings installations and ensures your Azure AD Connect is
always up to date with the latest release.
Next steps to configure sync features
TOPIC LINK
Configure filtering Azure AD Connect sync: Configure filtering
Password synchronization Azure AD Connect sync: Implement password synchronization
Password writeback Getting started with password management
Device writeback Enabling device writeback in Azure AD Connect
Prevent accidental deletes Azure AD Connect sync: Prevent accidental deletes
Automatic upgrade Azure AD Connect: Automatic upgrade
Customize Azure AD Connect sync

Azure AD Connect sync comes with a default configuration that is intended to work for most customers and
topologies. But there are always situations where the default configuration does not work and must be adjusted. It
is supported to make changes as documented in this section and linked topics.
If you have not worked with a synchronization topology before you want to start to understand the basics and the
terms used as described in the technical concepts. Azure AD Connect is the evolution of MIIS2003, ILM2007, and
FIM2010. Even if some things are identical, a lot has changed as well.
The default configuration assumes there might be more than one forest in the configuration. In those topologies a
user object might be represented as a contact in another forest. The user might also have a linked mailbox in
another resource forest. The behavior of the default configuration is described in users and contacts.
The configuration model in sync is called declarative provisioning. The advanced attribute flows are using functions
to express attribute transformations. You can see and examine the entire configuration using tools which comes
with Azure AD Connect. If you need to make configuration changes, make sure you follow the best practices so it is
easier to adopt new releases.
Next steps to customize Azure AD Connect sync
TOPIC LINK
All Azure AD Connect sync articles Azure AD Connect sync
Technical concepts Azure AD Connect sync: Technical Concepts
Understanding the default configuration Azure AD Connect sync: Understanding the default
configuration
Understanding users and contacts Azure AD Connect sync: Understanding Users and Contacts
Declarative provisioning Azure AD Connect Sync: Understanding Declarative

Provisioning Expressions
Change the default configuration Best practices for changing the default configuration
Configure federation features
Azure AD Connect provides several features that simplify federating with Azure AD using AD FS and managing your
federation trust. Azure AD Connect supports AD FS on Windows Server 2012R2 or later.
Update SSL certificate of AD FS farm even if you are not using Azure AD Connect to manage your federation trust.
Add an AD FS server to your farm to expand the farm as required.
Repair the trust with Azure AD in a few simple clicks.
ADFS can be configured to support multiple domains. For example you might have multiple top domains you need
to use for federation.
if your ADFS server has not been configured to automatically update certificates from Azure AD or if you use a non-
ADFS solution, then you will be notified when you have to update certificates.
Next steps to configure federation features
TOPIC LINK
All AD FS articles Azure AD Connect and federation
Configure ADFS with subdomains Multiple Domain Support for Federating with Azure AD
Manage AD FS farm AD FS management and customization with Azure AD

Connect
Manually updating federation certificates Renewing Federation Certificates for Office 365 and Azure AD
More information and references

TOPIC LINK
Version history Version history
Compare DirSync, Azure ADSync, and Azure AD Connect Directory integration tools comparison
Non-ADFS compatibility list for Azure AD Azure AD federation compatibility list
Configuring a SAML 2.0 Idp Using a SAML 2.0 Identity Provider (IdP) for Single Sign On
Attributes synchronized Attributes synchronized
Monitoring using Azure AD Connect Health Azure AD Connect Health
Frequently Asked Questions Azure AD Connect FAQ
Ignite 2015 presentation on extending your on-premises directories to the cloud.
Quickstart: Add a custom domain name to Azure
Active Directory
initial domain name cannot be changed or deleted, but you can add your corporate domain name to Azure AD as
well. For example, your organization probably has other domain names used to do business and users who sign
in using your corporate domain name. Adding custom domain names to Azure AD allows you to assign user
names in the directory that are familiar to your users, such as ‘alice@contoso.com.’ instead of 'alice@domain
name.onmicrosoft.com'. The process is simple:
Add the custom domain name to your directory

2. On the left, select Custom domain names.
3. Select Add custom domain.
4. On Custom domain names, enter the name of your custom domain in the box, such as 'contoso.com', and
then select Add Domain. Be sure to include the .com, .net, or other top-level extension.
5. On domainname (that is, your new domain name is the title), gather the DNS entry information to use
later to verify the custom domain name in Azure AD.
TIP
If you plan to federate your on-premises Windows Server AD with Azure AD, then you need to select the I plan to
configure this domain for single sign-on with my local Active Directory checkbox when you run the Azure AD
Connect tool to synchronize your directories. You also need to register the same domain name you select for federating
with your on-premises directory in the Azure AD Domain step in the wizard. You can see what that step in the wizard
looks like in these instructions. If you do not have the Azure AD Connect tool, you can download it here.
Add a DNS entry for the domain name at the domain name registrar
The next step to use your custom domain name with Azure AD is to update the DNS zone file for the domain.
Azure AD can then verify that your organization owns the custom domain name. You can use Azure DNS for your
Azure/Office 365/external DNS records within Azure, or add the DNS entry at a different DNS registrar.
1. Sign in to the domain name registrar for the domain. If you don't have access to update the DNS entry, ask the
person or team who has this access to complete step 2 and to let you know when it is completed.
2. Update the DNS zone file for the domain by adding the DNS entry provided to you by Azure AD. The DNS
entry doesn't change any behaviors such as mail routing or web hosting.
Verify the custom domain name in Azure AD

Once you have added the DNS entry, you are ready to verify the domain name with Azure AD. A domain name
can be verified only after the DNS records have propagated. This propagation often takes only seconds, but it can
sometimes take an hour or more. If verification doesn’t work the first time, try again later.
1. Sign in to Azure AD with an account that's a global admin for the tenant.
3. Select the unverified domain name that you want to verify.
4. Check your entries and select Verify to complete the verification.
Now you can assign user names that include your custom domain name. You can create cloud-based user
accounts, or update previously synchronized on-premises user account information, using your custom domain
name. You can also change synchronized user account domain suffix information using Microsoft PowerShell or
the Graph API.
TIP
You can add up to a maximum of 900 managed domain names. If you are configuring all of your domains for federation
on-premises with Active Directory, you can add up to a maximum of 450 domain names in each directory. For more
information, see Federated and managed domain names.
Troubleshooting
If you can't verify a custom domain name, try the following troubleshooting steps:
1. Wait an hour. DNS records must propagate before Azure AD can verify the domain. This process can take an
hour or more.
2. Ensure the DNS record was entered, and that it is correct. Complete this step at the website for the
domain name registrar for the domain. Azure AD can't verify the domain name if
The DNS entry is not present in the DNS zone file
It is not an exact match with the DNS entry that Azure AD provided you.
If you do not have access to update DNS records for the domain at the domain name registrar, share the
DNS entry with the person or team at your organization who has this access, and ask them to add the DNS
entry.
3. Delete the domain name from another directory in Azure AD. A domain name can be verified in only a
single directory. If a domain name is currently verified in a different directory, it can't be verified in your new
directory until it is deleted on the other one. To learn about deleting domain names, read Manage custom
domain names.
Repeat the steps in this article to add each of your domain names.
Learn more
Conceptual overview of custom domain names in Azure AD
Manage custom domain names
Next steps
In this quickstart, you’ve learned how to add a custom domain to Azure AD.
You can use the following link to add a new custom domain in Azure AD from the Azure portal.
Add a custom domain
Managing custom domain names in your Azure
Active Directory
A domain name is an important part of the identifier for many directory resources: it is part of a user name or
email address for a user, part of the address for a group, and can be part of the app ID URI for an application. A
resource in Azure Active Directory (Azure AD) can include a domain name that is already verified as owned by the
directory that contains the resource. Only a global administrator can perform domain management tasks in Azure
AD.
Set the primary domain name for your Azure AD directory

When your directory is created, the initial domain name, such as ‘contoso.onmicrosoft.com,’ is also the primary
domain name. The primary domain is the default domain name for a new user when you create a new user.
Setting a primary domain name streamlines the process for an administrator to create new users in the portal. To
change the primary domain name:
2. Select Azure Active Directory.
4. Select the name of the domain that you want to be the primary domain.
5. Select the Make primary command. Confirm your choice when prompted.
You can change the primary domain name for your directory to be any verified custom domain that is not
federated. Changing the primary domain for your directory will not change the user names for any existing users.
Add custom domain names to your Azure AD tenant

You can add up to a maximum of 900 managed domain names. If you are configuring all your domains for
federation with on-premises Active Directory, you can add up to a maximum of 450 domain names in each
directory. For more information, see Federated and managed domain names.
Add subdomains of a custom domain

If you want to add a third-level domain name such as ‘europe.contoso.com’ to your directory, you should first add
and verify the second-level domain, such as contoso.com. The subdomain will be automatically verified by Azure
AD. To see that the subdomain that you just added has been verified, refresh the page in the browser that lists the
domains.
What to do if you change the DNS registrar for your custom domain
name
If you change the DNS registrar for your custom domain name, you can continue to use your custom domain
name with Azure AD itself without interruption and without additional configuration tasks. If you use your custom
domain name with Office 365, Intune, or other services that rely on custom domain names in Azure AD, refer to
the documentation for those services.
Delete a custom domain name

You can delete a custom domain name from your Azure AD if your organization no longer uses that domain
name, or if you need to use that domain name with another Azure AD.
To delete a custom domain name, you must first ensure that no resources in your directory rely on the domain
name. You can't delete a domain name from your directory if:
Any user has a user name, email address, or proxy address that includes the domain name.
Any group has an email address or proxy address that includes the domain name.
Any application in your Azure AD has an app ID URI that includes the domain name.
You must change or delete any such resource in your Azure AD directory before you can delete the custom
domain name.
Use PowerShell or Graph API to manage domain names

Most management tasks for domain names in Azure Active Directory can also be completed using Microsoft
PowerShell, or programmatically using Azure AD Graph API.
Using PowerShell to manage domain names in Azure AD
Using Graph API to manage domain names in Azure AD
Next steps
Add custom domain names
Manage your Azure AD directory
What is an Azure AD tenant?

In Azure Active Directory (Azure AD), a tenant is a dedicated instance of an Azure AD directory that your
organization receives when it signs up for a Microsoft cloud service such as Azure or Office 365. Each Azure AD
directory is distinct and separate from other Azure AD directories. Just like a corporate office building is a secure
asset specific to only your organization, an Azure AD directory was also designed to be a secure asset for use by
only your organization. The Azure AD architecture isolates customer data and identity information so that users
and administrators of one Azure AD directory cannot accidentally or maliciously access data in another directory.
How can I get an Azure AD directory?

Azure AD provides the core directory and identity management capabilities behind most of Microsoft’s cloud
services, including:
Azure
Microsoft Office 365
Microsoft Dynamics CRM Online
Microsoft Intune
You get an Azure AD directory when you sign up for any of these Microsoft cloud services. You can create
additional directories as needed. For example, you might maintain your first directory as a production directory and
then create another directory for testing or staging.
Using the Azure AD directory that comes with a new Azure subscription
We recommend that you use the administrator account you used for your first service when you sign up for other
Microsoft services. The information that you provide the first time you sign up for a Microsoft service is used to
create a new Azure AD directory instance for your organization. If you use that directory to authenticate sign-in
attempts when you subscribe to other Microsoft services, they can use the existing user accounts, policies, settings,
or on-premises directory integration you configure in your default directory.
For example, if you sign up for a Microsoft Intune subscription and then further synchronize your on-premises
Active Directory with your Azure AD directory, you can sign up for another Microsoft service such as Office 365
and easily achieve the same directory integration benefits that you have with Microsoft Intune.
For more information about integrating your on-premises directory with Azure AD, see Directory integration with
Azure AD Connect.
Associate an existing Azure AD directory with a new Azure subscription
You can associate a new Azure subscription with the same directory that authenticates sign-in for an existing Office
365 or Microsoft Intune subscription. For more information on that scenario, see Transfer ownership of an Azure
subscription to another account
Create an Azure AD directory by signing up for a Microsoft cloud service as an organization
If you don’t yet have a subscription to a Microsoft cloud service, you can use one of the following links to sign up.
Signing up for your first service creates an Azure AD directory automatically.
Microsoft Azure
Office 365
Microsoft Intune
How to change the default directory for a subscription
1. Sign in to the Azure Account Center with an account that is the Account Administrator of the subscription to
transfer subscription ownership.
2. Ensure that the user who you want to be the subscription owner is in the targeted directory.
3. Click Transfer subscription.
4. Specify the recipient. The recipient automatically gets an email with an acceptance link.
5. The recipient clicks the link and follows the instructions, including entering their payment information. When
the recipient succeeds, the subscription is transferred.
6. The default directory of the subscription is changed to the directory that the user is in if the subscription
ownership transfer is successful.
To learn more, see Transfer Azure subscription ownership to another account
Manage the default directory in Azure
When you sign up for Azure, a default Azure AD directory is associated with your subscription. There are no costs
for using Azure AD and your directories are a free resource. There are paid Azure AD services that are licensed
separately and provide additional functionality such as company branding at sign-in, and self-service password
reset. You can also create a custom domain using a DNS name that you own instead of the default
*.onmicrosoft.com domain.
How can I manage directory data?

To administer one or more Microsoft cloud service subscriptions, you can use the Azure AD admin center, the
Microsoft Intune account portal, or the Office 365 Admin Center to manage your organization's directory data. You
can also use Azure Active Directory PowerShell cmdlets to help you manage data stored in Azure AD.
From any one of these portals (or cmdlets), you can:
Create and manage user and group accounts
Manage related cloud services for your organization's subscriptions
Set up on-premises integration with Azure AD identity and authentication services
The Azure AD admin center, Office 365 Admin Center, Microsoft Intune account portal, and the Azure AD cmdlets
all read from and write to a single shared instance of Azure AD that is associated with your organization’s directory.
Each of those tools acts as a front-end interface that pulls in or changes your directory data. When you change your
organization's data using any of the portals or cmdlets while signed in under the context of one of these services,
the changes are also shown in the other portals the next time you sign in. This data is shared across the Microsoft
cloud services to which you subscribe.
For example, if you use the Office 365 Admin Center to block a user from signing in, that action blocks the user
from signing in to any other service to which your organization is currently subscribed to. If you view the same
user account in the Microsoft Intune account portal, you also see that the user is blocked.
How can I add and manage multiple directories?

You can add an Azure AD directory in the Azure portal. Fill out the information and select Create.
You can manage each directory as a fully independent resource: 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 resource independence, administrative independence, and
synchronization independence.
Resource independence. If you create or delete a resource in one directory, it has no impact on any resource
in another directory, with the partial exception of external users. If you use a custom domain 'contoso.com' with
one directory, it cannot be used with any other directory.
Administrative independence. If a user who is not an administrator of directory 'Contoso' creates a test
directory 'Test,' then:
The administrators of directory 'Contoso' have no direct administrative privileges to directory 'Test'
unless an administrator of 'Test' specifically grants them these privileges. Administrators of 'Contoso'
can control access to directory 'Test' by virtue of their control of the user account that created 'Test.'
If you assign or remove an administrator role for a user in one directory, the change does not affect
any administrator role that user may have in another directory.
Synchronization independence. You can configure each Azure AD tenant independently to get data
synchronized from a single instance the Azure AD Connect directory synchronization tool.
Unlike other Azure resources, your 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 Azure AD PowerShell, the
Azure Graph API, or other interfaces such as the Office 365 Admin Center. You can also associate another
subscription with the directory.
How to prepare to delete an Azure AD directory

A global administrator can delete an Azure AD directory from the portal. When a directory is deleted, all resources
that are contained in the directory are also deleted. Verify that you don’t need the directory before you delete it.
NOTE
If the user is signed in with a work or school account, the user must not be attempting to delete their home directory. For
example, if the user is signed in as joe@contoso.onmicrosoft.com, that user cannot delete the directory that has
contoso.onmicrosoft.com as its default domain.
Azure AD requires that certain conditions are met to delete a directory. This reduces risk that deleting a directory
negatively impacts users or applications, such as the ability of users to sign in to Office 365 or access resources in
Azure. For example, if a directory for a subscription is unintentionally deleted, then users can't access the Azure
resources for that subscription.
The following conditions are checked:
The only user in the directory should be the global administrator who is to delete the directory. Any other users
must be deleted before the directory can be deleted. If users are synchronized from on-premises, then sync
must be turned off, and the users must be deleted in the cloud directory by using the Azure portal or Azure
PowerShell cmdlets. There is no requirement to delete groups or contacts, such as contacts added from the
Office 365 Admin Center.
There can be no applications in the directory. Any applications must be deleted before the directory can be
deleted.
No multi-factor authentication providers can be linked to the directory.
There can be no subscriptions for any Microsoft Online Services such as Microsoft Azure, Office 365, or Azure
AD Premium associated with the directory. For example, if a default directory was created for you in Azure, you
cannot delete this directory if your Azure subscription still relies on this directory for authentication. Similarly,
you can't delete a directory if another user has associated a subscription with it.
Next steps
Azure AD Forum
Azure Multi-Factor Authentication Forum
StackOverflow for Azure questions
Azure Active Directory PowerShell
Assigning administrator roles in Azure AD
Understand how multiple Azure Active Directory
tenants interact
In Azure Active Directory (Azure AD), each tenant is a fully independent resource: a peer that is logically
independent from the other tenants that you manage. There is no parent-child relationship between tenants. This
independence between tenants includes resource independence, administrative independence, and synchronization
independence.
Resource independence
If you create or delete a resource in one tenant, it has no impact on any resource in another tenant, with the
partial exception of external users.
If you use one of your domain names with one tenant, it cannot be used with any other tenant.
Administrative independence
If a non-administrative user of tenant 'Contoso' creates a test tenant 'Test,' then:
By default, the user who creates a tenant is added as an external user in that new tenant, and assigned the global
administrator role in that tenant.
The administrators of tenant 'Contoso' have no direct administrative privileges to tenant 'Test,' unless an
administrator of 'Test' specifically grants them these privileges. However, administrators of 'Contoso' can
control access to tenant 'Test' if they control the user account that created 'Test.'
If you add/remove an administrator role for a user in one tenant, the change does not affect the administrator
roles that the user has in another tenant.
Synchronization independence
You can configure each Azure AD tenant independently to get data synchronized from a single instance of either:
The Azure AD Connect tool, to synchronize data with a single AD forest.
The Azure Active tenant Connector for Forefront Identity Manager, to synchronize data with one or more on-
premises forests, and/or non-Azure AD data sources.
Add an Azure AD tenant

To add an Azure AD tenant in the Azure portal, sign in to the Azure portal with an account that is an Azure AD
global administrator, and, on the left, select New.
NOTE
Unlike other Azure resources, your tenants are not child resources of an Azure subscription. If your Azure subscription is
canceled or expired, you can still access your tenant data using Azure PowerShell, the Azure Graph API, or the Office 365
Admin Center. You can also associate another subscription with the tenant.
Next steps
For a broad overview of Azure AD licensing issues and best practices, see What is Azure Active tenant licensing?.
What is self-service signup for Azure Active
Directory?
This article explains self-service signup and how to support it in Azure Active Directory (Azure AD). If you want to
take over a domain name from an unmanaged Azure AD tenant, see Take over an unmanaged directory as
administrator.
Why use self-service signup?

Get customers to services they want faster
Create email-based offers for a service
Create email-based signup flows that quickly allow users to create identities using their easy-to-remember
work email aliases
A self-service-created Azure AD directory can be turned into a managed directory that can be used for other
services
Terms and definitions

Self-service signup: This is the method by which a user signs up for a cloud service and has an identity
automatically created for them in Azure AD based on their email domain.
Unmanaged Azure AD directory: This is the directory where that identity is created. An unmanaged directory
is a directory that has no global administrator.
Email-verified user: This is a type of user account in Azure AD. A user who has an identity created
automatically after signing up for a self-service offer is known as an email-verified user. An email-verified user
is a regular member of a directory tagged with creationmethod=EmailVerified.
How do I control self-service settings?

Admins have two self-service controls today. They can control whether:
Users can join the directory via email.
Users can license themselves for applications and services.
How can I control these capabilities?
An admin can configure these capabilities using the following Azure AD cmdlet Set-MsolCompanySettings
parameters:
AllowEmailVerifiedUsers controls whether a user can create or join an unmanaged directory. If you set that
parameter to $false, no email-verified users can join the directory.
AllowAdHocSubscriptions controls the ability for users to perform self-service signup. If you set that
parameter to $false, no users can perform self-service signup.
How do the controls work together?
These two parameters can be used in conjunction to define more precise control over self-service signup. For
example, the following command will allow users to perform self-service signup, but only if those users already
have an account in Azure AD (in other words, users who would need an email-verified account to be created first
cannot perform self-service signup):
Set-MsolCompanySettings -AllowEmailVerifiedUsers $false -AllowAdHocSubscriptions $true
The following flowchart explains the different combinations for these parameters and the resulting conditions for
the directory and self-service signup.
For more information and examples of how to use these parameters, see Set-MsolCompanySettings.
Next steps
Add a custom domain name to Azure AD
How to install and configure Azure PowerShell
Azure PowerShell
Azure Cmdlet Reference
Set-MsolCompanySettings
Take over an unmanaged directory as administrator
in Azure Active Directory
This article describes two ways to take over a DNS domain name in an unmanaged directory in Azure Active
Directory (Azure AD). When a self-service user signs up for a cloud service that uses Azure AD, they are added to an
unmanaged Azure AD directory based on their email domain. For more about self-service or "viral" signup for a
service, see
What is self -service signup f or Azure Active Dir ectory?
Decide how you want to take over an unmanaged directory

During the process of admin takeover, you can prove ownership as described in Add a custom domain name to
Azure AD. The next sections explain the admin experience in more detail, but here's a summary:
When you perform an "internal" admin takeover of an unmanaged Azure directory, you are added as the
global administrator of the unmanaged directory. No users, domains, or service plans are migrated to any
other directory you administer.
When you perform an "external" admin takeover of an unmanaged Azure directory, you add the DNS
domain name of the unmanaged directory to your managed Azure directory. When you add the domain
name, a mapping of users to resources is created in your managed Azure directory so that users can
continue to access services without interruption.
Internal admin takeover

Some products that include SharePoint and OneDrive, such as Office 365, do not support external takeover. If that
is your scenario, or if you are an admin and want to take over an unmanaged or "shadow" tenant create by users
who used self-service sign-up, you can do this with an internal admin takeover.
1. Create a user context in the unmanaged tenant through signing up with such as Power BI. For convenience
of example, these steps assume that path.
2. Open the Power BI site and select Start Free. Enter a user account that uses the domain name for the
organization; for example, admin@fourthcoffee.xyz . After you enter in the verification code, check your email
for the confirmation code.
3. In the confirmation email from Power BI, select Yes, that's me.
4. Sign in to the Office 365 Admin center with the Power BI user account. You receive a message that instructs
you to Become the Admin of the domain name that was already verified in the unmanaged tenant. select
Yes, I want to be the admin.
5. Add the TXT record to prove that you own the domain name fourthcoffee.xyz at your domain name
registrar. In this example, it is GoDaddy.com.
When the DNS TXT records are verified at your domain name registrar, you can manage the Azure AD tenant.
When you complete the preceding steps, you are now the global administrator of the Fourth Coffee tenant in Office
365. To integrate the domain name with your other Azure services, you can remove it from Office 365 and add it to
a different managed tenant in Azure.
Adding the domain name to a managed tenant in Azure AD
1. Open the Office 365 Admin center.
2. Select Users tab, and create a new user account with a name like user@fourthcoffeexyz.onmicrosoft.com that
does not use the custom domain name.
3. Ensure that the new user account has global admin privileges for the Azure AD tenant.
4. Open Domains tab in the Office 365 Admin center, select the domain name and select Remove.
5. If you have any users or groups in Office 365 that reference the removed domain name, they must be
renamed to the .onmicrosoft.com domain. If you force delete the domain name, all users are automatically
renamed, in this example to user@fourthcoffeexyz.onmicrosoft.com.
6. Sign in to the Azure AD admin center with an account that is the global admin for the Azure AD tenant.
7. Select Custom domain names, then add the domain name. You'll have to enter the DNS TXT records to
verify ownership of the domain name.
NOTE
Any users of Power BI or Azure Rights Management service who have licenses assigned in the Office 365 tenant must save
their dashboards if the domain name is removed. They must sign in with a user name like
user@fourthcoffeexyz.onmicrosoft.com rather than user@fourthcoffee.xyz.
External admin takeover

If you already manage a tenant with Azure services or Office 365, you are can't add a custom domain name if it is
already verified in another Azure AD tenant. However, from your managed tenant in Azure AD you can take over an
unmanaged tenant as an external admin takeover. The general procedure follows the article Add a custom domain
to Azure AD.
When you verify ownership of the domain name, Azure AD removes the domain name from the unmanaged
tenant and moves it to your existing tenant. External admin takeover of an unmanaged directory requires the same
DNS TXT validation process as internal admin takeover. The difference is that the following are also moved over
with the domain name:
Users
Subscriptions
License assignments
The ForceTakeover option for domain name external admin takeover is supported for only two services, Power BI
and Azure RMS.
Support for external admin takeover
External admin takeover is supported by the following online services:
Power BI
Azure Rights Management Service (RMS)
Exchange Online
The supported service plans include:
Power BI Free
Power BI Pro
PowerApps Free
PowerFlow Free
Azure Rights Management Service Basic (RMS)
Azure Rights Management Service Enterprise (RMS)
Microsoft Stream
Dynamics 365 free trial
Exernal admin takeover is not supported for any service that has service plans that include SharePoint, OneDrive,
or Skype For Business; for example, through an Office free subscription or the Office Basic SKU.
Azure AD PowerShell cmdlets for the ForceTakeover option
You can see these cmdlets used in PowerShell example.
CMDLET USAGE
connect-msolservice When prompted, sign in to your managed tenant.
get-msoldomain Shows your domain names associated with the current tenant.
new-msoldomain –name <domainname> Adds the domain name to tenant as Unverified (no DNS
verification has been performed yet).
get-msoldomain The domain name is now included in the list of domain names
associated with your managed tenant, but is listed as
Unverified.
get-msoldomainverificationdns –Domainname Provides the information to put into new DNS TXT record for
<domainname> –Mode DnsTxtRecord the domain (MS=xxxxx). Verification might not happen
immediately because it takes some time for the TXT record to
propagate, so wait a few minutes before considering the -
ForceTakeover option.
confirm-msoldomain –Domainname <domainname> – If your domain name is still not verified, you can proceed
ForceTakeover Force with the -ForceTakeover option. It verifies that the TXT
record was created and kicks off the takeover process.
The -ForceTakeover option should be added to the
cmdlet only when forcing an external admin takeover, such as
when the unmanaged tenant has Office 365 services blocking
the takeover.
get-msoldomain The domain list now shows the the domain name as Verified.
PowerShell example
1. Connect to Azure AD using the credentials that were used to respond to the self-service offering:
import-module MSOnline
$msolcred = get-credential
connect-msolservice -credential $msolcred
2. Get a list of domains:

Get-MsolDomain
3. Run the Get-MsolDomainVerificationDns cmdlet to create a challenge:
Get-MsolDomainVerificationDns –DomainName *your_domain_name* –Mode DnsTxtRecord
For example:
Get-MsolDomainVerificationDns –DomainName contoso.com –Mode DnsTxtRecord
4. Copy the value (the challenge) that is returned from this command. For example:
MS=32DD01B82C05D27151EA9AE93C5890787F0E65D9
5. In your public DNS namespace, create a DNS txt record that contains the value that you copied in the previous
step. The name for this record is the name of the parent domain, so if you create this resource record by using
the DNS role from Windows Server, leave the Record name blank and just paste the value into the Text box.
6. Run the Confirm-MsolDomain cmdlet to verify the challenge:
Confirm-MsolEmailVerifiedDomain -DomainName *your_domain_name*
For example:
Confirm-MsolEmailVerifiedDomain -DomainName contoso.com
A successful challenge returns you to the prompt without an error.
Next steps
Add a custom domain name to Azure AD
Azure PowerShell
Set-MsolCompanySettings
Enterprise State Roaming overview
With Windows 10, Azure Active Directory (Azure AD) users gain the ability to securely synchronize their user
settings and application settings data to the cloud. Enterprise State Roaming provides users with a unified
experience across their Windows devices and reduces the time needed for configuring a new device. Enterprise
State Roaming operates similar to the standard consumer settings sync that was first introduced in Windows 8.
Additionally, Enterprise State Roaming offers:
Separation of corporate and consumer data – Organizations are in control of their data, and there is no
mixing of corporate data in a consumer cloud account or consumer data in an enterprise cloud account.
Enhanced security – Data is automatically encrypted before leaving the user’s Windows 10 device by using
Azure Rights Management (Azure RMS), and data stays encrypted at rest in the cloud. All content stays
encrypted at rest in the cloud, except for the namespaces, like settings names and Windows app names.
Better management and monitoring – Provides control and visibility over who syncs settings in your
organization and on which devices through the Azure AD portal integration.
Enterprise State Roaming is available in multiple Azure regions. You can find the updated list of available regions
on the Azure Services by Regions page under Azure Active Directory.
ARTICLE DESCRIPTION
Enable Enterprise State Roaming in Azure Active Directory Enterprise State Roaming is available to any organization with
a Premium Azure Active Directory (Azure AD) subscription.
For more details on how to get an Azure AD subscription, see
the Azure AD product page.
Settings and data roaming FAQ This topic answers some questions IT administrators might
have about settings and app data sync.
Group policy and MDM settings for settings sync Windows 10 provides Group Policy and mobile device
management (MDM) policy settings to limit settings sync.
Windows 10 roaming settings reference The following is a complete list of all the settings that will be
roamed and/or backed-up in Windows 10.
Troubleshooting This topic goes through some basic steps for troubleshooting,
and contains a list of known issues.
Enable Enterprise State Roaming in Azure Active
Directory
Enterprise State Roaming is available to any organization with an Azure AD Premium or Enterprise Mobility +
Security (EMS) license. For more information on how to get an Azure AD subscription, see the Azure AD product
page.
When you enable Enterprise State Roaming, your organization is automatically granted a free, limited-use license
for Azure Rights Management. This free subscription is limited to encrypting and decrypting enterprise settings
and application data synced by Enterprise State Roaming. You must have a paid subscription to use the full
capabilities of Azure Rights Management.
To enable Enterprise State Roaming

1. Sign in to Azure AD admin center.
2. Select Azure Active Directory > Devices > Device settings.
3. Select Users may sync settings and app data across devices. For more information, see how to
configure device settings.
For a Windows 10 device to use the Enterprise State Roaming service, the device must authenticate using an Azure
AD identity. For devices that are joined to Azure AD, the user’s primary sign-in identity is their Azure AD identity,
so no additional configuration is required. For devices that use on-premises Active Directory, the IT admin must
connect the domain-joined devices to Azure AD for Windows 10 experiences.
Data storage
Enterprise State Roaming data is hosted in one or more Azure regions that best align with the country/region
value set in the Azure Active Directory instance. Enterprise State Roaming data is partitioned based on three major
geographic regions: North America, EMEA, and APAC. Enterprise State Roaming data for the tenant is locally
located with the geographical region, and is not replicated across regions. For example::
COUNTRY/REGION VALUE HAS THEIR DATA HOSTED IN
An EMEA country such as “France” or “Zambia" one or of the Azure regions within Europe
A North American country such as “United States” or one or more of the Azure regions within the US
“Canada”
An APAC country such as “Australia” or “New Zealand” one or more of the Azure regions within Asia
South American and Antarctica regions one or more Azure regions within the US
The country/region value is set as part of the Azure AD directory creation process and cannot be subsequently
modified. If you need more details on your data storage location, file a ticket with Azure support.
View per-user device sync status

Follow these steps to view a per-user device sync status report.
1. Sign in to Azure AD admin center.
2. Select Azure Active Directory > Users and groups > All users.
3. Select the user, and then select Devices.
4. Under Show, select Devices syncing settings and app data to show sync status.
5. If there are devices syncing for this user, you see the devices as shown here.
Data retention
Data synced to Azure using Enterprise State Roaming is retained until it is manually deleted or until the data in
question is determined to be stale.
Explicit deletion
Explicit deletion is when an Azure admin deletes a user or a directory or otherwise requests explicitly that data is to
be deleted.
User deletion: When a user is deleted in Azure AD, the user account roaming data is deleted after 90 to 180
days.
Directory deletion: Deleting an entire directory in Azure AD is an immediate operation. All the settings data
associated with that directory is deleted after 90 to 180 days.
On request deletion: If the Azure AD admin wants to manually delete a specific user’s data or settings data,
the admin can file a ticket with Azure support.
Stale data deletion
Data that has not been accessed for one year (“the retention period”) will be treated as stale and may be deleted
from Azure. The retention period is subject to change but will not be less than 90 days. The stale data may be a
specific set of Windows/application settings or all settings for a user. For example:
If no devices access a particular settings collection (for example, an application is removed from the device, or a
settings group such as “Theme” is disabled for all of a user’s devices), then that collection becomes stale after
the retention period and may be deleted.
If a user has turned off settings sync on all his/her devices, then none of the settings data will be accessed, and
all the settings data for that user will become stale and may be deleted after the retention period.
If the Azure AD directory admin turns off Enterprise State Roaming for the entire directory, then all users in that
directory will stop syncing settings, and all settings data for all users will become stale and may be deleted after
the retention period.
Deleted data recovery
The data retention policy is not configurable. Once the data is permanently deleted, it is not recoverable. However,
The settings data is deleted only from Azure, not from the end-user device. If any device later reconnects to the
Enterprise State Roaming service, the settings are again synced and stored in Azure.
Related topics
Settings and data roaming FAQ
Group Policy and MDM settings for settings sync
Windows 10 roaming settings reference
Troubleshooting
Group Policy and MDM settings
Use these group policy and mobile device management (MDM) settings only on corporate-owned devices because
these policies are applied to the user’s entire device. Applying an MDM policy to disable settings sync for a
personal, user-owned device will negatively impact the use of that device. Additionally, other user accounts on the
device will also be affected by the policy.
Enterprises that want to manage roaming for personal (unmanaged) devices can use the Azure portal to enable or
disable roaming, rather than using Group Policy or MDM. The following tables describe the policy settings
available.
MDM settings
The MDM policy settings apply to both Windows 10 and Windows 10 Mobile. Windows 10 Mobile support exists
only for Microsoft account based roaming via user’s OneDrive account. Please refer to “Devices and endpoints”
section for details on what devices are supported for Azure AD based syncing.
NAME DESCRIPTION
Allow Microsoft Account Connection Allows users to authenticate using a Microsoft account on the
device
Allow Sync My Settings Allows users to roam Windows settings and app data;
Disabling this policy will disable sync as well as backups on
mobile devices
Group Policy settings

The Group Policy settings apply to Windows 10 devices that are joined to an Active Directory domain. The table
also includes legacy settings that would appear to manage sync settings, but that do not work for Enterprise State
Roaming for Windows 10, which are noted with ‘Do not use’ in the description.
NAME DESCRIPTION
Accounts: Block Microsoft Accounts This policy setting prevents users from adding new Microsoft
accounts on this computer
Do not sync Prevents users to roam Windows settings and app data
Do not sync personalize Disables syncing of the Themes group
Do not sync browser settings Disables syncing of the Internet Explorer group
Do not sync passwords Disables syncing of Passwords group
Do not sync other Windows settings Disables syncing of Other Windows settings group
Do not sync desktop personalization Do not use; has no effect

NAME DESCRIPTION
Do not sync on metered connections Disables roaming on metered connections, such as cellular 3G
Do not sync apps Do not use; has no effect
Do not sync app settings Disables roaming of app data
Do not sync start settings Do not use; has no effect
Related topics
Enable enterprise state roaming in Azure Active Directory
Troubleshooting
The following is a complete list of all the settings that will be roamed or backed up in Windows 10.
Devices and endpoints

See the following table for a summary of the devices and account types that are supported by the sync, backup,
and restore framework in Windows 10.
ACCOUNT TYPE AND OPERATION DESKTOP MOBILE
Azure Active Directory: sync Yes No
Azure Active Directory: backup/restore No No
Microsoft account: sync Yes Yes
Microsoft account: backup/restore No Yes
What is backup?
Windows settings generally sync by default, but some settings are only backed up, such as the list of installed
applications on a device. Backup is for mobile devices only and currently not available for Enterprise State
Roaming users. Backup uses a Microsoft account and stores the settings and application data into OneDrive. If a
user disables sync on the device using the Settings app, application data that normally syncs becomes backup
only. Backup data can only be accessed through the restore operation during the first run experience of a new
device. Backups can be disabled via the device settings, and can be managed and deleted through the user’s
OneDrive account.
Windows Settings overview

The following settings groups are available for end-users to enable/disable settings sync on Windows 10 devices.
Theme: desktop background, user tile, taskbar position, etc.
Internet Explorer Settings: browsing history, typed URLs, favorites, etc.
Passwords: Windows credential locker, including Wi-Fi profiles
Language Preferences: spelling dictionary, system language settings
Ease of Access: narrator, on-screen keyboard, magnifier
Other Windows Settings: see Windows Settings details
Edge browser setting group (favorites, reading list) syncing can be enabled or disabled by end users through Edge
browser Settings menu option.
Windows Settings details

In the following table, Other entries in the Settings Group column refers to settings that can be disabled by going
to Settings > Accounts > Sync your settings > Other Windows settings.
Internal entries in the Settings Group column refer to settings and apps that can only be disabled from syncing
within the app itself or by disabling sync for the entire device using mobile device management (MDM) or Group
Policy settings. Settings that don't roam or sync will not belong to a group.
SETTINGS DESKTOP MOBILE GROUP
Accounts: account picture sync X Theme
Accounts: other account X X

settings
Advanced mobile X X Passwords

broadband: Internet
connection sharing network
name (enables auto-
discovery of mobile Wi-Fi
hotspots via Bluetooth)
App data: individual apps sync backup sync backup internal

can sync data
App list: list of installed X backup Other

apps
Bluetooth: all Bluetooth X X

settings
Command prompt: sync X

Command prompt
"Defaults" settings
Credentials: Credential sync sync password

Locker
Date, Time, and Region: sync sync language

automatic time (Internet
time sync)
Date, Time, and Region: sync X language

24-hour clock

date and time
Date, Time, and Region: X language

time zone

daylight savings time

country/region

first day of week

region format (locale)

short date

long date

short time

long time
Desktop personalization: sync X Theme

desktop Theme
(background, system color,
default system sounds,
screen saver)

slideshow wallpaper

taskbar settings (position,
auto-hide, etc.)
Desktop personalization: X backup

start screen layout
Devices: shared printers X X other

you've connected to
Edge browser: reading list sync sync internal
Edge browser: favorites sync sync internal
Edge browser: top sites [1] sync sync internal
Edge browser: typed URLs sync sync internal

[1]
Edge browser: favorites bar sync sync internal

settings [1]
Edge browser: show the sync sync internal

home button [1]
Edge browser: block pop- sync sync internal

ups [1]
Edge browser: ask me what sync sync internal

to do with each download [1]
Edge browser: offer to save sync sync internal

passwords [1]
Edge browser: send do not sync sync internal

track requests [1]
Edge browser: save form sync sync internal

entries [1]
Edge browser: show search sync sync internal

and site suggestions as I
type [1]
Edge browser: cookies sync sync internal

preference [1]
Edge browser: let sites save sync sync internal

protected media licenses on
my device [1]
Edge browser: screen sync sync internal

reader setting [1]
High Contrast: On or Off sync X ease of access
High contrast: Theme sync X ease of access

settings
Internet Explorer: open sync sync Internet Explorer

tabs (URL and title)
Internet Explorer: reading sync sync Internet Explorer

list
Internet Explorer: typed sync sync Internet Explorer

URLs
Internet Explorer: browsing sync sync Internet Explorer

history
Internet Explorer: favorites sync sync Internet Explorer
Internet Explorer: excluded sync sync Internet Explorer

URLs
Internet Explorer: home sync sync Internet Explorer

pages
Internet Explorer: domain sync sync Internet Explorer

suggestions
Keyboard: users can turn sync X ease of access

on/off on-screen keyboard
Keyboard: turn on sticky sync X ease of access

yes (off by default)
Keyboard: turn on filter sync X ease of access

keys (off by default)
Keyboard: turn on toggle sync X ease of access

keys (off by default)
Internet Explorer: domain sync X Language

Language: Chinese (CHS)
QWERTY - enable self-
learning
Language: CHS QWERTY - sync X Language

enable dynamic candidate
ranking

char-set Simplified Chinese

char-set Traditional Chinese
Language: CHS QWERTY - sync backup Language

fuzzy pinyin
Language: CHS QWERTY - sync backup Language

fuzzy pairs

full pinyin

double pinyin

reading auto correction

C/E switch key, shift

C/E switch key, Ctrl
Language: CHS WUBI - sync X Language

single character input mode

show the remaining coding
of the candidate

beep when 4-coding is
invalid
Language: CHT Bopomofo - sync X Language

include CJK Ext-A
Language: Japanese IME - sync sync Language

predictive typing and
custom words
Language: Korean (KOR) X X Language

IME
Language: handwriting X X Language

recognition
Language: language profile sync backup Language
Language: spellcheck - sync backup Language

autocorrect and highlight
misspellings
Language: list of keyboards sync backup Language
Lock Screen: all lock screen X X

settings
Magnifier: on or off (master X X Ease of access

toggle)
Magnifier: turn inversion sync X Ease of access

color on or off (off by
default)
Magnifier: tracking - follow sync X Ease of access

the keyboard focus
Magnifier: tracking - follow sync X Ease of access

the mouse cursor
Magnifier: start when users sync X Ease of access

sign in (off by default)
Mouse: change the size of sync X other

mouse cursor
Mouse: change the color of sync X other

mouse cursor
Mouse: all other settings X X
Narrator: quick launch sync X Ease of access
Narrator: users can change sync X Ease of access

Narrator speaking pitch
Narrator: users can turn on sync X Ease of access

or off Narrator reading hints
for common items (on by
default)

or off whether they can hear
typed characters (on by
default)

or off whether they can hear
typed words (on by default)
Narrator: have insert cursor sync X Ease of access

following Narrator (on by
default)
Narrator: enable visual sync X Ease of access

highlighting of Narrator
cursor (on by default)
Narrator: play audio cues sync X Ease of access

(on by default)
Narrator: activate keys on sync X Ease of access

the touch keyboard when
you lift your finger (off by
default)
Ease of access: set the sync X Ease of access

thickness of the blinking
cursor
Ease of access: remove sync X Ease of access

background images (off by
default)
Power and Sleep: all X X

settings
Start screen X sync Theme

personalization: accent
color (phone only)
Typing: spelling dictionary sync backup Language
Typing: autocorrect sync backup Language

misspelled word
Typing: highlight misspelled sync backup Language

words
Typing: show text sync backup Language

suggestions as I type
Typing: add a space after I sync backup Language

choose a text suggestion
Typing: add a period after I sync backup Language

double-tap the spacebar
Typing: capitalize the first sync backup Language

letter of each sentence
Typing: use all uppercase sync backup Language

letters when I double-tap
shift key
Typing: play key sounds as I sync backup Language

type
Typing: personalization data sync backup Language

for touch keyboard
Wi-Fi: Wi-Fi profiles (only sync sync Passwords

WPA)
Fo o tn o te 1
Minimum supported OS version of Windows Creators Update (Build 15063).
Related topics
Enterprise state roaming overview
Group policy and MDM settings for settings sync
Troubleshooting
This topic answers some questions IT administrators might have about settings and app data sync.
What data roams?

Windows settings: the PC settings that are built into the Windows operating system. Generally, these are settings
that personalize your PC, and they include the following broad categories:
Theme, which includes features such as desktop theme and taskbar settings.
Internet Explorer settings, including recently opened tabs and favorites.
Edge browser settings, such as favorites and reading list.
Passwords, including Internet passwords, Wi-Fi profiles, and others.
Language preferences, which includes settings for keyboard layouts, system language, date and time, and
more.
Ease of access features, such as high-contrast theme, Narrator, and Magnifier.
Other Windows settings, such as command prompt settings and application list.
Application data: Universal Windows apps can write settings data to a roaming folder, and any data written to
this folder will automatically be synced. It’s up to the individual app developer to design an app to take advantage
of this capability. For more details about how to develop a Universal Windows app that uses roaming, see the
appdata storage API and the Windows 8 appdata roaming developer blog.
What account is used for settings sync?

In Windows 8 and Windows 8.1, settings sync always used consumer Microsoft accounts. Enterprise users had the
ability to connect a Microsoft account to their Active Directory domain account to gain access to settings sync. In
Windows 10, this connected Microsoft account functionality is being replaced with a primary/secondary account
framework.
The primary account is defined as the account used to sign in to Windows. This can be a Microsoft account, an
Azure Active Directory (Azure AD) account, an on-premises Active Directory account, or a local account. In addition
to the primary account, Windows 10 users can add one or more secondary cloud accounts to their device. A
secondary account is generally a Microsoft account, an Azure AD account, or some other account such as Gmail or
Facebook. These secondary accounts provide access to additional services such as single sign-on and the Windows
Store, but they are not capable of powering settings sync.
In Windows 10, only the primary account for the device can be used for settings sync (see How do I upgrade from
Microsoft account settings sync in Windows 8 to Azure AD settings sync in Windows 10?).
Data is never mixed between the different user accounts on the device. There are two rules for settings sync:
Windows settings will always roam with the primary account.
App data will be tagged with the account used to acquire the app. Only apps tagged with the primary account
will sync. App ownership tagging is determined when an app is side-loaded through the Windows Store or
mobile device management (MDM).
If an app’s owner cannot be identified, it will roam with the primary account. If a device is upgraded from Windows
8 or Windows 8.1 to Windows 10, all the apps will be tagged as acquired by the Microsoft account. This is because
most users acquire apps through the Windows Store, and there was no Windows Store support for Azure AD
accounts prior to Windows 10. If an app is installed via an offline license, the app will be tagged using the primary
account on the device.
NOTE
Windows 10 devices that are enterprise-owned and are connected to Azure AD can no longer connect their Microsoft
accounts to a domain account. The ability to connect a Microsoft account to a domain account and have all the user's data
sync to the Microsoft account (that is, the Microsoft account roaming via the connected Microsoft account and Active
Directory functionality) is removed from Windows 10 devices that are joined to a connected Active Directory or Azure AD
environment.
How do I upgrade from Microsoft account settings sync in Windows 8

to Azure AD settings sync in Windows 10?
If you are joined to the Active Directory domain running Windows 8 or Windows 8.1 with a connected Microsoft
account, you will sync settings through your Microsoft account. After upgrading to Windows 10, you will continue
to sync user settings via Microsoft account as long as you are a domain-joined user and the Active Directory
domain does not connect with Azure AD.
If the on-premises Active Directory domain does connect with Azure AD, your device will attempt to sync settings
using the connected Azure AD account. If the Azure AD administrator does not enable Enterprise State Roaming,
your connected Azure AD account will stop syncing settings. If you are a Windows 10 user and you sign in with an
Azure AD identity, you will start syncing windows settings as soon as your administrator enables settings sync via
Azure AD.
If you stored any personal data on your corporate device, you should be aware that Windows OS and application
data will begin syncing to Azure AD. This has the following implications:
Your personal Microsoft account settings will drift apart from the settings on your work or school Azure AD
accounts. This is because the Microsoft account and Azure AD settings sync are now using separate accounts.
Personal data such as Wi-Fi passwords, web credentials, and Internet Explorer favorites that were previously
synced via a connected Microsoft account will be synced via Azure AD.
How do Microsoft account and Azure AD Enterprise State Roaming

interoperability work?
In the November 2015 or later releases of Windows 10, Enterprise State Roaming is only supported for a single
account at a time. If you sign in to Windows by using a work or school Azure AD account, all data will sync via
Azure AD. If you sign in to Windows by using a personal Microsoft account, all data will sync via the Microsoft
account. Universal appdata will roam using only the primary sign-in account on the device, and it will roam only if
the app’s license is owned by the primary account. Universal appdata for the apps owned by any secondary
accounts will not be synced.
Do settings sync for Azure AD accounts from multiple tenants?

When multiple Azure AD accounts from different Azure AD tenants are on the same device, you must update the
device's registry to communicate with Azure Rights Management (Azure RMS) for each Azure AD tenant.
1. Find the GUID for each Azure AD tenant. Open the Azure portal and select an Azure AD tenant. The GUID for the
tenant is on the Properties page for the selected tenant
(https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Properties), labeled
Directory ID.
2. After you have the GUID, you will need to add the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\SettingSync\WinMSIPC<tenant ID GUID>.
From the tenant ID GUID key, create a new Multi-String value (REG-MULTI-SZ) named
AllowedRMSServerUrls. For its data, specify the licensing distribution point URLs of the other Azure tenants
that the device accesses.
3. You can find the licensing distribution point URLs by running the Get-AadrmConfiguration cmdlet. If the
values for the LicensingIntranetDistributionPointUrl and LicensingExtranetDistributionPointUrl are
different, specify both values. If the values are the same, specify the value just once.
What are the roaming settings options for existing Windows desktop
applications?
Roaming only works for Universal Windows apps. There are two options available for enabling roaming on an
existing Windows desktop application:
The Desktop Bridge helps you bring your existing Windows desktop apps to the Universal Windows Platform.
From here, minimal code changes will be required to take advantage of Azure AD app data roaming. The
Desktop Bridge provides your apps with an app identity, which is needed to enable app data roaming for
existing desktop apps.
User Experience Virtualization (UE-V) helps you create a custom settings template for existing Windows
desktop apps and enable roaming for Win32 apps. This option does not require the app developer to change
code of the app. UE-V is limited to on-premises Active Directory roaming for customers who have purchased
the Microsoft Desktop Optimization Pack.
Administrators can configure UE-V to roam Windows desktop app data by changing roaming of Windows OS
settings and Universal app data through UE-V group policies, including:
Roam Windows settings group policy
Do not synchronize Windows Apps group policy
Internet Explorer roaming in the applications section
In the future, Microsoft may investigate ways to make UE-V deeply integrated into Windows and extend UE-V to
roam settings through the Azure AD cloud.
Can I store synced settings and data on premises?

Enterprise State Roaming stores all synced data in the Azure cloud. UE-V offers an on-premises roaming solution.
Who owns the data that’s being roamed?

The enterprises own the data roamed via Enterprise State Roaming. Data is stored in an Azure datacenter. All user
data is encrypted both in transit and at rest in the cloud using Azure RMS. This is an improvement compared to
Microsoft account-based settings sync, which encrypts only certain sensitive data such as user credentials before it
leaves the device.
Microsoft is committed to safeguarding customer data. An enterprise user’s settings data is automatically
encrypted by Azure RMS before it leaves a Windows 10 device, so no other user can read this data. If your
organization has a paid subscription for Azure RMS, you can use other Azure RMS features, such as track and
revoke documents, automatically protect emails that contain sensitive information, and manage your own keys
(the "bring your own key" solution, also known as BYOK). For more information about these features and how
Azure RMS works, see What is Azure Rights Management.
Can I manage sync for a specific app or setting?

In Windows 10, there is no MDM or Group Policy setting to disable roaming for an individual application. Tenant
administrators can disable appdata sync for all apps on a managed device, but there is no finer control at a per-
app or within-app level.
How can I enable or disable roaming?

In the Settings app, go to Accounts > Sync your settings. From this page, you can see which account is being
used to roam settings, and you can enable or disable individual groups of settings to be roamed.
What is Microsoft’s recommendation for enabling roaming in Windows

10?
Microsoft has a few different settings roaming solutions available, including Roaming User Profiles, UE-V, and
Enterprise State Roaming. Microsoft is committed to making an investment in Enterprise State Roaming in future
versions of Windows. If your organization is not ready or comfortable with moving data to the cloud, then we
recommend that you use UE-V as your primary roaming technology. If your organization requires roaming
support for existing Windows desktop applications but is eager to move to the cloud, we recommend that you use
both Enterprise State Roaming and UE-V. Although UE-V and Enterprise State Roaming are very similar
technologies, they are not mutually exclusive. They complement each other to help ensure that your organization
provides the roaming services that your users need.
When using both Enterprise State Roaming and UE-V, the following rules apply:
Enterprise State Roaming is the primary roaming agent on the device. UE-V is being used to supplement the
“Win32 gap.”
UE-V roaming for Windows settings and modern UWP app data should be disabled when using the UE-V
group polices. These are already covered by Enterprise State Roaming.
How does Enterprise State Roaming support virtual desktop

infrastructure (VDI)?
Enterprise State Roaming is supported on Windows 10 client SKUs, but not on server SKUs. If a client VM is hosted
on a hypervisor machine and you remotely sign in to the virtual machine, your data will roam. If multiple users
share the same OS and users remotely sign in to a server for a full desktop experience, roaming might not work.
The latter session-based scenario is not officially supported.
What happens when my organization purchases Azure RMS after

using roaming?
If your organization is already using roaming in Windows 10 with the Azure RMS limited-use free subscription,
purchasing a paid Azure RMS subscription will not have any impact on the functionality of the roaming feature,
and no configuration changes will be required by your IT administrator.
Known issues
Please see the documentation in the troubleshooting section for a list of known issues.
Related topics
Troubleshooting
Troubleshooting Enterprise State Roaming settings in
This topic provides information on how to troubleshoot and diagnose issues with Enterprise State Roaming, and
provides a list of known issues.
Preliminary steps for troubleshooting

Before you start troubleshooting, verify that the user and device have been configured properly, and that all the
requirements of Enterprise State Roaming are met by the device and the user.
1. Windows 10, with the latest updates, and a minimum Version 1511 (OS Build 10586 or later) is installed on the
device.
2. The device is Azure AD joined or hybrid Azure AD joined. For more information, see how to get a device under
the control of Azure AD.
3. Ensure that Enterprise State Roaming is enabled for the tenant in Azure AD as described in To enable
Enterprise State Roaming. You can enable roaming for all users or for only a selected group of users.
4. The user must already be assigned an Azure Active Directory Premium license.
5. The device must be restarted and the user must sign in again to access Enterprise State Roaming features.
Information to include when you need help

If you cannot solve your issue with the guidance below, you can contact our support engineers. When you contact
them, include the following information:
General description of the error: Are there error messages seen by the user? If there was no error message,
describe the unexpected behavior you noticed, in detail. What features are enabled for sync and what is the
user expecting to sync? Are multiple features not syncing or is it isolated to one?
Users affected – Is sync working/failing for one user or multiple users? How many devices are involved per
user? Are all of them not syncing or are some of them syncing and some not syncing?
Information about the user – What identity is the user using to sign in to the device? How is the user signing
in to the device? Are they part of a selected security group allowed to sync?
Information about the device – Is this device Azure AD-joined or domain-joined? What build is the device
on? What are the most recent updates?
Date / Time / Timezone – What was the precise date and time you saw the error (include the timezone)?
Including this information helps us solve your problem as quickly as possible.
Troubleshooting and diagnosing issues

This section gives suggestions on how to troubleshoot and diagnose problems related to Enterprise State
Roaming.
Verify sync, and the “Sync your settings” settings page

1. After joining your Windows 10 PC to a domain that is configured to allow Enterprise State Roaming, sign on
with your work account. Go to Settings > Accounts > Sync Your Settings and confirm that sync and the
individual settings are on, and that the top of the settings page indicates that you are syncing with your work
account. Confirm the same account is also used as your login account in Settings > Accounts > Your Info.
2. Verify that sync works across multiple machines by making some changes on the original machine, such as
moving the taskbar to the right or top side of the screen. Watch the change propagate to the second machine
within five minutes.
Locking and unlocking the screen (Win + L) can help trigger a sync.
You must be signing in with the same account on both PCs for sync to work – as Enterprise State
Roaming is tied to the user account and not the machine account.
Potential issue: If the controls in the Settings page are not available, and you see the message “Some Windows
features are only available if you are using a Microsoft account or work account.” This issue might arise for
devices that are set up to be domain-joined and registered to Azure AD, but the device has not yet successfully
authenticated to Azure AD. A possible cause is that the device policy must be applied, but this application happens
asynchronously, and could be delayed by a few hours.
Verify the device registration status
Enterprise State Roaming requires the device to be registered with Azure AD. Although not specific to Enterprise
State Roaming, following the instructions below can help confirm that the Windows 10 Client is registered, and
confirm thumbprint, Azure AD settings URL, NGC status, and other information.
1. Open the command prompt unelevated. To do this in Windows, open the Run launcher (Win + R) and type
“cmd” to open.
2. Once the command prompt is open, type “dsregcmd.exe /status”.
3. For expected output, the AzureAdJoined field value should be “YES”, WamDefaultSet field value should be
“YES”, and the WamDefaultGUID field value should be a GUID with “(AzureAd)” at the end.
Potential issue: WamDefaultSet and AzureAdJoined both have “NO” in the field value, the device was
domain-joined and registered with Azure AD, and the device does not sync. If it is showing this, the device may
need to wait for policy to be applied or the authentication for the device failed when connecting to Azure AD. The
user may have to wait a few hours for the policy to be applied. Other troubleshooting steps may include retrying
auto-registration by signing out and back in, or launching the task in Task Scheduler. In some cases, running
“dsregcmd.exe /leave” in an elevated command prompt window, rebooting, and trying registration again may
help with this issue.
Potential issue: The field for AzureAdSettingsUrl is empty and the device does not sync. The user may have last
logged in to the device before Enterprise State Roaming was enabled in the Azure Active Directory Portal. Restart
the device and have the user login. Optionally, in the portal, try having the IT Admin disable and re-enable Users
May Sync Settings and Enterprise App Data. Once re-enabled, restart the device and have the user login. If this
does not resolve the issue, AzureAdSettingsUrl may be empty in the case of a bad device certificate. In this case,
running “dsregcmd.exe /leave” in an elevated command prompt window, rebooting, and trying registration again
may help with this issue.
Enterprise State Roaming and Multi-Factor Authentication

Under certain conditions, Enterprise State Roaming can fail to sync data if Azure Multi-Factor Authentication is
configured. For additional details on these symptoms, see the support document KB3193683.
Potential issue: If your device is configured to require Multi-Factor Authentication on the Azure Active Directory
portal, you may fail to sync settings while signing in to a Windows 10 device using a password. This type of Multi-
Factor Authentication configuration is intended to protect an Azure administrator account. Admin users may still
be able to sync by signing in to their Windows 10 devices with their Microsoft Passport for Work PIN or by
completing Multi-Factor Authentication while accessing other Azure services like Office 365.
Potential issue: Sync can fail if the admin configures the Active Directory Federation Services Multi-Factor
Authentication conditional access policy and the access token on the device expires. Ensure that you sign in and
sign out using the Microsoft Passport for Work PIN or complete Multi-Factor Authentication while accessing other
Azure services like Office 365.
Event Viewer
For advanced troubleshooting, Event Viewer can be used to find specific errors. These are documented in the table
below. The events can be found under Event Viewer > Applications and Services Logs > Microsoft > Windows >
SettingSync and for identity-related issues with sync Microsoft > Windows > Azure AD.
Known issues
Sync does not work on devices that have apps side -loaded using MDM software
Affects devices running the Windows 10 Anniversary Update (Version 1607). In Event Viewer under the
SettingSync-Azure logs, the Event ID 6013 with error 80070259 is frequently seen.
Recommended action
Make sure the Windows 10 v1607 client has the August 23, 2016 Cumulative Update (KB3176934 OS Build
14393.82).
Internet Explorer Favorites do not sync

Affects devices running the Windows 10 November Update (Version 1511).
Recommended action
Make sure the Windows 10 v1511 client has the July 2016 Cumulative Update (KB3172985 OS Build 10586.494).
Theme is not syncing, as well as data protected with Windows Information Protection
To prevent data leakage, data that is protected with Windows Information Protection will not sync through
Enterprise State Roaming for devices using the Windows 10 Anniversary Update.
Recommended action
None. Future updates to Windows may resolve this issue.
Date, Time, and Region settings do not sync on domain-joined device

Devices that are domain-joined will not experience sync for the setting Date, Time, and Region: automatic time.
Using automatic time may override the other Date, Time, and Region settings and cause those settings not to sync.
Recommended action
None.
UAC Prompts when syncing passwords

Affects devices running the Windows 10 November Update (Version 1511) with a wireless NIC that is configured
to sync passwords.
Recommended action
Make sure the Windows 10 v1511 client has the Cumulative Update (KB3140743 OS Build 10586.494).
Sync does not work on devices that use smart card for login
If you attempt to sign in to your Windows device using a smart card or virtual smart card, settings sync will stop
working.
Recommended action
None. Future updates to Windows may resolve this issue.
Domain-joined device is not syncing after leaving corporate network

Domain-joined devices registered to Azure AD may experience sync failure if the device is off-site for extended
periods of time, and domain authentication can't complete.
Recommended action
Connect the device to a corporate network so that sync can resume.
Azure AD Joined device is not syncing and the user has a mixed case User Principal Name.
If the user has a mixed case UPN (e.g. UserName instead of username) and the user is on an Azure AD Joined
device which has upgraded from Windows 10 Build 10586 to 14393, the user's device may fail to sync.
Recommended action
The user will need to unjoin and rejoin the device to the cloud. To do this, login as the Local Administrator user
and unjoin the device by going to Settings > System > About and select "Manage or disconnect from work or
school". Clean up the files below, and then Azure AD Join the device again in Settings > System > About and
selecting "Connect to Work or School". Continue to join the device to Azure Active Directory and complete the
flow.
In the cleanup step, cleanup the following files:
Settings.dat in C:\Users\<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\
All the files under the folder
C:\Users\<Username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Account
Event ID 6065: 80070533 This user can’t sign in because this account is currently disabled
In Event Viewer under the SettingSync/Debug logs, this error can be seen when the user's credentials have
expired. In addition, it can occur when the tenant did not automatically have AzureRMS provisioned.
Recommended action
In the first case, have the user update their credentials and login to the device with the new credentials. To solve
the AzureRMS issue, proceed with the steps listed in KB3193791.
Event ID 1098: Error: 0xCAA5001C Token broker operation failed

In Event Viewer under the AAD/Operational logs, this error may be seen with Event 1104: AAD Cloud AP plugin
call Get token returned error: 0xC000005F. This issue occurs if there are missing permissions or ownership
attributes.
Recommended action
Proceed with the steps listed KB3196528.
Next steps
Use the User Voice forum to provide feedback and make suggestions on how to improve Enterprise State
Roaming.
For more information, see the Enterprise State Roaming overview.
Related topics
Active Directory
IMPORTANT
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great time
to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these tools are
now deprecated are no longer supported as of April 13, 2017.

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common
identity for accessing both cloud and on-premises resources. Users and organizations can take advantage of the
following:
Azure Active Directory Connect is made up of three primary components: the synchronization services, the optional
Active Directory Federation Services component, and the monitoring component named Azure AD Connect Health.
AD FS - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid environment
using an on-premises AD FS infrastructure. This can be used by organizations to address complex deployments,
such as domain join SSO, enforcement of AD sign-in policy, and smart card or 3rd party MFA.

SOLUTION SCENARIO
Connect.
Express settings If you have a single forest AD then this is the recommended
option to use.
synchronization.
writeback.
running.
preference.
TOPIC LINK

You also want to prepare for operational concerns. You might want to have a stand-by server so you easily can fall
over if there is a disaster. If you plan to make frequent configuration changes, you should plan for a staging mode
server.
TOPIC LINK

Azure AD Connect comes with several features you can optionally turn on or are enabled by default. Some features
might sometimes require more configuration in certain scenarios and topologies.
attributes.
the same password on-premises and in the cloud but only manage it in one location. Since it uses your on-premises
Active Directory as the authority, you can also use your own password policy.
Device writeback will allow a device registered in Azure AD to be written back to on-premises Active Directory so it
can be used for conditional access.
organization size.
TOPIC LINK
Password synchronization Azure AD Connect sync: Implement password synchronization

topologies. But there are always situations where the default configuration does not work and must be adjusted. It
is supported to make changes as documented in this section and linked topics.
The default configuration assumes there might be more than one forest in the configuration. In those topologies a
user object might be represented as a contact in another forest. The user might also have a linked mailbox in
The configuration model in sync is called declarative provisioning. The advanced attribute flows are using functions
to express attribute transformations. You can see and examine the entire configuration using tools which comes
with Azure AD Connect. If you need to make configuration changes, make sure you follow the best practices so it is
easier to adopt new releases.
TOPIC LINK
configuration

Azure AD Connect provides several features that simplify federating with Azure AD using AD FS and managing your
federation trust. Azure AD Connect supports AD FS on Windows Server 2012R2 or later.
Update SSL certificate of AD FS farm even if you are not using Azure AD Connect to manage your federation trust.
ADFS can be configured to support multiple domains. For example you might have multiple top domains you need
to use for federation.
if your ADFS server has not been configured to automatically update certificates from Azure AD or if you use a non-
ADFS solution, then you will be notified when you have to update certificates.
TOPIC LINK

Connect

TOPIC LINK
Manage access to Azure resources with Azure Active
Directory
Identity and access management for cloud resources is a critical function for any organization that is using the
cloud. Azure Active Directory (Azure AD) is the identity and access system for Microsoft Azure.
Before exploring the supporting feature areas of Azure AD, check out the following video: "Locking down access to
the Azure Cloud using SSO, Roles Based Access Control, and Conditional." In it, you learn about:
Best practices for configuring single sign-on to the Azure portal, with on-premises Active Directory.
Using Azure RBAC for fine-grained access control to resources in subscriptions.
Enforcing strong authentication rules using Azure AD Conditional Access.
The concept of Managed Service Identity, where Azure resources can automatically authenticate to Azure
services, and developers don’t need to handle API keys or secrets.
Feature areas
Azure AD provides the following capabilities for managing access to Azure resources:
Relationship between Azure AD tenants and subscriptions Learn about how Azure AD is the trusted source of users and
groups for an Azure subscription.
Role-Based Access Control (RBAC) Offer fine-grained access management through roles assigned
to users, groups, or service principals.
Privileged Identity Management with RBAC Control highly privileged access by assigning privileged roles
just-in-time.
Conditional Access for Azure management Set up conditional access policies to allow or block access to
Azure management endpoints.
Managed Service Identity (MSI) Give Azure resources like Virtual Machines their own identity
so that you don’t have to put credentials in your code.
Understanding resource access in Azure
Access control in Azure starts from a billing perspective. The owner of an Azure account, accessed by visiting the
Azure Accounts Center, is the Account Administrator (AA). Subscriptions are a container for billing, but they also
act as a security boundary: each subscription has a Service Administrator (SA) who can add, remove, and modify
Azure resources in that subscription by using the Azure portal. The default SA of a new subscription is the AA, but
the AA can change the SA in the Azure Accounts Center.
Subscriptions also have an association with a directory. The directory defines a set of users. These can be users
from the work or school that created the directory or they can be external guest users. Subscriptions are accessible
by a subset of those directory users who have been assigned as either Service Administrator (SA) or Co-
Administrator (CA); the only exception is that, for legacy reasons, Microsoft accounts (formerly Windows Live ID)
can be assigned as SA or CA without being present in the directory.
Functionality within the Azure portal enables SAs that are signed in using a Microsoft Account to change the
directory with which a subscription is associated. This operation has implications on the access control of that
subscription.
In the simple case, an organization (such as Contoso) will enforce billing and access control across the same set of
subscriptions. That is, the directory is associated to subscriptions that are owned by a single Azure Account. Upon
successful login to the Azure portal, users see two collections of resources (depicted in orange in the previous
illustration):
Directories where their user account exists (sourced or added as a foreign principal). Note that the directory
used for login isn’t relevant to this computation, so your directories will always be shown regardless of where
you logged in.
Resources that are part of subscriptions that are associated with the directory used for login AND which the
user can access (where they are an SA or CA).
Users with subscriptions across multiple directories have the ability to switch the current context of the Azure
portal by using the subscription filter. Under the covers, this results in a separate login to a different directory, but
this is accomplished seamlessly using single sign-on (SSO).
Operations such as moving resources between subscriptions can be more difficult as a result of this single
directory view of subscriptions. To perform the resource transfer, it may be necessary to first use the Edit
Directory command on the Subscriptions page in Settings to associate the subscriptions to the same directory.
Next Steps
To learn more about how to change administrators for an Azure subscription, see How to add or change Azure
administrator roles
For more information on how Azure Active Directory relates to your Azure subscription, see How Azure
subscriptions are associated with Azure Active Directory
For more information on how to assign roles in Azure AD, see Assigning administrator roles in Azure Active
Directory
Get started with Role-Based Access Control in the
Azure portal
Security-oriented companies should focus on giving employees the exact permissions they need. Too many
permissions can expose an account to attackers. Too few permissions means that employees can't get their work
done efficiently. Azure Role-Based Access Control (RBAC) helps address this problem by offering fine-grained
access management for Azure.
Using RBAC, you can segregate duties within your team and grant only the amount of access to users that they
need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or
resources, you can allow only certain actions. For example, use RBAC to let one employee manage virtual machines
in a subscription, while another can manage SQL databases within the same subscription.
Basics of access management in Azure

Each Azure subscription is associated with one Azure Active Directory (AD) directory. Users, groups, and
applications from that directory can manage resources in the Azure subscription. Assign these access rights using
the Azure portal, Azure command-line tools, and Azure Management APIs.
Grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The
scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent
scope also grants access to the children contained within it. For example, a user with access to a resource group can
manage all the resources it contains, like websites, virtual machines, and subnets.
The RBAC role that you assign dictates what resources the user, group, or application can manage within that
scope.
Built-in roles
Azure RBAC has three basic roles that apply to all resource types:
Owner has full access to all resources including the right to delegate access to others.
Contributor can create and manage all types of Azure resources but can’t grant access to others.
Reader can view existing Azure resources.
The rest of the RBAC roles in Azure allow management of specific Azure resources. For example, the Virtual
Machine Contributor role allows the user to create and manage virtual machines. It does not give them access to
the virtual network or the subnet that the virtual machine connects to.
RBAC built-in roles lists the roles available in Azure. It specifies the operations and scope that each built-in role
grants to users. If you're looking to define your own roles for even more control, see how to build Custom roles in
Azure RBAC.
Resource hierarchy and access inheritance

Each subscription in Azure belongs to only one directory. (But each directory can have more than one
subscription.)
Each resource group belongs to only one subscription.
Each resource belongs to only one resource group.
Access that you grant at parent scopes is inherited at child scopes. For example:
You assign the Reader role to an Azure AD group at the subscription scope. The members of that group can
view every resource group and resource in the subscription.
You assign the Contributor role to an application at the resource group scope. It can manage resources of all
types in that resource group, but not other resource groups in the subscription.
Azure RBAC vs. classic subscription administrators

Classic subscription administrators and co-admins have full access to the Azure subscription. They can manage
resources using the Azure portal, Azure Resource Manager APIs, and the classic deployment model APIs. In the
RBAC model, classic administrators are assigned the Owner role at the subscription scope.
Only the Azure portal and the new Azure Resource Manager APIs support Azure RBAC. Users and applications that
are assigned RBAC roles cannot use the the Azure classic deployment model APIs.
Authorization for management vs. data operations

Azure RBAC only supports management operations of the Azure resources in the Azure portal and Azure Resource
Manager APIs. It cannot authorize all data level operations for Azure resources. For example, you can authorize
someone to manage Storage Accounts, but not to the blobs or tables within a Storage Account. Similarly, a SQL
database can be managed, but not the tables within it.
Next Steps
Get started with Role-Based Access Control in the Azure portal.
See the RBAC built-in roles
Define your own Custom roles in Azure RBAC
View access assignments for users and groups in the
Azure portal
With role-based access control (RBAC) in the Azure Active Directory (Azure AD), you can manage access to your
Azure resources.
Access assigned with RBAC is fine-grained because there are two ways you can restrict the permissions:
Scope: RBAC role assignments are scoped to a specific subscription, resource group, or resource. A user given
access to a single resource cannot access any other resources in the same subscription.
Role: Within the scope of the assignment, access is narrowed even further by assigning a role. Roles can be
high-level, like owner, or specific, like virtual machine reader.
Roles can only be assigned from within the subscription, resource group, or resource that is the scope for the
assignment. But you can view all the access assignments for a given user or group in a single place. You can have
up to 2000 role assignments in each subscription.
Get more information about how to Use role assignments to manage access to your Azure subscription resources.
View access assignments

To look up the access assignments for a single user or group, start in Azure Active Directory in the Azure portal.
1. Select Azure Active Directory. If this option is not visible on your navigation list, select More Services and
then scroll down to find Azure Active Directory.
2. Select Users and Groups, and then either All users or All groups. For this example, we focus on individual
users.
3. Search for the user by name or username.

4. Select Azure resources on the user blade. All the access assignments for that user appear.
Read permissions to view assignments
This page only shows the access assignments that you have permission to read. For example, you have read access
to subscription A and go to the Azure resources blade to check a user's assignments. You can see her access
assignments for subscription A, but can't see that she also has access assignments on subscription B.
Delete access assignments

From this blade, you can delete access assignments that were assigned directly to a user or group. If the access
assignment was inherited from a parent group, you need to go to the resource or subscription and manage the
assignment there.
1. From the list of all the access assignments for a user or group, select the one you want to delete.
2. Select Remove and then Yes to confirm.
Next steps
Get started with Role-Based Access Control to Use role assignments to manage access to your Azure
subscription resources
Use Role-Based Access Control to manage access
to your Azure subscription resources
Azure Role-Based Access Control (RBAC) enables fine-grained access management for Azure. Using RBAC,
you can grant only the amount of access that users need to perform their jobs. This article helps you get up
and running with RBAC in the Azure portal. If you want more details about how RBAC helps you manage
access, see What is Role-Based Access Control.
Within each subscription, you can grant up to 2000 role assignments.
View access
You can see who has access to a resource, resource group, or subscription from its main blade in the Azure
portal. For example, we want to see who has access to one of our resource groups:
1. Select Resource groups in the navigation bar on the left.
2. Select the name of the resource group from the Resource groups blade.
3. Select Access control (IAM) from the left menu.
4. The Access control blade lists all users, groups, and applications that have been granted access to the
resource group.
Notice that some roles are scoped to This resource while others are Inherited it from another scope. Access
is either assigned specifically to the resource group or inherited from an assignment to the parent
subscription.
NOTE
Classic subscription admins and co-admins are considered owners of the subscription in the new RBAC model.
Add Access
You grant access from within the resource, resource group, or subscription that is the scope of the role
assignment.
1. Select Add on the Access control blade.
2. Select the role that you wish to assign from the Select a role blade.
3. Select the user, group, or application in your directory that you wish to grant access to. You can search
the directory with display names, email addresses, and object identifiers.
4. Select OK to create the assignment. The Adding user popup tracks the progress.
After successfully adding a role assignment, it will appear on the Users blade.
Remove Access
1. Hover your cursor over the name of the assignment that you want to remove. A check box appears next to
the name.
2. Use the check boxes to select one or more role assignments.
3. Select Remove.
4. Select Yes to confirm the removal.
Inherited assignments cannot be removed. If you need to remove an inherited assignment, you need to do it
at the scope where the role assignment was created. In the Scope column, next to Inherited there is a link
that takes you to the resources where this role was assigned. Go to the resource listed there to remove the
role assignment.
Other tools to manage access

You can assign roles and manage access with Azure RBAC commands in tools other than the Azure portal.
Follow the links to learn more about the prerequisites and get started with the Azure RBAC commands.
Azure PowerShell
Azure Command-Line Interface
REST API
Next Steps
Create an access change history report
Define your own Custom roles in Azure RBAC
Built-in roles for Azure role-based access control
Azure Role-Based Access Control (RBAC) comes with the following built-in roles that can be assigned to users,
groups, and services. You can’t modify the definitions of built-in roles. However, you can create Custom roles in
Azure RBAC to fit the specific needs of your organization.
Roles in Azure
The following table provides brief descriptions of the built-in roles. Click the role name to see the detailed list of
actions and notactions for the role. The actions property specifies the allowed actions on Azure resources.
Action strings can use wildcard characters. The notactions property specifies the actions that are excluded from
the allowed actions.
The action defines what type of operations you can perform on a given resource type. For example:
Write enables you to perform PUT, POST, PATCH, and DELETE operations.
Read enables you to perform GET operations.
This article only addresses the different roles that exist today. When you assign a role to a user, though, you can
limit the allowed actions further by defining a scope. This is helpful if you want to make someone a Website
Contributor, but only for one resource group.
NOTE
The Azure role definitions are constantly evolving. This article is kept as up to date as possible, but you can always find the
latest roles definitions in Azure PowerShell. Use the Get-AzureRmRoleDefinition cmdlet to list all current roles. You can dive
in to a specific role using (get-azurermroledefinition "<role name>").actions or
(get-azurermroledefinition "<role name>").notactions as applicable. Use Get-AzureRmProviderOperation to list
operations of specific Azure resource providers.
ROLE NAME DESCRIPTION
API Management Service Contributor Can manage API Management service and the APIs
API Management Service Operator Role Can manage API Management service, but not the APIs
themselves
API Management Service Reader Role Read-only access to API Management service and APIs
Application Insights Component Contributor Can manage Application Insights components
Automation Operator Able to start, stop, suspend, and resume jobs
Backup Contributor Can manage backup in Recovery Services vault
Backup Operator Can manage backup except removing backup, in Recovery

Services vault
Backup Reader Can view all backup management services

Billing Reader Can view all billing information
BizTalk Contributor Can manage BizTalk services
ClearDB MySQL DB Contributor Can manage ClearDB MySQL databases
Contributor Can manage everything except access.
Data Factory Contributor Can create and manage data factories, and child resources
within them.
DevTest Labs User Can view everything and connect, start, restart, and
shutdown virtual machines
DNS Zone Contributor Can manage DNS zones and records
DocumentDB Account Contributor Can manage Azure Cosmos DB accounts
Intelligent Systems Account Contributor Can manage Intelligent Systems accounts
Logic App Contributor Can manage all aspects of a Logic App, but not create a new
one.
Logic App Operator Can start and stop workflows defined within a Logic App.
Monitoring Reader Can read all monitoring data
Monitoring Contributor Can read monitoring data and edit monitoring settings
Network Contributor Can manage all network resources
New Relic APM Account Contributor Can manage New Relic Application Performance Management
accounts and applications
Owner Can manage everything, including access
Reader Can view everything, but can't make changes
Redis Cache Contributor Can manage Redis caches
Scheduler Job Collections Contributor Can manage scheduler job collections
Search Service Contributor Can manage search services
Security Manager Can manage security components, security policies, and

virtual machines
Site Recovery Contributor Can manage Site Recovery in Recovery Services vault
Site Recovery Operator Can manage failover and failback operations Site Recovery in
Recovery Services vault
Site Recovery Reader Can view all Site Recovery management operations
SQL DB Contributor Can manage SQL databases, but not their security-related
policies
SQL Security Manager Can manage the security-related policies of SQL servers and
databases
SQL Server Contributor Can manage SQL servers and databases, but not their
security-related policies
Classic Storage Account Contributor Can manage classic storage accounts
Storage Account Contributor Can manage storage accounts
Support Request Contributor Can create and manage support requests
User Access Administrator Can manage user access to Azure resources
Classic Virtual Machine Contributor Can manage classic virtual machines, but not the virtual
network or storage account to which they are connected
Virtual Machine Contributor Can manage virtual machines, but not the virtual network or
storage account to which they are connected
Classic Network Contributor Can manage classic virtual networks and reserved IPs
Web Plan Contributor Can manage web plans
Website Contributor Can manage websites, but not the web plans to which they
are connected
Role permissions
The following tables describe the specific permissions given to each role. This can include Actions, which give
permissions, and NotActions, which restrict them.
API Management Service Contributor
Can manage API Management services
ACTIONS
Microsoft.ApiManagement/Service/* Create and manage API Management service
Microsoft.Authorization/*/read Read authorization
Microsoft.Insights/alertRules/* Create and manage alert rules
Microsoft.ResourceHealth/availabilityStatuses/read Read health of the resources
Microsoft.Resources/deployments/* Create and manage resource group deployments

ACTIONS
Microsoft.Resources/subscriptions/resourceGroups/read Read roles and role assignments
Microsoft.Support/* Create and manage support tickets
API Management Service Operator Role

ACTIONS
Microsoft.ApiManagement/Service/*/read Read API Management Service instances
Microsoft.ApiManagement/Service/backup/action Back up API Management Service to the specified container in

a user provided storage account
Microsoft.ApiManagement/Service/delete Delete an API Management Service instance
Microsoft.ApiManagement/Service/managedeployments/actio Change SKU/units; add or remove regional deployments of

n API Management Service
Microsoft.ApiManagement/Service/read Read metadata for an API Management Service instance
Microsoft.ApiManagement/Service/restore/action Restore API Management Service from the specified container

in a user provided storage account
Microsoft.ApiManagement/Service/updatehostname/action Set up, update, or remove custom domain names for an API
Management Service
Microsoft.ApiManagement/Service/write Create a new instance of API Management Service
API Management Service Reader Role

ACTIONS
Microsoft.ApiManagement/Service/*/read Read API Management Service instances
Microsoft.ApiManagement/Service/read Read metadata for an API Management Service instance

ACTIONS
Application Insights Component Contributor

Can manage Application Insights components
ACTIONS
Microsoft.Authorization/*/read Read roles and role assignments
Microsoft.Insights/components/* Create and manage Insights components
Microsoft.Insights/webtests/* Create and manage web tests
Microsoft.Resources/subscriptions/resourceGroups/read Read resource groups
Automation Operator
Able to start, stop, suspend, and resume jobs
ACTIONS
Microsoft.Automation/automationAccounts/jobs/read Read automation account jobs
Microsoft.Automation/automationAccounts/jobs/resume/acti Resume an automation account job

on
Microsoft.Automation/automationAccounts/jobs/stop/action Stop an automation account job
Microsoft.Automation/automationAccounts/jobs/streams/rea Read automation account job streams

d
ACTIONS
Microsoft.Automation/automationAccounts/jobs/suspend/act Suspend an automation account job

ion
Microsoft.Automation/automationAccounts/jobs/write Write automation account jobs
Microsoft.Automation/automationAccounts/jobSchedules/rea Read an automation account job schedule

d
Microsoft.Automation/automationAccounts/jobSchedules/wri Read an automation account job schedule

te
Microsoft.Automation/automationAccounts/read Read automation accounts
Microsoft.Automation/automationAccounts/runbooks/read Read automation runbooks
Microsoft.Automation/automationAccounts/schedules/read Read automation account schedules
Microsoft.Automation/automationAccounts/schedules/write Write automation account schedules
Backup Contributor
Can manage all backup management actions, except creating Recovery Services vault and giving access to others
ACTIONS
Microsoft.Network/virtualNetworks/read Read virtual networks
Microsoft.RecoveryServices/Vaults/backupFabrics/operationRe Manage results of operation on backup management

sults/*
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Create and manage backup containers inside backup fabrics

ontainers/* of Recovery Services vault
Microsoft.RecoveryServices/Vaults/backupJobs/* Create and manage backup jobs
Microsoft.RecoveryServices/Vaults/backupJobsExport/action Export backup jobs into an excel
Microsoft.RecoveryServices/Vaults/backupManagementMeta Create and manage meta data related to backup

Data/* management
Microsoft.RecoveryServices/Vaults/backupOperationResults/* Create and manage Results of backup management

operations
ACTIONS
Microsoft.RecoveryServices/Vaults/backupPolicies/* Create and manage backup policies
Microsoft.RecoveryServices/Vaults/backupProtectableItems/* Create and manage items which can be backed up
Microsoft.RecoveryServices/Vaults/backupProtectedItems/* Create and manage backed up items
Microsoft.RecoveryServices/Vaults/backupProtectionContaine Create and manage containers holding backup items

rs/*
Microsoft.RecoveryServices/Vaults/certificates/* Create and manage certificates related to backup in Recovery

Services vault
Microsoft.RecoveryServices/Vaults/extendedInformation/* Create and manage extended info related to vault
Microsoft.RecoveryServices/Vaults/read Read recovery services vaults
Microsoft.RecoveryServices/Vaults/refreshContainers/* Manage discovery operation for fetching newly created

containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/* Create and manage registered identities
Microsoft.RecoveryServices/Vaults/usages/* Create and manage usage of Recovery Services vault
Microsoft.Storage/storageAccounts/read Read storage accounts
Backup Operator
Can manage all backup management actions except creating vaults, removing backup and giving access to others
ACTIONS
Microsoft.RecoveryServices/Vaults/backupFabrics/operationRe Read results of operation on backup management

sults/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read operation results on protection containers

ontainers/operationResults/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Perform on-demand backup operation on a backed up item

ontainers/protectedItems/backup/action
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read result of operation performed on backed up item

ontainers/protectedItems/operationResults/read
ACTIONS
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read status of operation performed on backed up item

ontainers/protectedItems/operationStatus/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read backed up items

ontainers/protectedItems/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read recovery point of a backed up item

ontainers/protectedItems/recoveryPoints/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Perform a restore operation using a recovery point of a

ontainers/protectedItems/recoveryPoints/restore/action backed up item
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Create a backup item

ontainers/protectedItems/write
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read containers holding backup item

ontainers/read
Microsoft.RecoveryServices/Vaults/backupJobs/* Create and manage backup jobs
Microsoft.RecoveryServices/Vaults/backupManagementMeta Read meta data related to backup management

Data/read
Microsoft.RecoveryServices/Vaults/backupOperationResults/* Create and manage Results of backup management

operations
Microsoft.RecoveryServices/Vaults/backupPolicies/operationR Read results of operations performed on backup policies

esults/read
Microsoft.RecoveryServices/Vaults/backupPolicies/read Read backup policies
Microsoft.RecoveryServices/Vaults/backupProtectableItems/* Create and manage items which can be backed up
Microsoft.RecoveryServices/Vaults/backupProtectedItems/rea Read backed up items

d
Microsoft.RecoveryServices/Vaults/backupProtectionContaine Read backed up containers holding backup items

rs/read
Microsoft.RecoveryServices/Vaults/extendedInformation/read Read extended info related to vault
Microsoft.RecoveryServices/Vaults/extendedInformation/write Write extended info related to vault
Microsoft.RecoveryServices/Vaults/refreshContainers/* Manage discovery operation for fetching newly created

containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/operati Read results of operation performed on Registered items of

onResults/read the vault
ACTIONS
Microsoft.RecoveryServices/Vaults/registeredIdentities/read Read registered items of the vault
Microsoft.RecoveryServices/Vaults/registeredIdentities/write Write registered items to vault
Microsoft.RecoveryServices/Vaults/usages/read Read usage of the Recovery Services vault
Backup Reader
Can monitor backup management in Recovery Services vault
ACTIONS
Microsoft.RecoveryServices/Vaults/backupFabrics/operationRe Read results of operation on backup management

sults/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read operation results on protection containers

ontainers/operationResults/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read result of operation performed on backed up item

ontainers/protectedItems/operationResults/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read status of operation performed on backed up item

ontainers/protectedItems/operationStatus/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read backed up items

ontainers/protectedItems/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionC Read containers holding backup item

ontainers/read
Microsoft.RecoveryServices/Vaults/backupJobs/operationResu Read results of backup jobs

lts/read
Microsoft.RecoveryServices/Vaults/backupJobs/read Read backup jobs
Microsoft.RecoveryServices/Vaults/backupManagementMeta Read meta data related to backup management

Data/read
Microsoft.RecoveryServices/Vaults/backupOperationResults/r Read backup management operation results

ead
Microsoft.RecoveryServices/Vaults/backupPolicies/operationR Read results of operations performed on backup policies

esults/read
ACTIONS
Microsoft.RecoveryServices/Vaults/backupPolicies/read Read backup policies
Microsoft.RecoveryServices/Vaults/backupProtectedItems/rea Read backed up items

d
Microsoft.RecoveryServices/Vaults/backupProtectionContaine Read backed up containers holding backup items

rs/read
Microsoft.RecoveryServices/Vaults/refreshContainers/read Read result of discovery operation for fetching newly created

containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/operati Read results of operation performed on Registered items of

onResults/read the vault
Microsoft.RecoveryServices/Vaults/registeredIdentities/read Read registered items of the vault
Microsoft.RecoveryServices/Vaults/usages/read Read usage of the Recovery Services vault
Billing Reader
Can view all Billing information
ACTIONS
Microsoft.Billing/*/read Read Billing information
BizTalk Contributor
Can manage BizTalk services
ACTIONS
Microsoft.BizTalkServices/BizTalk/* Create and manage BizTalk services

ACTIONS
ClearDB MySQL DB Contributor

Can manage ClearDB MySQL databases
ACTIONS
successbricks.cleardb/databases/* Create and manage ClearDB MySQL databases
Contributor
Can manage everything except access
ACTIONS
* Create and manage resources of all types
NOTACTIONS
Microsoft.Authorization/*/Delete Can’t delete roles and role assignments
Microsoft.Authorization/*/Write Can’t create roles and role assignments
Data Factory Contributor

Create and manage data factories, and child resources within them.
ACTIONS
Microsoft.Authorization/*/read Read roles and role Assignments
Microsoft.DataFactory/dataFactories/* Create and manage data factories, and child resources within
them.

ACTIONS
DevTest Labs User

Can view everything and connect, start, restart, and shutdown virtual machines
ACTIONS
Microsoft.Compute/availabilitySets/read Read the properties of availability sets
Microsoft.Compute/virtualMachines/*/read Read the properties of a virtual machine (VM sizes, runtime

status, VM extensions, etc.)
Microsoft.Compute/virtualMachines/deallocate/action Deallocate virtual machines
Microsoft.Compute/virtualMachines/read Read the properties of a virtual machine
Microsoft.Compute/virtualMachines/restart/action Restart virtual machines
Microsoft.Compute/virtualMachines/start/action Start virtual machines
Microsoft.DevTestLab/*/read Read the properties of a lab
Microsoft.DevTestLab/labs/createEnvironment/action Create a lab environment
Microsoft.DevTestLab/labs/formulas/delete Delete formulas
Microsoft.DevTestLab/labs/formulas/read Read formulas
Microsoft.DevTestLab/labs/formulas/write Add or modify formulas
Microsoft.DevTestLab/labs/policySets/evaluatePolicies/action Evaluate lab policies
Microsoft.Network/loadBalancers/backendAddressPools/join/ Join a load balancer backend address pool

action
Microsoft.Network/loadBalancers/inboundNatRules/join/actio Join a load balancer inbound NAT rule

n
Microsoft.Network/networkInterfaces/*/read Read the properties of a network interface (for example, all

the load balancers that the network interface is a part of)
Microsoft.Network/networkInterfaces/join/action Join a Virtual Machine to a network interface
Microsoft.Network/networkInterfaces/read Read network interfaces
Microsoft.Network/networkInterfaces/write Write network interfaces

ACTIONS
Microsoft.Network/publicIPAddresses/*/read Read the properties of a public IP address
Microsoft.Network/publicIPAddresses/join/action Join a public IP address
Microsoft.Network/publicIPAddresses/read Read network public IP addresses
Microsoft.Network/virtualNetworks/subnets/join/action Join a virtual network
Microsoft.Resources/deployments/operations/read Read deployment operations
Microsoft.Resources/deployments/read Read deployments
Microsoft.Storage/storageAccounts/listKeys/action List storage account keys
DNS Zone Contributor

Can manage DNS zones and records.
ACTIONS
Microsoft.Network/dnsZones/* Create and manage DNS zones and records
Microsoft.ResourceHealth/availabilityStatuses/read Read the health of the resources
Microsoft.Support/* Create and manage Support tickets
DocumentDB Account Contributor

Can manage Azure Cosmos DB accounts. Azure Cosmos DB is formerly known as DocumentDB.
ACTIONS
Microsoft.DocumentDb/databaseAccounts/* Create and manage Azure Cosmos DB accounts

ACTIONS
Intelligent Systems Account Contributor

Can manage Intelligent Systems accounts
ACTIONS
Microsoft.IntelligentSystems/accounts/* Create and manage intelligent systems accounts
Monitoring Reader
Can read all monitoring data (metrics, logs, etc.). See also Get started with roles, permissions, and security with
Azure Monitor.
ACTIONS
*/read Read resources of all types, except secrets.
Microsoft.OperationalInsights/workspaces/search/action Search Log Analytics data
Monitoring Contributor
Can read all monitoring data and edit monitoring settings. See also Get started with roles, permissions, and
security with Azure Monitor.
ACTIONS
Microsoft.Insights/AlertRules/* Read/write/delete alert rules.
Microsoft.Insights/components/* Read/write/delete Application Insights components.
Microsoft.Insights/DiagnosticSettings/* Read/write/delete diagnostic settings.

ACTIONS
Microsoft.Insights/eventtypes/* List Activity Log events (management events) in a

subscription. This permission is applicable to both
programmatic and portal access to the Activity Log.
Microsoft.Insights/LogDefinitions/* This permission is necessary for users who need access to

Activity Logs via the portal. List log categories in Activity Log.
Microsoft.Insights/MetricDefinitions/* Read metric definitions (list of available metric types for a

resource).
Microsoft.Insights/Metrics/* Read metrics for a resource.
Microsoft.Insights/Register/Action Register the Microsoft.Insights provider.
Microsoft.Insights/webtests/* Read/write/delete Application Insights web tests.
Microsoft.OperationalInsights/workspaces/intelligencepacks/* Read/write/delete Log Analytics solution packs.
Microsoft.OperationalInsights/workspaces/savedSearches/* Read/write/delete Log Analytics saved searches.
Microsoft.OperationalInsights/workspaces/search/action Search Log Analytics workspaces.
Microsoft.OperationalInsights/workspaces/sharedKeys/action List keys for a Log Analytics workspace.
Microsoft.OperationalInsights/workspaces/storageinsightconfi Read/write/delete Log Analytics storage insight

gs/* configurations.
Network Contributor
Can manage all network resources
ACTIONS
Microsoft.Network/* Create and manage networks
New Relic APM Account Contributor

Can manage New Relic Application Performance Management accounts and applications
ACTIONS
NewRelic.APM/accounts/* Create and manage New Relic application performance

management accounts
Owner
Can manage everything, including access
ACTIONS
* Create and manage resources of all types
Reader
Can view everything, but can't make changes
ACTIONS
Redis Cache Contributor

Can manage Redis caches
ACTIONS
Microsoft.Cache/redis/* Create and manage Redis caches
Scheduler Job Collections Contributor

Can manage Scheduler job collections
ACTIONS
Microsoft.Scheduler/jobcollections/* Create and manage job collections
Search Service Contributor

Can manage Search services
ACTIONS
Microsoft.Search/searchServices/* Create and manage search services
Security Manager
Can manage security components, security policies, and virtual machines
ACTIONS
Microsoft.ClassicCompute/*/read Read configuration information classic compute virtual

machines
Microsoft.ClassicCompute/virtualMachines/*/write Write configuration for virtual machines
Microsoft.ClassicNetwork/*/read Read configuration information about classic network

ACTIONS
Microsoft.Security/* Create and manage security components and policies
Site Recovery Contributor

Can manage all Site Recovery management actions, except creating Recovery Services vault and assigning access
rights to other users
ACTIONS
Microsoft.RecoveryServices/Vaults/certificates/write Updates the vault credential certificate
Microsoft.RecoveryServices/Vaults/extendedInformation/* Create and manage extended info related to vault
Microsoft.RecoveryServices/Vaults/monitoringAlerts/* Read alerts for the Recovery services vault
Microsoft.RecoveryServices/Vaults/monitoringConfigurations/ Read Recovery services vault notification configuration

notificationConfiguration/read
Microsoft.RecoveryServices/Vaults/read Read Recovery Services vaults
Microsoft.RecoveryServices/Vaults/refreshContainers/read Manage discovery operation for fetching newly created

containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/* Create and manage registered identities
Microsoft.RecoveryServices/vaults/replicationAlertSettings/* Create or Update replication alert settings
Microsoft.RecoveryServices/vaults/replicationEvents/read Read replication events
Microsoft.RecoveryServices/vaults/replicationFabrics/* Create and manage replication fabrics
Microsoft.RecoveryServices/vaults/replicationJobs/* Create and manage replication jobs
Microsoft.RecoveryServices/vaults/replicationPolicies/* Create and manage replication policies
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/* Create and manage recovery plans
Microsoft.RecoveryServices/Vaults/storageConfig/* Create and manage storage configuration of Recovery

Services vault
ACTIONS
Microsoft.RecoveryServices/Vaults/tokenInfo/read Read Recovery Services vault token information
Microsoft.RecoveryServices/Vaults/usages/read Read usage details of a Recovery Services vault
Site Recovery Operator

Can Failover and Failback but can not perform other Site Recovery management actions or assign access to other
users
ACTIONS
Microsoft.RecoveryServices/Vaults/monitoringAlerts/* Read alerts for the Recovery services vault


containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/operati Read operation status and result for a submitted operation

onResults/read
Microsoft.RecoveryServices/Vaults/registeredIdentities/read Read containers registered for a resource
Microsoft.RecoveryServices/vaults/replicationAlertSettings/rea Read replication alert settings

d
Microsoft.RecoveryServices/vaults/replicationFabrics/checkCo Check consistency of the fabrics

nsistency/action
ACTIONS
Microsoft.RecoveryServices/vaults/replicationFabrics/read Read replication fabrics
Microsoft.RecoveryServices/vaults/replicationFabrics/ Re-associate replication gateway

reassociateGateway/action
Microsoft.RecoveryServices/vaults/replicationFabrics/renewcer Renew replication fabric certificate

tificate/action
Microsoft.RecoveryServices/vaults/replicationFabrics/replicatio Read replication fabric networks

nNetworks/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read replication fabric network mapping

replicationNetworks/replicationNetworkMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read protection containers

replicationProtectionContainers/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of all protectable items

replicationProtectionContainers/replicationProtectableItems/r
ead
Microsoft.RecoveryServices/vaults/replicationFabrics/ Apply a specific recovery point

replicationProtectionContainers/replicationProtectedItems/
applyRecoveryPoint/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Commit failover for a failed over item

failoverCommit/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Start planned failover for a protected item

plannedFailover/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of all protected items

replicationProtectionContainers/replicationProtectedItems/rea
d
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of available recovery points

replicationProtectionContainers/replicationProtectedItems/rec
overyPoints/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Repair replication for a protected item

repairReplication/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Start re-protect for a protected item

replicationProtectionContainers/replicationProtectedItems/re
Protect/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Start test failover of a protected item

replicationProtectionContainers/replicationProtectedItems/tes
tFailover/action
ACTIONS
Microsoft.RecoveryServices/vaults/replicationFabrics/ Start cleanup of a test failover

testFailoverCleanup/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Start unplanned failover of a protected item

unplannedFailover/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Update the mobility service

updateMobilityService/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read protection container mappings

replicationProtectionContainers/replicationProtectionContain
erMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read Recovery Services providers

replicationRecoveryServicesProviders/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Refresh Recovery Services provider

replicationRecoveryServicesProviders/refreshProvider/action
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read storage classifications for replication fabrics

replicationStorageClassifications/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read storage classification mappings

replicationStorageClassifications/replicationStorageClassificati
onMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/replicatio Read registered vCenter information

nvCenters/read
Microsoft.RecoveryServices/vaults/replicationJobs/* Create and manage replication jobs
Microsoft.RecoveryServices/vaults/replicationPolicies/read Read replication policies
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/ Commit failover for recovery plan failover

failoverCommit/action
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/ Start failover of a recovery plan

plannedFailover/action
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/re Read recovery plans

ad
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/re Start re-protect of a recovery plan

Protect/action
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/te Start test failover of a recovery plan

stFailover/action
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/ Start cleanup of a recovery plan test failover

testFailoverCleanup/action
ACTIONS
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/ Start unplanned failover of a recovery plan

unplannedFailover/action
Microsoft.RecoveryServices/Vaults/storageConfig/read Read storage configuration of a Recovery Services vault
Site Recovery Reader

Can monitor Site Recovery status in Recovery Services vault and raise Support tickets
ACTIONS
Microsoft.RecoveryServices/Vaults/monitoringAlerts/read Read alerts for the Recovery services vault


containers
Microsoft.RecoveryServices/Vaults/registeredIdentities/operati Read operation status and result for a submitted operation

onResults/read
Microsoft.RecoveryServices/Vaults/registeredIdentities/read Read containers registered for a resource
Microsoft.RecoveryServices/vaults/replicationAlertSettings/rea Read replication alert settings

d
Microsoft.RecoveryServices/vaults/replicationFabrics/read Read replication fabrics

ACTIONS
Microsoft.RecoveryServices/vaults/replicationFabrics/replicatio Read replication fabric networks

nNetworks/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read replication fabric network mapping

replicationNetworks/replicationNetworkMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read protection containers

replicationProtectionContainers/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of all protectable items

replicationProtectionContainers/replicationProtectableItems/r
ead
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of all protected items

replicationProtectionContainers/replicationProtectedItems/rea
d
Microsoft.RecoveryServices/vaults/replicationFabrics/ Get list of available recovery points

replicationProtectionContainers/replicationProtectedItems/rec
overyPoints/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read protection container mappings

replicationProtectionContainers/replicationProtectionContain
erMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read Recovery Services providers

replicationRecoveryServicesProviders/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read storage classifications for replication fabrics

replicationStorageClassifications/read
Microsoft.RecoveryServices/vaults/replicationFabrics/ Read storage classification mappings

replicationStorageClassifications/replicationStorageClassificati
onMappings/read
Microsoft.RecoveryServices/vaults/replicationFabrics/replicatio Read registered vCenter information

nvCenters/read
Microsoft.RecoveryServices/vaults/replicationJobs/read Read status of replication jobs
Microsoft.RecoveryServices/vaults/replicationPolicies/read Read replication policies
Microsoft.RecoveryServices/vaults/replicationRecoveryPlans/re Read recovery plans

ad
Microsoft.RecoveryServices/Vaults/storageConfig/read Read storage configuration of a Recovery Services vault
SQL DB Contributor
Can manage SQL databases but not their security-related policies
ACTIONS
Microsoft.Sql/servers/databases/* Create and manage SQL databases
Microsoft.Sql/servers/read Read SQL Servers
NOTACTIONS
Microsoft.Sql/servers/databases/auditingPolicies/* Can't edit audit policies
Microsoft.Sql/servers/databases/auditingSettings/* Can't edit audit settings
Microsoft.Sql/servers/databases/auditRecords/read Can't read audit records
Microsoft.Sql/servers/databases/connectionPolicies/* Can't edit connection policies
Microsoft.Sql/servers/databases/dataMaskingPolicies/* Can't edit data masking policies
Microsoft.Sql/servers/databases/securityAlertPolicies/* Can't edit security alert policies
Microsoft.Sql/servers/databases/securityMetrics/* Can't edit security metrics
SQL Security Manager

Can manage the security-related policies of SQL servers and databases
ACTIONS
Microsoft.Authorization/*/read Read Microsoft authorization
Microsoft.Insights/alertRules/* Create and manage Insights alert rules
Microsoft.Sql/servers/auditingPolicies/* Create and manage SQL server auditing policies

ACTIONS
Microsoft.Sql/servers/auditingSettings/* Create and manage SQL server auditing setting
Microsoft.Sql/servers/databases/auditingPolicies/* Create and manage SQL server database auditing policies
Microsoft.Sql/servers/databases/auditingSettings/* Create and manage SQL server database auditing settings
Microsoft.Sql/servers/databases/auditRecords/read Read audit records
Microsoft.Sql/servers/databases/connectionPolicies/* Create and manage SQL server database connection policies
Microsoft.Sql/servers/databases/dataMaskingPolicies/* Create and manage SQL server database data masking

policies
Microsoft.Sql/servers/databases/read Read SQL databases
Microsoft.Sql/servers/databases/schemas/read Read SQL server database schemas
Microsoft.Sql/servers/databases/schemas/tables/columns/rea Read SQL server database table columns

d
Microsoft.Sql/servers/databases/schemas/tables/read Read SQL server database tables
Microsoft.Sql/servers/databases/securityAlertPolicies/* Create and manage SQL server database security alert

policies
Microsoft.Sql/servers/databases/securityMetrics/* Create and manage SQL server database security metrics
Microsoft.Sql/servers/read Read SQL Servers
Microsoft.Sql/servers/securityAlertPolicies/* Create and manage SQL server security alert policies
SQL Server Contributor

Can manage SQL servers and databases but not their security-related policies
ACTIONS
Microsoft.Sql/servers/* Create and manage SQL servers

ACTIONS
NOTACTIONS
Microsoft.Sql/servers/auditingPolicies/* Can't edit SQL server auditing policies
Microsoft.Sql/servers/auditingSettings/* Can't edit SQL server auditing settings
Microsoft.Sql/servers/databases/auditingPolicies/* Can't edit SQL server database auditing policies
Microsoft.Sql/servers/databases/auditingSettings/* Can't edit SQL server database auditing settings
Microsoft.Sql/servers/databases/auditRecords/read Can't read audit records
Microsoft.Sql/servers/databases/connectionPolicies/* Can't edit SQL server database connection policies
Microsoft.Sql/servers/databases/dataMaskingPolicies/* Can't edit SQL server database data masking policies
Microsoft.Sql/servers/databases/securityAlertPolicies/* Can't edit SQL server database security alert policies
Microsoft.Sql/servers/databases/securityMetrics/* Can't edit SQL server database security metrics
Microsoft.Sql/servers/securityAlertPolicies/* Can't edit SQL server security alert policies
Classic Storage Account Contributor

Can manage classic storage accounts
ACTIONS
Microsoft.ClassicStorage/storageAccounts/* Create and manage storage accounts
Storage Account Contributor

Can manage storage accounts, but not access to them.
ACTIONS
Microsoft.Authorization/*/read Read all authorization

ACTIONS
Microsoft.Insights/diagnosticSettings/* Manage diagnostic settings
Microsoft.Storage/storageAccounts/* Create and manage storage accounts
Support Request Contributor

Can create and manage support tickets at the subscription scope
ACTIONS
User Access Administrator

Can manage user access to Azure resources
ACTIONS
*/read Read resources of all Types, except secrets.
Microsoft.Authorization/* Manage authorization
Classic Virtual Machine Contributor

Can manage classic virtual machines but not the virtual network or storage account to which they are connected
ACTIONS
Microsoft.ClassicCompute/domainNames/* Create and manage classic compute domain names
Microsoft.ClassicCompute/virtualMachines/* Create and manage virtual machines
Microsoft.ClassicNetwork/networkSecurityGroups/join/action Join network security groups
Microsoft.ClassicNetwork/reservedIps/link/action Link reserved IPs

ACTIONS
Microsoft.ClassicNetwork/reservedIps/read Read reserved IP addresses
Microsoft.ClassicNetwork/virtualNetworks/join/action Join virtual networks
Microsoft.ClassicNetwork/virtualNetworks/read Read virtual networks
Microsoft.ClassicStorage/storageAccounts/disks/read Read storage account disks
Microsoft.ClassicStorage/storageAccounts/images/read Read storage account images
Microsoft.ClassicStorage/storageAccounts/listKeys/action List storage account keys
Microsoft.ClassicStorage/storageAccounts/read Read classic storage accounts
Virtual Machine Contributor

Can manage virtual machines but not the virtual network or storage account to which they are connected
ACTIONS
Microsoft.Compute/availabilitySets/* Create and manage compute availability sets
Microsoft.Compute/locations/* Create and manage compute locations
Microsoft.Compute/virtualMachines/* Create and manage virtual machines
Microsoft.Compute/virtualMachineScaleSets/* Create and manage virtual machine scale sets
Microsoft.Network/applicationGateways/backendAddressPool Join network application gateway backend address pools

s/join/action
Microsoft.Network/loadBalancers/backendAddressPools/join/ Join load balancer backend address pools

action
Microsoft.Network/loadBalancers/inboundNatPools/join/actio Join load balancer inbound NAT pools

n
ACTIONS
Microsoft.Network/loadBalancers/inboundNatRules/join/actio Join load balancer inbound NAT rules

n
Microsoft.Network/loadBalancers/read Read load balancers
Microsoft.Network/locations/* Create and manage network locations
Microsoft.Network/networkInterfaces/* Create and manage network interfaces
Microsoft.Network/networkSecurityGroups/join/action Join network security groups
Microsoft.Network/networkSecurityGroups/read Read network security groups
Microsoft.Network/publicIPAddresses/join/action Join network public IP addresses
Microsoft.Network/publicIPAddresses/read Read network public IP addresses
Microsoft.Network/virtualNetworks/subnets/join/action Join virtual network subnets
Microsoft.Storage/storageAccounts/listKeys/action List storage account keys
Classic Network Contributor

Can manage classic virtual networks and reserved IPs
ACTIONS
Microsoft.ClassicNetwork/* Create and manage classic networks

ACTIONS
Web Plan Contributor

Can manage web plans
ACTIONS
Microsoft.Web/serverFarms/* Create and manage server farms
Website Contributor
Can manage websites but not the web plans to which they are connected
ACTIONS
Microsoft.Web/certificates/* Create and manage website certificates
Microsoft.Web/listSitesAssignedToHostName/read Read sites assigned to a host name
Microsoft.Web/serverFarms/join/action Join server farms
Microsoft.Web/serverFarms/read Read server farms
Microsoft.Web/sites/* Create and manage websites (site creation also requires write
permissions to the associated App Service Plan)
See also
Role-Based Access Control: Get started with RBAC in the Azure portal.
Custom roles in Azure RBAC: Learn how to create custom roles to fit your access needs.
Create an access change history report: Keep track of changing role assignments in RBAC.
Role-Based Access Control troubleshooting: Get suggestions for fixing common issues.
Create custom roles for Azure Role-Based Access
Control
Create a custom role in Azure Role-Based Access Control (RBAC) if none of the built-in roles meet your specific
access needs. Custom roles can be created using Azure PowerShell, Azure Command-Line Interface (CLI), and the
REST API. Just like built-in roles, you can assign custom roles to users, groups, and applications at subscription,
resource group, and resource scopes. Custom roles are stored in an Azure AD tenant and can be shared across
subscriptions.
Each tenant can create up to 2000 custom roles.
The following example shows a custom role for monitoring and restarting virtual machines:
{
"Name": "Virtual Machine Operator",
"Id": "cadb4a5a-4e7a-47be-84db-05cad13b6769",
"IsCustom": true,
"Description": "Can monitor and restart virtual machines.",
"Actions": [
"Microsoft.Storage/*/read",
"Microsoft.Network/*/read",
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Authorization/*/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Insights/alertRules/*",
"Microsoft.Insights/diagnosticSettings/*",
"Microsoft.Support/*"
],
"NotActions": [
],
"AssignableScopes": [
"/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e",
"/subscriptions/e91d47c4-76f3-4271-a796-21b4ecfe3624",
"/subscriptions/34370e90-ac4a-4bf9-821f-85eeedeae1a2"
]
}
Actions
The Actions property of a custom role specifies the Azure operations to which the role grants access. It is a
collection of operation strings that identify securable operations of Azure resource providers. Operation strings
follow the format of Microsoft.<ProviderName>/<ChildResourceType>/<action> . Operation strings that contain
wildcards (*) grant access to all operations that match the operation string. For instance:
*/read grants access to read operations for all resource types of all Azure resource providers.
Microsoft.Compute/* grants access to all operations for all resource types in the Microsoft.Compute resource
provider.
Microsoft.Network/*/read grants access to read operations for all resource types in the Microsoft.Network
resource provider of Azure.
Microsoft.Compute/virtualMachines/* grants access to all operations of virtual machines and its child resource
types.
Microsoft.Web/sites/restart/Action grants access to restart websites.
Use Get-AzureRmProviderOperation (in PowerShell) or azure provider operations show (in Azure CLI) to list
operations of Azure resource providers. You may also use these commands to verify that an operation string is
valid, and to expand wildcard operation strings.
Get-AzureRMProviderOperation Microsoft.Compute/virtualMachines/*/action | FT Operation, OperationName
Get-AzureRMProviderOperation Microsoft.Network/*
azure provider operations show "Microsoft.Compute/virtualMachines/*/action" --js on | jq '.[] | .operation'
azure provider operations show "Microsoft.Network/*"
NotActions
Use the NotActions property if the set of operations that you wish to allow is more easily defined by excluding
restricted operations. The access granted by a custom role is computed by subtracting the NotActions operations
from the Actions operations.
NOTE
If a user is assigned a role that excludes an operation in NotActions, and is assigned a second role that grants access to the
same operation, the user is allowed to perform that operation. NotActions is not a deny rule – it is simply a convenient way
to create a set of allowed operations when specific operations need to be excluded.
AssignableScopes
The AssignableScopes property of the custom role specifies the scopes (subscriptions, resource groups, or
resources) within which the custom role is available for assignment. You can make the custom role available for
assignment in only the subscriptions or resource groups that require it, and not clutter user experience for the rest
of the subscriptions or resource groups.
Examples of valid assignable scopes include:
“/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e”, “/subscriptions/e91d47c4-76f3-4271-a796-
21b4ecfe3624” - makes the role available for assignment in two subscriptions.
“/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e” - makes the role available for assignment in a
single subscription.
“/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network” - makes the role
available for assignment only in the Network resource group.
NOTE
You must use at least one subscription, resource group, or resource ID.
Custom roles access control

The AssignableScopes property of the custom role also controls who can view, modify, and delete the role.
Who can create a custom role? Owners (and User Access Administrators) of subscriptions, resource groups,
and resources can create custom roles for use in those scopes. The user creating the role needs to be able to
perform Microsoft.Authorization/roleDefinition/write operation on all the AssignableScopes of the role.
Who can modify a custom role? Owners (and User Access Administrators) of subscriptions, resource groups,
and resources can modify custom roles in those scopes. Users need to be able to perform the
Microsoft.Authorization/roleDefinition/write operation on all the AssignableScopes of a custom role.
Who can view custom roles? All built-in roles in Azure RBAC allow viewing of roles that are available for
assignment. Users who can perform the Microsoft.Authorization/roleDefinition/read operation at a scope can
view the RBAC roles that are available for assignment at that scope.
See also
Role Based Access Control: Get started with RBAC in the Azure portal.
For a list of available operations, see Azure Resource Manager Resource Provider operations.
Learn how to manage access with:
PowerShell
Azure CLI
REST API
Built-in roles: Get details about the roles that come standard in RBAC.
Intro on role-based access control
Role-based access control is an Azure portal only feature allowing the owners of a subscription to assign granular
roles to other users who can manage specific resource scopes in their environment.
RBAC allows better security management for large organizations and for SMBs working with external collaborators,
vendors or freelancers which need access to specific resources in your environment but not necessarily to the entire
infrastructure or any billing-related scopes. RBAC allows the flexibility of owning one Azure subscription managed
by the administrator account (service administrator role at a subscription level) and have multiple users invited to
work under the same subscription but without any administrative rights for it. From a management and billing
perspective, the RBAC feature proves to be a time and management efficient option for using Azure in various
scenarios.
Prerequisites
Using RBAC in the Azure environment requires:
Having a standalone Azure subscription assigned to the user as owner (subscription role)
Have the Owner role of the Azure subscription
Have access to the Azure portal
Make sure to have the following Resource Providers registered for the user subscription:
Microsoft.Authorization. For more information on how to register the resource providers, see Resource
Manager providers, regions, API versions and schemas.
NOTE
Office 365 subscriptions or Azure Active Directory licenses (for example: Access to Azure Active Directory) provisioned from
the Office 365 Admin center don't qualify for using RBAC.
How can RBAC be used

RBAC can be applied at three different scopes in Azure. From the highest scope to the lowest one, they are as
follows:
Subscription (highest)
Resource group
Resource scope (the lowest access level offering targeted permissions to an individual Azure resource scope)
Assign RBAC roles at the subscription scope

There are two common examples when RBAC is used (but not limited to):
Having external users from the organizations (not part of the admin user's Azure Active Directory tenant) invited
to manage certain resources or the whole subscription
Working with users inside the organization (they are part of the user's Azure Active Directory tenant) but part of
different teams or groups which need granular access either to the whole subscription or to certain resource
groups or resource scopes in the environment
Grant access at a subscription level for a user outside of Azure Active
Directory
RBAC roles can be granted only by Owners of the subscription therefore the admin user must be logged with a
username which has this role pre-assigned or has created the Azure subscription.
From the Azure portal, after you sign-in as admin, select “Subscriptions” and chose the desired one.
By default, if the admin user has purchased the Azure subscription, the user will show up as Account Admin, this
being the subscription role. For more details on the Azure subscription roles, see Add or change Azure
administrator roles that manage the subscription or services.
In this example, the user "alflanigan@outlook.com" is the Owner of the "Free Trial" subscription in the AAD tenant
"Default tenant Azure". Since this user is the creator of the Azure subscription with the initial Microsoft Account
“Outlook” (Microsoft Account = Outlook, Live etc.) the default domain name for all other users added in this tenant
will be "@alflaniganuoutlook.onmicrosoft.com". By design, the syntax of the new domain is formed by putting
together the username and domain name of the user who created the tenant and adding the extension
".onmicrosoft.com". Furthermore, users can sign-in with a custom domain name in the tenant after adding and
verifying it for the new tenant. For more details on how to verify a custom domain name in an Azure Active
Directory tenant, see Add a custom domain name to your directory.
In this example, the "Default tenant Azure" directory contains only users with the domain name
"@alflanigan.onmicrosoft.com".
After selecting the subscription, the admin user must click Access Control (IAM) and then Add a new role.
The next step is to select the role to be assigned and the user whom the RBAC role will be assigned to. In the Role
dropdown menu the admin user sees only the built-in RBAC roles which are available in Azure. For more detailed
explanations of each role and their assignable scopes, see Built-in roles for Azure Role-Based Access Control.
The admin user then needs to add the email address of the external user. The expected behavior is for the external
user to not show up in the existing tenant. After the external user has been invited, he will be visible under
Subscriptions > Access Control (IAM) with all the current users which are currently assigned an RBAC role at the
Subscription scope.
The user "chessercarlton@gmail.com" has been invited to be an Owner for the “Free Trial” subscription. After
sending the invitation, the external user will receive an email confirmation with an activation link.
Being external to the organization, the new user does not have any existing attributes in the "Default tenant Azure"
directory. They will be created after the external user has given consent to be recorded in the directory which is
associated with the subscription which he has been assigned a role to.
The external user shows in the Azure Active Directory tenant from now on as external user and this can be viewed in
the Azure portal.
In the Users view, the external users can be recognized by the different icon type in the Azure portal.
However, granting Owner or Contributor access to an external user at the Subscription scope, does not allow the
access to the admin user's directory, unless the Global Admin allows it. In the user proprieties, the User Type
which has two common parameters, Member and Guest can be identified. A member is a user which is registered
in the directory while a guest is a user invited to the directory from an external source. For more information, see
How do Azure Active Directory admins add B2B collaboration users.
NOTE
Make sure that after entering the credentials in the portal, the external user selects the correct directory to sign-in to. The
same user can have access to multiple directories and can select either one of them by clicking the username in the top right-
hand side in the Azure portal and then choose the appropriate directory from the dropdown list.
While being a guest in the directory, the external user can manage all resources for the Azure subscription, but can't
access the directory.
Azure Active Directory and an Azure subscription don't have a child-parent relation like other Azure resources (for
example: virtual machines, virtual networks, web apps, storage etc.) have with an Azure subscription. All the latter is
created, managed and billed under an Azure subscription while an Azure subscription is used to manage the access
to an Azure directory. For more details, see How an Azure subscription is related to Azure AD.
From all the built-in RBAC roles, Owner and Contributor offer full management access to all resources in the
environment, the difference being that a Contributor can't create and delete new RBAC roles. The other built-in
roles like Virtual Machine Contributor offer full management access only to the resources indicated by the name,
regardless of the Resource Group they are being created into.
Assigning the built-in RBAC role of Virtual Machine Contributor at a subscription level, means that the user
assigned the role:
Can view all virtual machines regardless their deployment date and the resource groups they are part of
Has full management access to the virtual machines in the subscription
Can't view any other resource types in the subscription
Can't operate any changes from a billing perspective
Assign a built-in RBAC role to an external user

For a different scenario in this test, the external user "alflanigan@gmail.com" is added as a Virtual Machine
Contributor.
The normal behavior for this external user with this built-in role is to see and manage only virtual machines and
their adjacent Resource Manager only resources necessary while deploying. By design, these limited roles offer
access only to their correspondent resources created in the Azure portal.
Grant access at a subscription level for a user in the same directory

The process flow is identical to adding an external user, both from the admin perspective granting the RBAC role as
well as the user being granted access to the role. The difference here is that the invited user will not receive any
email invitations as all the resource scopes within the subscription will be available in the dashboard after signing
in.
Assign RBAC roles at the resource group scope

Assigning an RBAC role at a Resource Group scope has an identical process for assigning the role at the
subscription level, for both types of users - either external or internal (part of the same directory). The users which
are assigned the RBAC role is to see in their environment only the resource group they have been assigned access
from the Resource Groups icon in the Azure portal.
Assign RBAC roles at the resource scope

Assigning an RBAC role at a resource scope in Azure has an identical process for assigning the role at the
subscription level or at the resource group level, following the same workflow for both scenarios. Again, the users
which are assigned the RBAC role can see only the items that they have been assigned access to, either in the All
Resources tab or directly in their dashboard.
An important aspect for RBAC both at resource group scope or resource scope is for the users to make sure to sign-
in to the correct directory.
Assign RBAC roles for an Azure Active Directory group

All the scenarios using RBAC at the three different scopes in Azure offer the privilege of managing, deploying and
administering various resources as an assigned user without the need of managing a personal subscription.
Regardless the RBAC role is assigned for a subscription, resource group or resource scope, all the resources created
further on by the assigned users are billed under the one Azure subscription where the users have access to. This
way, the users who have billing administrator permissions for that entire Azure subscription has a complete
overview on the consumption, regardless who is managing the resources.
For larger organizations, RBAC roles can be applied in the same way for Azure Active Directory groups considering
the perspective that the admin user wants to grant the granular access for teams or entire departments, not
individually for each user, thus considering it as an extremely time and management efficient option. To illustrate
this example, the Contributor role has been added to one of the groups in the tenant at the subscription level.
These groups are security groups which are provisioned and managed only within Azure Active Directory.
Create a custom RBAC role to open support requests using PowerShell

The built-in RBAC roles which are available in Azure ensure certain permission levels based on the available
resources in the environment. However, if none of these roles suit the admin user's needs, there is the option to
limit access even more by creating custom RBAC roles.
Creating custom RBAC roles requires to take one built-in role, edit it and then import it back in the environment.
The download and upload of the role are managed using either PowerShell or CLI.
It is important to understand the prerequisites of creating a custom role which can grant granular access at the
subscription level and also allow the invited user the flexibility of opening support requests.
For this example the built-in role Reader which allows users access to view all the resource scopes but not to edit
them or create new ones has been customized to allow the user the option of opening support requests.
The first action of exporting the Reader role needs to be completed in PowerShell ran with elevated permissions as
administrator.
Login-AzureRMAccount
Get-AzureRMRoleDefinition -Name "Reader"
Get-AzureRMRoleDefinition -Name "Reader" | ConvertTo-Json | Out-File C:\rbacrole2.json

Then you need to extract the JSON template of the role.
A typical RBAC role is composed out of three main sections, Actions, NotActions and AssignableScopes.
In the Action section are listed all the permitted operations for this role. It's important to understand that each
action is assigned from a resource provider. In this case, for creating support tickets the Microsoft.Support
resource provider must be listed.
To be able to see all the resource providers available and registered in your subscription, you can use PowerShell.
Get-AzureRMResourceProvider
Additionally, you can check for the all the available PowerShell cmdlets to manage the resource providers.
To restrict all the actions for a particular RBAC role, resource providers are listed under the section NotActions.
Last, it's mandatory that the RBAC role contains the explicit subscription IDs where it is used. The subscription IDs
are listed under the AssignableScopes, otherwise you will not be allowed to import the role in your subscription.
After creating and customizing the RBAC role, it needs to be imported back the environment.
New-AzureRMRoleDefinition -InputFile "C:\rbacrole2.json"
In this example, the custom name for this RBAC role is "Reader support tickets access level" allowing the user to
view everything in the subscription and also to open support requests.
NOTE
The only two built-in RBAC roles allowing the action of opening of support requests are Owner and Contributor. For a user
to be able to open support requests, he must be assigned an RBAC role only at the subscription scope, because all support
requests are created based on an Azure subscription.
This new custom role has been assigned to an user from the same directory.
The example has been further detailed to emphasize the limits of this custom RBAC role as follows:
Can create new support requests
Can't create new resource scopes (for example: virtual machine)
Can't create new resource groups
Create a custom RBAC role to open support requests using Azure CLI
Running on a Mac and without having access to PowerShell, Azure CLI is the way to go.
The steps to create a custom role are the same, with the sole exception that using CLI the role can't be downloaded
in a JSON template, but it can be viewed in the CLI.
For this example I have chosen the built-in role of Backup Reader.
azure role show "backup reader" --json
Editing the role in Visual Studio after copying the proprieties in a JSON template, the Microsoft.Support resource
provider has been added in the Actions sections so that this user can open support requests while continuing to be
a reader for the backup vaults. Again it is necessary to add the subscription ID where this role will be used in the
AssignableScopes section.
azure role create --inputfile <path>

The new role is now available in the Azure portal and the assignation process is the same as in the previous
examples.
As of the latest Build 2017, the Azure Cloud Shell is generally available. Azure Cloud Shell is a complement to IDE
and the Azure portal. With this service, you get a browser-based shell that is authenticated and hosted within Azure
and you can use it instead of CLI installed on your machine.
Create an access report for Role-Based Access
Control
Any time someone grants or revokes access within your subscriptions, the changes get logged in Azure events. You
can create access change history reports to see all changes for the past 90 days.
Create a report with Azure PowerShell

To create an access change history report in PowerShell, use the Get-AzureRMAuthorizationChangeLog command.
When you call this command, you can specify which property of the assignments you want listed, including the
following:
PROPERTY DESCRIPTION
Action Whether access was granted or revoked
Caller The owner responsible for the access change
PrincipalId The unique identifier of the user, group, or application that

was assigned the role
PrincipalName The name of the user, group, or application
PrincipalType Whether the assignment was for a user, group, or application
RoleDefinitionId The GUID of the role that was granted or revoked
RoleName The role that was granted or revoked
Scope The unique identifier of the subscription, resource group, or

resource that the assignment applies to
ScopeName The name of the subscription, resource group, or resource
ScopeType Whether the assignment was at the subscription, resource

group, or resource scope
Timestamp The date and time that access was changed
This example command lists all access changes in the subscription for the past seven days:
Get-AzureRMAuthorizationChangeLog -StartTime ([DateTime]::Now - [TimeSpan]::FromDays(7)) | FT

Caller,Action,RoleName,PrincipalType,PrincipalName,ScopeType,ScopeName
Create a report with Azure CLI
To create an access change history report in the Azure command-line interface (CLI), use the
azure role assignment changelog list command.
Export to a spreadsheet
To save the report, or manipulate the data, export the access changes into a .csv file. You can then view the report in
a spreadsheet for review.
Next steps
Work with Custom roles in Azure RBAC
Learn how to manage Azure RBAC with powershell
Manage Role-Based Access Control with the Azure
command-line interface
You can use Role-Based Access Control (RBAC) in the Azure portal and Azure Resource Manager API to manage
access to your subscription and resources at a fine-grained level. With this feature, you can grant access for Active
Directory users, groups, or service principals by assigning some roles to them at a particular scope.
Before you can use the Azure command-line interface (CLI) to manage RBAC, you must have the following
prerequisites:
Azure CLI version 0.8.8 or later. To install the latest version and associate it with your Azure subscription, see
Install and Configure the Azure CLI.
Azure Resource Manager in Azure CLI. Go to Using the Azure CLI with the Resource Manager for more details.
List roles
List all available roles
To list all available roles, use:
azure role list
The following example shows the list of all available roles.
azure role list --json | jq '.[] | {"roleName":.properties.roleName, "description":.properties.description}'
List actions of a role

To list the actions of a role, use:
azure role show "<role name>"
The following example shows the actions of the Contributor and Virtual Machine Contributor roles.
azure role show "contributor" --json | jq '.[] |

{"Actions":.properties.permissions[0].actions,"NotActions":properties.permissions[0].notActions}'
azure role show "virtual machine contributor" --json | jq '.[] | .properties.permissions[0].actions'
List access
List role assignments effective on a resource group
To list the role assignments that exist in a resource group, use:
azure role assignment list --resource-group <resource group name>
The following example shows the role assignments in the pharma-sales-projecforcast group.
azure role assignment list --resource-group pharma-sales-projecforcast --json | jq '.[] |

{"DisplayName":.properties.aADObject.displayName,"RoleDefinitionName":.properties.roleName,"Scope":.properties
.scope}'
List role assignments for a user
To list the role assignments for a specific user and the assignments that are assigned to a user's groups, use:
azure role assignment list --signInName <user email>
You can also see role assignments that are inherited from groups by modifying the command:
azure role assignment list --expandPrincipalGroups --signInName <user email>
The following example shows the role assignments that are granted to the sameert@aaddemo.com user. This
includes roles that are assigned directly to the user and roles that are inherited from groups.
azure role assignment list --signInName sameert@aaddemo.com --json | jq '.[] |

{"DisplayName":.properties.aADObject.DisplayName,"RoleDefinitionName":.properties.roleName,"Scope":.properties
.scope}'
azure role assignment list --expandPrincipalGroups --signInName sameert@aaddemo.com --json | jq '.[] |

{"DisplayName":.properties.aADObject.DisplayName,"RoleDefinitionName":.properties.roleName,"Scope":.properties
.scope}'
Grant access
To grant access after you have identified the role that you want to assign, use:
azure role assignment create
Assign a role to group at the subscription scope

To assign a role to a group at the subscription scope, use:
azure role assignment create --objectId <group object id> --roleName <name of role> --subscription
<subscription> --scope <subscription/subscription id>
The following example assigns the Reader role to Christine Koch's Team at the subscription scope.
Assign a role to an application at the subscription scope
To assign a role to an application at the subscription scope, use:
azure role assignment create --objectId <applications object id> --roleName <name of role> --subscription
<subscription> --scope <subscription/subscription id>
The following example grants the Contributor role to an Azure AD application on the selected subscription.
Assign a role to a user at the resource group scope

To assign a role to a user at the resource group scope, use:
azure role assignment create --signInName <user email address> --roleName "<name of role>" --resourceGroup
<resource group name>
The following example grants the Virtual Machine Contributor role to samert@aaddemo.com user at the Pharma-
Sales-ProjectForcast resource group scope.
Assign a role to a group at the resource scope
To assign a role to a group at the resource scope, use:
azure role assignment create --objectId <group id> --role "<name of role>" --resource-name <resource group
name> --resource-type <resource group type> --parent <resource group parent> --resource-group <resource group>
The following example grants the Virtual Machine Contributor role to an Azure AD group on a subnet.
Remove access
To remove a role assignment, use:
azure role assignment delete --objectId <object id to from which to remove role> --roleName "<role name>"
The following example removes the Virtual Machine Contributor role assignment from the
sammert@aaddemo.com user on the Pharma-Sales-ProjectForcast resource group. The example then removes
the role assignment from a group on the subscription.
Create a custom role

To create a custom role, use:
azure role create --inputfile <file path>
The following example creates a custom role called Virtual Machine Operator. This custom role grants access to all
read operations of Microsoft.Compute, Microsoft.Storage, and Microsoft.Network resource providers and grants
access to start, restart, and monitor virtual machines. This custom role can be used in two subscriptions. This
example uses a JSON file as an input.
Modify a custom role
To modify a custom role, first use the azure role list command to retrieve role definition. Second, make the
desired changes to the role definition file. Finally, use azure role set to save the modified role definition.
azure role set --inputfile <file path>
The following example adds the Microsoft.Insights/diagnosticSettings/ operation to the Actions, and an Azure
subscription to the AssignableScopes of the Virtual Machine Operator custom role.
Delete a custom role
To delete a custom role, first use the azure role list command to determine the ID of the role. Then, use the
azure role delete command to delete the role by specifying the ID.
The following example removes the Virtual Machine Operator custom role.
List custom roles

To list the roles that are available for assignment at a scope, use the azure role list command.
The following command lists all roles that are available for assignment in the selected subscription.
azure role list --json | jq '.[] | {"name":.properties.roleName, type:.properties.type}'

In the following example, the Virtual Machine Operator custom role isn’t available in the Production4 subscription
because that subscription isn’t in the AssignableScopes of the role.
azure role list --json | jq '.[] | if .properties.type == "CustomRole" then .properties.roleName else empty
end'
Next steps
Role Based Access Control
Manage access using Azure Powershell
Manage access using the Azure CLI
RBAC Built in Roles
Manage Role-Based Access Control with Azure
PowerShell
You can use Role-Based Access Control (RBAC) in the Azure portal and Azure Resource Management API to
manage access to your subscription at a fine-grained level. With this feature, you can grant access for Active
Directory users, groups, or service principals by assigning some roles to them at a particular scope.
Before you can use PowerShell to manage RBAC, you need the following prerequisites:
Azure PowerShell version 0.8.8 or later. To install the latest version and associate it with your Azure
subscription, see how to install and configure Azure PowerShell.
Azure Resource Manager cmdlets. Install the Azure Resource Manager cmdlets in PowerShell.
List roles
List all available roles
To list RBAC roles that are available for assignment and to inspect the operations to which they grant access, use
Get-AzureRmRoleDefinition .
Get-AzureRmRoleDefinition | FT Name, Description
List actions of a role

To list the actions for a specific role, use Get-AzureRmRoleDefinition <role name> .
Get-AzureRmRoleDefinition Contributor | FL Actions, NotActions
(Get-AzureRmRoleDefinition "Virtual Machine Contributor").Actions

See who has access
To list RBAC access assignments, use Get-AzureRmRoleAssignment .
List role assignments at a specific scope
You can see all the access assignments for a specified subscription, resource group, or resource. For example, to
see the all the active assignments for a resource group, use
Get-AzureRmRoleAssignment -ResourceGroupName <resource group name> .
Get-AzureRmRoleAssignment -ResourceGroupName Pharma-Sales-ProjectForcast | FL DisplayName,

RoleDefinitionName, Scope
List roles assigned to a user

To list all the roles that are assigned to a specified user and the roles that are assigned to the groups to which the
user belongs, use Get-AzureRmRoleAssignment -SignInName <User email> -ExpandPrincipalGroups .
Get-AzureRmRoleAssignment -SignInName sameert@aaddemo.com | FL DisplayName, RoleDefinitionName, Scope
Get-AzureRmRoleAssignment -SignInName sameert@aaddemo.com -ExpandPrincipalGroups | FL DisplayName,

RoleDefinitionName, Scope
List classic service administrator and coadmin role assignments

To list access assignments for the classic subscription administrator and coadministrators, use:
Get-AzureRmRoleAssignment -IncludeClassicAdministrators
Grant access
Search for object IDs
To assign a role, you need to identify both the object (user, group, or application) and the scope.
If you don't know the subscription ID, you can find it in the Subscriptions blade on the Azure portal. To learn how
to query for the subscription ID, see Get-AzureSubscription on MSDN.
To get the object ID for an Azure AD group, use:
Get-AzureRmADGroup -SearchString <group name in quotes>
To get the object ID for an Azure AD service principal or application, use:
Get-AzureRmADServicePrincipal -SearchString <service name in quotes>
Assign a role to an application at the subscription scope

To grant access to an application at the subscription scope, use:
New-AzureRmRoleAssignment -ObjectId <application id> -RoleDefinitionName <role name> -Scope <subscription id>
Assign a role to a user at the resource group scope
To grant access to a user at the resource group scope, use:
New-AzureRmRoleAssignment -SignInName <email of user> -RoleDefinitionName <role name in quotes> -

ResourceGroupName <resource group name>
Assign a role to a group at the resource scope

To grant access to a group at the resource scope, use:
New-AzureRmRoleAssignment -ObjectId <object id> -RoleDefinitionName <role name in quotes> -ResourceName

<resource name> -ResourceType <resource type> -ParentResource <parent resource> -ResourceGroupName <resource
group name>
Remove access
To remove access for users, groups, and applications, use:
Remove-AzureRmRoleAssignment -ObjectId <object id> -RoleDefinitionName <role name> -Scope <scope such as
subscription id>
Create a custom role

To create a custom role, use the New-AzureRmRoleDefinition command. There are two methods of structuring the
role, using PSRoleDefinitionObject or a JSON template.
Get Actions for a Resource Provider

When You are creating custom roles from scratch, it is important to know all the possible operations from the
resource providers. Use the Get-AzureRMProviderOperation command to get this information. For example, if you
want to check all the available operations for virtual Machine use this command:
Get-AzureRMProviderOperation "Microsoft.Compute/virtualMachines/*" | FT OperationName, Operation ,
Description -AutoSize
Create role with PSRoleDefinitionObject

When you use PowerShell to create a custom role, you can start from scratch or use one of the built-in roles as a
starting point. The example in this section starts with a built-in role and then customizes it with more privileges.
Edit the attributes to add the Actions, notActions, or scopes that you want, and then save the changes as a new
role.
The following example starts with the Virtual Machine Contributor role and uses that to create a custom role
called Virtual Machine Operator. The new role grants access to all read operations of Microsoft.Compute,
Microsoft.Storage, and Microsoft.Network resource providers and grants access to start, restart, and monitor
virtual machines. The custom role can be used in two subscriptions.
$role = Get-AzureRmRoleDefinition "Virtual Machine Contributor"

$role.Id = $null
$role.Name = "Virtual Machine Operator"
$role.Description = "Can monitor and restart virtual machines."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/*/read")
$role.Actions.Add("Microsoft.Network/*/read")
$role.Actions.Add("Microsoft.Compute/*/read")
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/action")
$role.Actions.Add("Microsoft.Authorization/*/read")
$role.Actions.Add("Microsoft.Resources/subscriptions/resourceGroups/read")
$role.Actions.Add("Microsoft.Insights/alertRules/*")
$role.Actions.Add("Microsoft.Support/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e")
$role.AssignableScopes.Add("/subscriptions/e91d47c4-76f3-4271-a796-21b4ecfe3624")
New-AzureRmRoleDefinition -Role $role
Create role with JSON template

A JSON template can be used as the source definition for the custom role. The following example creates a
custom role that allows read access to storage and compute resources, access to support, and adds that role to
two subscriptions. Create a new file C:\CustomRoles\customrole1.json with the following example. The Id should
be set to null on initial role creation as a new ID is generated automatically.
{
"Name": "Custom Role 1",
"Id": null,
"IsCustom": true,
"Description": "Allows for read access to Azure storage and compute resources and access to support",
"Actions": [
],
"NotActions": [
],
"/subscriptions/e91d47c4-76f3-4271-a796-21b4ecfe3624"
]
}
To add the role to the subscriptions, run the following PowerShell command:
New-AzureRmRoleDefinition -InputFile "C:\CustomRoles\customrole1.json"
Modify a custom role

Similar to creating a custom role, you can modify an existing custom role using either the PSRoleDefinitionObject
or a JSON template.
Modify role with PSRoleDefinitionObject
To modify a custom role, first, use the Get-AzureRmRoleDefinition command to retrieve the role definition.
Second, make the desired changes to the role definition. Finally, use the Set-AzureRmRoleDefinition command to
save the modified role definition.
The following example adds the Microsoft.Insights/diagnosticSettings/* operation to the Virtual Machine
Operator custom role.
$role = Get-AzureRmRoleDefinition "Virtual Machine Operator"

$role.Actions.Add("Microsoft.Insights/diagnosticSettings/*")
Set-AzureRmRoleDefinition -Role $role
The following example adds an Azure subscription to the assignable scopes of the Virtual Machine Operator
custom role.
Get-AzureRmSubscription - SubscriptionName Production3
$role = Get-AzureRmRoleDefinition "Virtual Machine Operator"

$role.AssignableScopes.Add("/subscriptions/34370e90-ac4a-4bf9-821f-85eeedead1a2")
Set-AzureRmRoleDefinition -Role $role
Modify role with JSON template

Using the previous JSON template, you can easily modify an existing custom role to add or remove Actions.
Update the JSON template and add the read action for networking as shown in the following example. The
definitions listed in the template are not cumulatively applied to an existing definition, meaning that the role
appears exactly as you specify in the template. You also need to update the Id field with the ID of the role. If you
aren't sure what this value is, you can use the Get-AzureRmRoleDefinition cmdlet to get this information.
{
"Name": "Custom Role 1",
"Id": "acce7ded-2559-449d-bcd5-e9604e50bad1",
"IsCustom": true,
"Description": "Allows for read access to Azure storage and compute resources and access to support",
"Actions": [
],
"NotActions": [
],
"/subscriptions/e91d47c4-76f3-4271-a796-21b4ecfe3624"
]
}
To update the existing role, run the following PowerShell command:
Set-AzureRmRoleDefinition -InputFile "C:\CustomRoles\customrole1.json"
Delete a custom role

To delete a custom role, use the Remove-AzureRmRoleDefinition command.
The following example removes the Virtual Machine Operator custom role.
Get-AzureRmRoleDefinition "Virtual Machine Operator"
Get-AzureRmRoleDefinition "Virtual Machine Operator" | Remove-AzureRmRoleDefinition
List custom roles

To list the roles that are available for assignment at a scope, use the Get-AzureRmRoleDefinition command.
The following example lists all roles that are available for assignment in the selected subscription.
Get-AzureRmRoleDefinition | FT Name, IsCustom
In the following example, the Virtual Machine Operator custom role isn’t available in the Production4 subscription
because that subscription isn’t in the AssignableScopes of the role.
See also
Using Azure PowerShell with Azure Resource Manager * Role Based Access Control * Manage access using
Azure Powershell * Manage access using the Azure CLI * RBAC Built in Roles
Manage Role-Based Access Control with the REST API
Role-Based Access Control (RBAC) in the Azure portal and Azure Resource Manager API helps you manage access to your subscription and
resources at a fine-grained level. With this feature, you can grant access for Active Directory users, groups, or service principals by assigning
some roles to them at a particular scope.
List all role assignments

Lists all the role assignments at the specified scope and subscopes.
To list role assignments, you must have access to Microsoft.Authorization/roleAssignments/read operation at the scope. All the built-in roles are
granted access to this operation. For more information about role assignments and managing access for Azure resources, see Azure Role-Based
Access Control.
Request
Use the GET method with the following URI:
https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments?api-version={api-version}&$filter={filter}
Within the URI, make the following substitutions to customize your request:
1. Replace {scope} with the scope for which you wish to list the role assignments. The following examples show how to specify the scope for
different levels:
Subscription: /subscriptions/{subscription-id}
Resource Group: /subscriptions/{subscription-id}/resourceGroups/myresourcegroup1
Resource: /subscriptions/{subscription-id}/resourceGroups/myresourcegroup1/providers/Microsoft.Web/sites/mysite1
2. Replace {api-version} with 2015-07-01.
3. Replace {filter} with the condition that you wish to apply to filter the role assignment list:
List role assignments for only the specified scope, not including the role assignments at subscopes: atScope()
List role assignments for a specific user, group, or application: principalId%20eq%20'{objectId of user, group, or service principal}'
List role assignments for a specific user, including ones inherited from groups | assignedTo('{objectId of user}')
Response
Status code: 200
{
"value": [
{
"properties": {
"roleDefinitionId": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-
3385-48ef-bd42-f606fba81ae7",
"principalId": "2f9d4375-cbf1-48e8-83c9-2a0be4cb33fb",
"scope": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e",
"createdOn": "2015-10-08T07:28:24.3905077Z",
"updatedOn": "2015-10-08T07:28:24.3905077Z",
"createdBy": "877f0ab8-9c5f-420b-bf88-a1c6c7e2643e",
"updatedBy": "877f0ab8-9c5f-420b-bf88-a1c6c7e2643e"
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleAssignments/baa6e199-ad19-4667-b768-
623fde31aedd",
"type": "Microsoft.Authorization/roleAssignments",
"name": "baa6e199-ad19-4667-b768-623fde31aedd"
}
],
"nextLink": null
}
Get information about a role assignment

Gets information about a single role assignment specified by the role assignment identifier.
To get information about a role assignment, you must have access to Microsoft.Authorization/roleAssignments/read operation. All the built-in
roles are granted access to this operation. For more information about role assignments and managing access for Azure resources, see Azure
Role-Based Access Control.
Request
https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments/{role-assignment-id}?api-version={api-version}
different levels:
2. Replace {role-assignment-id} with the GUID identifier of the role assignment.
Response
Status code: 200
{
"properties": {
"roleDefinitionId": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-
6180-42a0-ab88-20f7382dd24c",
"principalId": "672f1afa-526a-4ef6-819c-975c7cd79022",
"scope": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e",
"createdOn": "2015-10-05T08:36:26.4014813Z",
"updatedOn": "2015-10-05T08:36:26.4014813Z",
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleAssignments/196965ae-6088-4121-a92a-
f1e33fdcc73e",
"name": "196965ae-6088-4121-a92a-f1e33fdcc73e"
}
Create a Role Assignment

Create a role assignment at the specified scope for the specified principal granting the specified role.
To create a role assignment, you must have access to Microsoft.Authorization/roleAssignments/write operation. Of the built-in roles, only Owner
and User Access Administrator are granted access to this operation. For more information about role assignments and managing access for Azure
resources, see Azure Role-Based Access Control.
Request
Use the PUT method with the following URI:
1. Replace {scope} with the scope at which you wish to create the role assignments. When you create a role assignment at a parent scope, all
child scopes inherit the same role assignment. The following examples show how to specify the scope for different levels:
2. Replace {role-assignment-id} with a new GUID, which becomes the GUID identifier of the new role assignment.
For the request body, provide the values in the following format:
{
"properties": {
"roleDefinitionId": "/subscriptions/c276fc76-9cd4-44c9-99a7-
4fd71546436e/resourceGroups/Network/providers/Microsoft.Network/virtualNetworks/EASTUS-VNET-01/subnets/Devices-Engineering-
ProjectRND/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-173b1dc7cf3c",
"principalId": "5ac84765-1c8c-4994-94b2-629461bd191b"
}
}
ELEMENT NAME REQUIRED TYPE DESCRIPTION
roleDefinitionId Yes String The identifier of the role. The format

of the identifier is:
{scope}/providers/Microsoft.Authorization/roleDefi
definition-id-guid}
principalId Yes String objectId of the Azure AD principal

(user, group, or service principal) to
which the role is assigned.
Response
Status code: 201
{
"properties": {
"roleDefinitionId": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/9980e02c-
c2be-4d73-94e8-173b1dc7cf3c",
"principalId": "5ac84765-1c8c-4994-94b2-629461bd191b",
"scope": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network/providers/Microsoft.Network/virtualNetworks/EASTUS-
VNET-01/subnets/Devices-Engineering-ProjectRND",
"createdOn": "2015-12-16T00:27:19.6447515Z",
"updatedOn": "2015-12-16T00:27:19.6447515Z",
"createdBy": null,
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network/providers/Microsoft.Network/virtualNetworks/EASTUS-VNET-
01/subnets/Devices-Engineering-ProjectRND/providers/Microsoft.Authorization/roleAssignments/2e9e86c8-0e91-4958-b21f-20f51f27bab2",
"name": "2e9e86c8-0e91-4958-b21f-20f51f27bab2"
}
Delete a Role Assignment

Delete a role assignment at the specified scope.
To delete a role assignment, you must have access to the Microsoft.Authorization/roleAssignments/delete operation. Of the built-in roles, only
Owner and User Access Administrator are granted access to this operation. For more information about role assignments and managing access
for Azure resources, see Azure Role-Based Access Control.
Request
Use the DELETE method with the following URI:
1. Replace {scope} with the scope at which you wish to create the role assignments. The following examples show how to specify the scope
for different levels:
2. Replace {role-assignment-id} with the role assignment id GUID.
Response
Status code: 200
{
"properties": {
"roleDefinitionId": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/9980e02c-
c2be-4d73-94e8-173b1dc7cf3c",
"principalId": "5ac84765-1c8c-4994-94b2-629461bd191b",
"scope": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network/providers/Microsoft.Network/virtualNetworks/EASTUS-
VNET-01/subnets/Devices-Engineering-ProjectRND",
"createdOn": "2015-12-17T23:21:40.8921564Z",
"updatedOn": "2015-12-17T23:21:40.8921564Z",
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/resourceGroups/Network/providers/Microsoft.Network/virtualNetworks/EASTUS-VNET-
01/subnets/Devices-Engineering-ProjectRND/providers/Microsoft.Authorization/roleAssignments/5eec22ee-ea5c-431e-8f41-82c560706fd2",
"name": "5eec22ee-ea5c-431e-8f41-82c560706fd2"
}
List all Roles

Lists all the roles that are available for assignment at the specified scope.
To list roles, you must have access to Microsoft.Authorization/roleDefinitions/read operation at the scope. All the built-in roles are granted
access to this operation. For more information about role assignments and managing access for Azure resources, see Azure Role-Based Access
Control.
Request
https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleDefinitions?api-version={api-version}&$filter={filter}
1. Replace {scope} with the scope for which you wish to list the roles. The following examples show how to specify the scope for different
levels:
Resource /subscriptions/{subscription-id}/resourceGroups/myresourcegroup1/providers/Microsoft.Web/sites/mysite1
3. Replace {filter} with the condition that you wish to apply to filter the list of roles:
List roles available for assignment at the specified scope and any of its child scopes: atScopeAndBelow()
Search for a role using exact display name: roleName%20eq%20'{role-display-name}' . Use the URL encoded form of the exact display
name of the role. For instance, $filter=roleName%20eq%20'Virtual%20Machine%20Contributor' |
Response
Status code: 200
{
"value": [
{
"properties": {
"roleName": "Virtual Machine Contributor",
"type": "BuiltInRole",
"description": "Lets you manage virtual machines, but not access to them, and not the virtual network or storage account
they\u2019re connected to.",
"assignableScopes": [
"/"
],
"permissions": [
{
"actions": [
"Microsoft.Compute/availabilitySets/*",
"Microsoft.Compute/locations/*",
"Microsoft.Compute/virtualMachines/*",
"Microsoft.Compute/virtualMachineScaleSets/*",
"Microsoft.Network/applicationGateways/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/inboundNatPools/join/action",
"Microsoft.Network/loadBalancers/inboundNatRules/join/action",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/locations/*",
"Microsoft.Network/networkInterfaces/*",
"Microsoft.Network/networkSecurityGroups/join/action",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/publicIPAddresses/join/action",
"Microsoft.Network/publicIPAddresses/read",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/virtualNetworks/subnets/join/action",
"Microsoft.Resources/deployments/*",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/read",
],
"notActions": []
}
],
"createdOn": "2015-06-02T00:18:27.3542698Z",
"updatedOn": "2015-12-08T03:16:55.6170255Z",
"createdBy": null,
"updatedBy": null
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-
173b1dc7cf3c",
"type": "Microsoft.Authorization/roleDefinitions",
"name": "9980e02c-c2be-4d73-94e8-173b1dc7cf3c"
}
],
"nextLink": null
}
Get information about a Role

Gets information about a single role specified by the role definition identifier. To get information about a single role using its display name, see
List all roles.
To get information about a role, you must have access to Microsoft.Authorization/roleDefinitions/read operation. All the built-in roles are
granted access to this operation. For more information about role assignments and managing access for Azure resources, see Azure Role-Based
Access Control.
Request
https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleDefinitions/{role-definition-id}?api-version={api-version}
different levels:
2. Replace {role-definition-id} with the GUID identifier of the role definition.
Response
Status code: 200
{
"value": [
{
"properties": {
"roleName": "Virtual Machine Contributor",
"type": "BuiltInRole",
"description": "Lets you manage virtual machines, but not access to them, and not the virtual network or storage account
they\u2019re connected to.",
"/"
],
"permissions": [
{
"actions": [
"Microsoft.Compute/availabilitySets/*",
"Microsoft.Compute/locations/*",
"Microsoft.Compute/virtualMachines/*",
"Microsoft.Compute/virtualMachineScaleSets/*",
"Microsoft.Network/applicationGateways/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/inboundNatPools/join/action",
"Microsoft.Network/loadBalancers/inboundNatRules/join/action",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/locations/*",
"Microsoft.Network/networkInterfaces/*",
"Microsoft.Network/networkSecurityGroups/join/action",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/publicIPAddresses/join/action",
"Microsoft.Network/publicIPAddresses/read",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/virtualNetworks/subnets/join/action",
"Microsoft.Resources/deployments/*",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/read",
],
"notActions": []
}
],
"createdOn": "2015-06-02T00:18:27.3542698Z",
"updatedOn": "2015-12-08T03:16:55.6170255Z",
"createdBy": null,
"updatedBy": null
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/9980e02c-c2be-4d73-94e8-
173b1dc7cf3c",
"name": "9980e02c-c2be-4d73-94e8-173b1dc7cf3c"
}
],
"nextLink": null
}
Create a Custom Role

Create a custom role.
To create a custom role, you must have access to Microsoft.Authorization/roleDefinitions/write operation on all the AssignableScopes . Of the
built-in roles, only Owner and User Access Administrator are granted access to this operation. For more information about role assignments and
managing access for Azure resources, see Azure Role-Based Access Control.
Request
1. Replace {scope} with the first AssignableScope of the custom role. The following examples show how to specify the scope for different
levels.
2. Replace {role-definition-id} with a new GUID, which becomes the GUID identifier of the new custom role.
{
"name": "7c8c8ccd-9838-4e42-b38c-60f0bbe9a9d7",
"properties": {
"roleName": "Virtual Machine Operator",
"description": "Lets you monitor virtual machines and restart them.",
"type": "CustomRole",
"permissions": [
{
"actions": [
"Microsoft.Support/*",
"Microsoft.Compute/virtualMachines/restart/action"
],
"notActions": []
}
],
"/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e"
]
}
}
name Yes String GUID identifier of the custom role.
properties.roleName Yes String Display name of the custom role.

Maximum size 128 characters.
properties.description No String Description of the custom role.

Maximum size 1024 characters.
properties.type Yes String Set to "CustomRole."
properties.permissions.actions Yes String[] An array of action strings specifying

the operations granted by the
custom role.
properties.permissions.notActions No String[] An array of action strings specifying

the operations to exclude from the
operations granted by the custom
role.
properties.assignableScopes Yes String[] An array of scopes in which the

custom role can be used.
Response
Status code: 201
{
"properties": {
],
"permissions": [
{
"actions": [
],
"notActions": []
}
],
"createdOn": "2015-12-18T00:10:51.4662695Z",
"updatedOn": "2015-12-18T00:10:51.4662695Z",
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/7c8c8ccd-9838-4e42-b38c-
60f0bbe9a9d7",
"name": "7c8c8ccd-9838-4e42-b38c-60f0bbe9a9d7"
}
Update a Custom Role

Modify a custom role.
To modify a custom role, you must have access to Microsoft.Authorization/roleDefinitions/write operation on all the AssignableScopes . Of the
Request
1. Replace {scope} with the first AssignableScope of the custom role. The following examples show how to specify the scope for different
levels:
2. Replace {role-definition-id} with the GUID identifier of the custom role.
{
"name": "7c8c8ccd-9838-4e42-b38c-60f0bbe9a9d7",
"properties": {
"permissions": [
{
"actions": [
],
"notActions": []
}
],
]
}
}
name Yes String GUID identifier of the custom role.
properties.roleName Yes String Display name of the updated custom

role.
properties.description No String Description of the updated custom

role.
properties.type Yes String Set to "CustomRole."
properties.permissions.actions Yes String[] An array of action strings specifying

the operations to which the updated
custom role grants access.
properties.permissions.notActions No String[] An array of action strings specifying

the operations to exclude from the
operations which the updated
custom role grants.
properties.assignableScopes Yes String[] An array of scopes in which the

updated custom role can be used.
Response
Status code: 201
{
"properties": {
],
"permissions": [
{
"actions": [
],
"notActions": []
}
],
"createdOn": "2015-12-18T00:10:51.4662695Z",
"updatedOn": "2015-12-18T00:10:51.4662695Z",
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/7c8c8ccd-9838-4e42-b38c-
60f0bbe9a9d7",
"name": "7c8c8ccd-9838-4e42-b38c-60f0bbe9a9d7"
}
Delete a Custom Role

Delete a custom role.
To delete a custom role, you must have access to Microsoft.Authorization/roleDefinitions/delete operation on all the AssignableScopes . Of the
Request
Use the DELETE method with the following URI:
1. Replace {scope} with the scope at which you wish to delete the role definition. The following examples show how to specify the scope for
different levels:
2. Replace {role-definition-id} with the GUID role definition id of the custom role.
Response
Status code: 200
{
"properties": {
],
"permissions": [
{
"actions": [
],
"notActions": []
}
],
"createdOn": "2015-12-16T00:07:02.9236555Z",
"updatedOn": "2015-12-16T00:07:02.9236555Z",
},
"id": "/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e/providers/Microsoft.Authorization/roleDefinitions/0bd62a70-e1b8-4e0b-a7c2-
75cab365c95b",
"name": "0bd62a70-e1b8-4e0b-a7c2-75cab365c95b"
}
Next steps
Role Based Access Control
Manage access using Azure Powershell
Manage access using the Azure CLI
RBAC Built in Roles
Elevate access as a tenant admin with Role-Based
Access Control
Role-based Access Control helps tenant administrators get temporary elevations in access so that they can grant
higher permissions than normal. A tenant admin can elevate herself to the User Access Administrator role when
needed. That role gives the tenant admin permissions to grant herself or others roles at the "/" scope.
This feature is important because it allows the tenant admin to see all the subscriptions that exist in an organization.
It also allows for automation apps like invoicing and auditing to access all the subscriptions and provide an accurate
view of the state of the organization for billing or asset management.
Use elevateAccess for tenant access with Azure AD admin center

1. Go to the Azure Active Directory admin center and log in with you credentials.
2. Choose Properties from the Azure AD left menu.
3. In the Properties blade, find Global admin can manage Azure Subscriptions, choose Yes, then Save.
IMPORTANT
When you choose Yes, assigns the User Access Administrator role at the Root "/" (Root Scope) for the user with
which you are currently logged into the Portal. This allows the user to see all other Azure Subscriptions.
NOTE
When you choose No, removes the User Access Administrator role at the Root "/" (Root Scope) for the user with
which you are currently logged into the Portal.
TIP
The impression is that this is a Global Property for Azure Active Directory, however, it functions on a per-user basis for the
currently logged on user. When you have Global Administrator rights in Azure Active Directory, you can invoke the
elevateAccess feature for the user which you are currently logged into Azure Active Directory Admin Center.
View role assignments at the "/" scope using PowerShell
To view the User Access Administrator assignment at the / scope, use the Get-AzureRmRoleAssignment PowerShell
cmdlet.
Get-AzureRmRoleAssignment* | where {$_.RoleDefinitionName -eq "User Access Administrator" -and $_SignInName -eq
"<username@somedomain.com>" -and $_.Scope -eq "/"}
Example output:
RoleAssignmentId : /providers/Microsoft.Authorization/roleAssignments/098d572e-c1e5-43ee-84ce-
8dc459c7e1f0
Scope : /
DisplayName : username
SignInName : username@somedomain.com
RoleDefinitionName : User Access Administrator
RoleDefinitionId : 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9
ObjectId : d65fd0e9-c185-472c-8f26-1dafa01f72cc
ObjectType : User
Delete the role assignment at "/" scope using Powershell:
You can delete the assignment using following PowerShell cmdlet:
Remove-AzureRmRoleAssignment -SignInName <username@somedomain.com> -RoleDefinitionName "User Access

Administrator" -Scope "/"
Use elevateAccess to give tenant access with the REST API

The basic process works with the following steps:
1. Using REST, call elevateAccess, which grants you the User Access Administrator role at "/" scope.
POST https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01
2. Create a role assignment to assign any role at any scope. The following example shows the properties for
assigning the Reader role at "/" scope:
{ "properties":{
"roleDefinitionId":
"providers/Microsoft.Authorization/roleDefinitions/acdd72a7338548efbd42f606fba81ae7",
"principalId": "cbc5e050-d7cd-4310-813b-4870be8ef5bb",
"scope": "/"
},
"id": "providers/Microsoft.Authorization/roleAssignments/64736CA0-56D7-4A94-A551-973C2FE7888B",
"name": "64736CA0-56D7-4A94-A551-973C2FE7888B"
}
3. While a User Access Admin, you can also delete role assignments at "/" scope.
4. Revoke your User Access Admin privileges until they're needed again.
How to undo the elevateAccess action with the REST API

When you call elevateAccess you create a role assignment for yourself, so to revoke those privileges you need to
delete the assignment.
1. Call GET role definitions where roleName = User Access Administrator to determine the name GUID of the
User Access Administrator role.
a. GET https://management.azure.com/providers/Microsoft.Authorization/roleDefinitions?api-
version=2015-07-01&$filter=roleName+eq+'User+Access+Administrator
{"value":[{"properties":{
"roleName":"User Access Administrator",
"type":"BuiltInRole",
"description":"Lets you manage user access to Azure resources.",
"assignableScopes":["/"],
"permissions":[{"actions":
["*/read","Microsoft.Authorization/*","Microsoft.Support/*"],"notActions":[]}],
"createdOn":"0001-01-01T08:00:00.0000000Z",
"updatedOn":"2016-05-31T23:14:04.6964687Z",
"createdBy":null,
"updatedBy":null},
"id":"/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
"type":"Microsoft.Authorization/roleDefinitions",
"name":"18d7d88d-d35e-4fb5-a5c3-7773c20a72d9"}],
"nextLink":null}
Save the GUID from the name parameter, in this case 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9.
2. You also need to list the role assignment for tenant admin at tenant scope. List all assignments at tenant
scope for the PrincipalId of the TenantAdmin who made the elevate access call. This will list all assignments
in the tenant for the ObjectID.
a. GET https://management.azure.com/providers/Microsoft.Authorization/roleAssignments?api-
version=2015-07-01&$filter=principalId+eq+'{objectid}'
NOTE
A tenant admin should not have many assignments, if the query above returns too many assignments, you
can also query for all assignments just at tenant scope level, then filter the results: GET
https://management.azure.com/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-
01&$filter=atScope()
b. The above calls return a list of role assignments. Find the role assignment where the scope is "/" and
the RoleDefinitionId ends with the role name GUID you found in step 1 and PrincipalId matches the
ObjectId of the Tenant Admin. The role assignment looks like this:
{"value":[{"properties":{
"roleDefinitionId":"/providers/Microsoft.Authorization/roleDefinitions/18d7d88d-d35e-4fb5-a5c3-
7773c20a72d9",
"principalId":"{objectID}",
"scope":"/",
"createdOn":"2016-08-17T19:21:16.3422480Z",
"updatedOn":"2016-08-17T19:21:16.3422480Z",
"createdBy":"93ce6722-3638-4222-b582-78b75c5c6d65",
"updatedBy":"93ce6722-3638-4222-b582-78b75c5c6d65"},
"id":"/providers/Microsoft.Authorization/roleAssignments/e7dd75bc-06f6-4e71-9014-ee96a929d099",
"type":"Microsoft.Authorization/roleAssignments",
"name":"e7dd75bc-06f6-4e71-9014-ee96a929d099"}],
"nextLink":null}
Again, save the GUID from the name parameter, in this case e7dd75bc-06f6-4e71-9014-
ee96a929d099.
c. Finally, Use the highlighted RoleAssignment ID to delete the assignment added by Elevate Access:
DELETE https://management.azure.com
/providers/Microsoft.Authorization/roleAssignments/e7dd75bc-06f6-4e71-9014-ee96a929d099?api-
version=2015-07-01
Next steps
Learn more about managing Role-Based Access Control with REST
Manage access assignments in the Azure portal
Troubleshooting Azure role-based access control
This document article answers common questions about the specific access rights that are granted with roles, so
that you know what to expect when using the roles in the Azure portal and can troubleshoot access problems.
These three roles cover all resource types:
Owner
Contributor
Reader
Owners and contributors both have full access to the management experience, but a contributor can’t give access
to other users or groups. Things get a little more interesting with the reader role, so that’s where we'll spend some
time. See the Role-Based Access Control get-started article for details on how to grant access.
App service workloads

Write access capabilities
If you grant a user read-only access to a single web app, some features are disabled that you might not expect. The
following management capabilities require write access to a web app (either Contributor or Owner), and aren’t
available in any read-only scenario.
Commands (like start, stop, etc.)
Changing settings like general configuration, scale settings, backup settings, and monitoring settings
Accessing publishing credentials and other secrets like app settings and connection strings
Streaming logs
Diagnostic logs configuration
Console (command prompt)
Active and recent deployments (for local git continuous deployment)
Estimated spend
Web tests
Virtual network (only visible to a reader if a virtual network has previously been configured by a user with write
access).
If you can't access any of these tiles, you need to ask your administrator for Contributor access to the web app.
Dealing with related resources
Web apps are complicated by the presence of a few different resources that interplay. Here is a typical resource
group with a couple websites:
As a result, if you grant someone access to just the web app, much of the functionality on the website blade in the
Azure portal is disabled.
These items require write access to the App Service plan that corresponds to your website:
Viewing the web app’s pricing tier (Free or Standard)
Scale configuration (number of instances, virtual machine size, autoscale settings)
Quotas (storage, bandwidth, CPU)
These items require write access to the whole Resource group that contains your website:
SSL Certificates and bindings (SSL certificates can be shared between sites in the same resource group and geo-
location)
Alert rules
Autoscale settings
Application insights components
Web tests
Virtual machine workloads

Much like with web apps, some features on the virtual machine blade require write access to the virtual machine, or
to other resources in the resource group.
Virtual machines are related to Domain names, virtual networks, storage accounts, and alert rules.
These items require write access to the Virtual machine:
Endpoints
IP addresses
Disks
Extensions
These require write access to both the Virtual machine, and the Resource group (along with the Domain name)
that it is in:
Availability set
Load balanced set
Alert rules
If you can't access any of these tiles, ask your administrator for Contributor access to the Resource group.
See more
Role Based Access Control: Get started with RBAC in the Azure portal.
Built-in roles: Get details about the roles that come standard in RBAC.
Custom roles in Azure RBAC: Learn how to create custom roles to fit your access needs.
Create an access change history report: Keep track of changing role assignments in RBAC.
Azure Resource Manager Resource Provider
operations
This document lists the operations available for each Microsoft Azure Resource Manager resource provider. These
can be used in custom roles to provide granular Role-Based Access Control (RBAC) permissions to resources in
Azure. Please note this is not a comprehensive list and operations may be added or removed as each provider is
updated. Operation strings follow the format of Microsoft.<ProviderName>/<ChildResourceType>/<action> .
NOTE
For a comprehensive and current list please use Get-AzureRmProviderOperation (in PowerShell) or
az provider operation list (in Azure CLI v2) to list operations of Azure resource providers.
Microsoft.ADHybridHealthService
OPERATION DESCRIPTION
/configuration/action Updates Tenant Configuration.
/services/action Updates a service instance in the tenant.
/configuration/write Creates a Tenant Configuration.
/configuration/read Reads the Tenant Configuration.
/services/write Creates a service instance in the tenant.
/services/read Reads the service instances in the tenant.
/services/delete Deletes a service instance in the tenant.
/services/servicemembers/action Creates a service member instance in the service.
/services/servicemembers/read Reads the service member instance in the service.
/services/servicemembers/delete Deletes a service member instance in the service.
/services/servicemembers/alerts/read Reads the alerts for a service member.
/services/alerts/read Reads the alerts for a service.
/services/alerts/read Reads the alerts for a service.
Microsoft.Advisor
/generateRecommendations/action Generates recommendations
/suppressions/action Creates/updates suppressions
/register/action Registers the subscription for the Microsoft Advisor
/generateRecommendations/read Gets generate recommendations status
/recommendations/read Reads recommendations
/suppressions/read Gets suppressions
/suppressions/delete Deletes suppression
Microsoft.AnalysisServices
/servers/read Retrieves the information of the specified Analysis Server.
/servers/write Creates or updates the specified Analysis Server.
/servers/delete Deletes the Analysis Server.
/servers/suspend/action Suspends the Analysis Server.
/servers/resume/action Resumes the Analysis Server.
/servers/checkNameAvailability Checks that given Analysis Server name is valid and not in use.
/action
Microsoft.ApiManagement
/checkNameAvailability/action Checks if provided service name is available
/register/action Register subscription for Microsoft.ApiManagement resource

provider
/unregister/action Un-register subscription for Microsoft.ApiManagement

resource provider
/service/write Create a new instance of API Management Service
/service/read Read metadata for an API Management Service instance
/service/delete Delete API Management Service instance

/service/updatehostname/action Setup, update or remove custom domain names for an API

Management Service
/service/uploadcertificate/action Upload SSL certificate for an API Management Service
/service/backup/action Backup API Management Service to the specified container in

a user provided storage account
/service/restore/action Restore API Management Service from the specified container

in a user provided storage account
/service/managedeployments/action Change SKU/units, add/remove regional deployments of API

Management Service
/service/getssotoken/action Gets SSO token that can be used to login into API
Management Service Legacy portal as an administrator
/service/applynetworkconfigurationupdates/action Updates the Microsoft.ApiManagement resources running in

Virtual Network to pick updated Network Settings.
/service/operationresults/read Gets current status of long running operation
/service/networkStatus/read Gets the network access status of resources.
/service/loggers/read Get list of loggers or Get details of logger
/service/loggers/write Add new logger or Update existing logger details
/service/loggers/delete Remove existing logger
/service/users/read Get a list of registered users or Get account details of a user
/service/users/write Register a new user or Update account details of an existing

user
/service/users/delete Remove user account
/service/users/generateSsoUrl/action Generate SSO URL. The URL can be used to access admin
portal
/service/users/subscriptions/read Get list of user subscriptions
/service/users/keys/read Get list of user keys
/service/users/groups/read Get list of user groups
/service/tenant/operationResults/read Get list of operation results or Get result of a specific

operation
/service/tenant/policy/read Get policy configuration for the tenant
/service/tenant/policy/write Set policy configuration for the tenant

/service/tenant/policy/delete Remove policy configuration for the tenant
/service/tenant/configuration/save/action Creates commit with configuration snapshot to the specified

branch in the repository
/service/tenant/configuration/deploy/action Runs a deployment task to apply changes from the specified

git branch to the configuration in database.
/service/tenant/configuration/validate/action Validates changes from the specified git branch
/service/tenant/configuration/operationResults/read Get list of operation results or Get result of a specific

operation
/service/tenant/configuration/syncState/read Get status of last git synchronization
/service/tenant/access/read Get tenant access information details
/service/tenant/access/write Update tenant access information details
/service/tenant/access/regeneratePrimaryKey/action Regenerate primary access key
/service/tenant/access/regenerateSecondaryKey/action Regenerate secondary access key
/service/identityProviders/read Get list of Identity providers or Get details of Identity Provider
/service/identityProviders/write Create a new Identity Provider or Update details of an existing

Identity Provider
/service/identityProviders/delete Remove existing Identity Provider
/service/subscriptions/read Get a list of product subscriptions or Get details of product

subscription
/service/subscriptions/write Subscribe an existing user to an existing product or Update

existing subscription details. This operation can be used to
renew subscription
/service/subscriptions/delete Delete subscription. This operation can be used to delete

subscription
/service/subscriptions/regeneratePrimaryKey/action Regenerate subscription primary key
/service/subscriptions/regenerateSecondaryKey/action Regenerate subscription secondary key
/service/backends/read Get list of backends or Get details of backend
/service/backends/write Add a new backend or Update existing backend details
/service/backends/delete Remove existing backend
/service/apis/read Get list of all registered APIs or Get details of API

/service/apis/write Create new API or Update existing API details
/service/apis/delete Remove existing API
/service/apis/policy/read Get policy configuration details for API
/service/apis/policy/write Set policy configuration details for API
/service/apis/policy/delete Remove policy configuration from API
/service/apis/operations/read Get list of existing API operations or Get details of API

operation
/service/apis/operations/write Create new API operation or Update existing API operation
/service/apis/operations/delete Remove existing API operation
/service/apis/operations/policy/read Get policy configuration details for operation
/service/apis/operations/policy/write Set policy configuration details for operation
/service/apis/operations/policy/delete Remove policy configuration from operation
/service/products/read Get list of products or Get details of product
/service/products/write Create new product or Update existing product details
/service/products/delete Remove existing product
/service/products/subscriptions/read Get list of product subscriptions
/service/products/apis/read Get list of APIs added to existing product
/service/products/apis/write Add existing API to existing product
/service/products/apis/delete Remove existing API from existing product
/service/products/policy/read Get policy configuration of existing product
/service/products/policy/write Set policy configuration for existing product
/service/products/policy/delete Remove policy configuration from existing product
/service/products/groups/read Get list of developer groups associated with product
/service/products/groups/write Associate existing developer group with existing product
/service/products/groups/delete Delete association of existing developer group with existing

product
/service/openidConnectProviders/read Get list of OpenID Connect providers or Get details of OpenID

Connect Provider
/service/openidConnectProviders/write Create a new OpenID Connect Provider or Update details of

an existing OpenID Connect Provider
/service/openidConnectProviders/delete Remove existing OpenID Connect Provider
/service/certificates/read Get list of certificates or Get details of certificate
/service/certificates/write Add new certificate
/service/certificates/delete Remove existing certificate
/service/properties/read Gets list of all properties or Gets details of specified property
/service/properties/write Creates a new property or Updates value for specified

property
/service/properties/delete Removes existing property
/service/groups/read Get list of groups or Gets details of a group
/service/groups/write Create new group or Update existing group details
/service/groups/delete Remove existing group
/service/groups/users/read Get list of group users
/service/groups/users/write Add existing user to existing group
/service/groups/users/delete Remove existing user from existing group
/service/authorizationServers/read Get list of authorization servers or Get details of authorization

server
/service/authorizationServers/write Create a new authorization server or Update details of an

existing authorization server
/service/authorizationServers/delete Remove existing authorization server
/service/reports/bySubscription/read Get report aggregated by subscription.
/service/reports/byRequest/read Get requests reporting data
/service/reports/byOperation/read Get report aggregated by operations
/service/reports/byGeo/read Get report aggregated by geographical region
/service/reports/byUser/read Get report aggregated by developers.

/service/reports/byTime/read Get report aggregated by time periods
/service/reports/byApi/read Get report aggregated by APIs
/service/reports/byProduct/read Get report aggregated by products.
Microsoft.Authorization
/elevateAccess/action Grants the caller User Access Administrator access at the

tenant scope
/classicAdministrators/read Reads the administrators for the subscription.
/classicAdministrators/write Add or modify administrator to a subscription.
/classicAdministrators/delete Removes the administrator from the subscription.
/locks/read Gets locks at the specified scope.
/locks/write Add locks at the specified scope.
/locks/delete Delete locks at the specified scope.
/policyAssignments/read Get information about a policy assignment.
/policyAssignments/write Create a policy assignment at the specified scope.
/policyAssignments/delete Delete a policy assignment at the specified scope.
/permissions/read Lists all the permissions the caller has at a given scope.
/roleDefinitions/read Get information about a role definition.
/roleDefinitions/write Create or update a custom role definition with specified

permissions and assignable scopes.
/roleDefinitions/delete Delete the specified custom role definition.
/providerOperations/read Get operations for all resource providers which can be used in
role definitions.
/policyDefinitions/read Get information about a policy definition.
/policyDefinitions/write Create a custom policy definition.
/policyDefinitions/delete Delete a policy definition.
/roleAssignments/read Get information about a role assignment.

/roleAssignments/write Create a role assignment at the specified scope.
/roleAssignments/delete Delete a role assignment at the specified scope.
Microsoft.Automation
/automationAccounts/read Gets an Azure Automation account
/automationAccounts/write Creates or updates an Azure Automation account
/automationAccounts/delete Deletes an Azure Automation account
/automationAccounts/configurations/readContent/action Gets an Azure Automation DSC's content
/automationAccounts/hybridRunbookWorkerGroups/read Reads Hybrid Runbook Worker Resources
/automationAccounts/hybridRunbookWorkerGroups/delete Deletes Hybrid Runbook Worker Resources
/automationAccounts/jobSchedules/read Gets an Azure Automation job schedule
/automationAccounts/jobSchedules/write Creates an Azure Automation job schedule
/automationAccounts/jobSchedules/delete Deletes an Azure Automation job schedule
/automationAccounts/connectionTypes/read Gets an Azure Automation connection type asset
/automationAccounts/connectionTypes/write Creates an Azure Automation connection type asset
/automationAccounts/connectionTypes/delete Deletes an Azure Automation connection type asset
/automationAccounts/modules/read Gets an Azure Automation module
/automationAccounts/modules/write Creates or updates an Azure Automation module
/automationAccounts/modules/delete Deletes an Azure Automation module
/automationAccounts/credentials/read Gets an Azure Automation credential asset
/automationAccounts/credentials/write Creates or updates an Azure Automation credential asset
/automationAccounts/credentials/delete Deletes an Azure Automation credential asset
/automationAccounts/certificates/read Gets an Azure Automation certificate asset
/automationAccounts/certificates/write Creates or updates an Azure Automation certificate asset
/automationAccounts/certificates/delete Deletes an Azure Automation certificate asset

/automationAccounts/schedules/read Gets an Azure Automation schedule asset
/automationAccounts/schedules/write Creates or updates an Azure Automation schedule asset
/automationAccounts/schedules/delete Deletes an Azure Automation schedule asset
/automationAccounts/jobs/read Gets an Azure Automation job
/automationAccounts/jobs/write Creates an Azure Automation job
/automationAccounts/jobs/stop/action Stops an Azure Automation job
/automationAccounts/jobs/suspend/action Suspends an Azure Automation job
/automationAccounts/jobs/resume/action Resumes an Azure Automation job
/automationAccounts/jobs/runbookContent/action Gets the content of the Azure Automation runbook at the

time of the job execution
/automationAccounts/jobs/output/action Gets the output of a job
/automationAccounts/jobs/read Gets an Azure Automation job
/automationAccounts/jobs/write Creates an Azure Automation job
/automationAccounts/jobs/stop/action Stops an Azure Automation job
/automationAccounts/jobs/suspend/action Suspends an Azure Automation job
/automationAccounts/jobs/resume/action Resumes an Azure Automation job
/automationAccounts/jobs/streams/read Gets an Azure Automation job stream
/automationAccounts/connections/read Gets an Azure Automation connection asset
/automationAccounts/connections/write Creates or updates an Azure Automation connection asset
/automationAccounts/connections/delete Deletes an Azure Automation connection asset
/automationAccounts/variables/read Reads an Azure Automation variable asset
/automationAccounts/variables/write Creates or updates an Azure Automation variable asset
/automationAccounts/variables/delete Deletes an Azure Automation variable asset
/automationAccounts/runbooks/readContent/action Gets the content of an Azure Automation runbook
/automationAccounts/runbooks/read Gets an Azure Automation runbook
/automationAccounts/runbooks/write Creates or updates an Azure Automation runbook

/automationAccounts/runbooks/delete Deletes an Azure Automation runbook
/automationAccounts/runbooks/draft/readContent/action Gets the content of an Azure Automation runbook draft
/automationAccounts/runbooks/draft/writeContent/action Creates the content of an Azure Automation runbook draft
/automationAccounts/runbooks/draft/read Gets an Azure Automation runbook draft
/automationAccounts/runbooks/draft/publish/action Publishes an Azure Automation runbook draft
/automationAccounts/runbooks/draft/undoEdit/action Undo edits to an Azure Automation runbook draft
/automationAccounts/runbooks/draft/testJob/read Gets an Azure Automation runbook draft test job
/automationAccounts/runbooks/draft/testJob/write Creates an Azure Automation runbook draft test job
/automationAccounts/runbooks/draft/testJob/stop/action Stops an Azure Automation runbook draft test job
/automationAccounts/runbooks/draft/testJob/suspend/action Suspends an Azure Automation runbook draft test job
/automationAccounts/runbooks/draft/testJob/resume/action Resumes an Azure Automation runbook draft test job
/automationAccounts/webhooks/read Reads an Azure Automation webhook
/automationAccounts/webhooks/write Creates or updates an Azure Automation webhook
/automationAccounts/webhooks/delete Deletes an Azure Automation webhook
/automationAccounts/webhooks/generateUri/action Generates a URI for an Azure Automation webhook
Microsoft.AzureActiveDirectory
This provider is not a full ARM provider and does not provide any ARM operations.
Microsoft.Batch
/register/action Registers the subscription for the Batch Resource Provider and
enables the creation of Batch accounts
/batchAccounts/write Creates a new Batch account or updates an existing Batch

account
/batchAccounts/read Lists Batch accounts or gets the properties of a Batch account
/batchAccounts/delete Deletes a Batch account
/batchAccounts/listkeys/action Lists access keys for a Batch account

/batchAccounts/regeneratekeys/action Regenerates access keys for a Batch account
/batchAccounts/syncAutoStorageKeys/action Synchronizes access keys for the auto storage account

configured for a Batch account
/batchAccounts/applications/read Lists applications or gets the properties of an application
/batchAccounts/applications/write Creates a new application or updates an existing application
/batchAccounts/applications/delete Deletes an application
/batchAccounts/applications/versions/read Gets the properties of an application package
/batchAccounts/applications/versions/write Creates a new application package or updates an existing

application package
/batchAccounts/applications/versions/activate/action Activates an application package
/batchAccounts/applications/versions/delete Deletes an application package
/locations/quotas/read Gets Batch quotas of the specified subscription at the specified

Azure region
Microsoft.Billing
/invoices/read Lists available invoices
Microsoft.BingMaps
/mapApis/Read Read Operation
/mapApis/Write Write Operation
/mapApis/Delete Delete Operation
/mapApis/regenerateKey/action Regenerates the Key
/mapApis/listSecrets/action List the Secrets
/mapApis/listSingleSignOnToken/action Read Single Sign On Authorization Token For The Resource
/Operations/read Description of the operation.
Microsoft.Cache
/checknameavailability/action Checks if a name is available for use with a new Redis Cache
/register/action Registers the 'Microsoft.Cache' resource provider with a

subscription
/unregister/action Unregisters the 'Microsoft.Cache' resource provider with a

subscription
/redis/write Modify the Redis Cache's settings and configuration in the

management portal
/redis/read View the Redis Cache's settings and configuration in the

management portal
/redis/delete Delete the entire Redis Cache
/redis/listKeys/action View the value of Redis Cache access keys in the management
portal
/redis/regenerateKey/action Change the value of Redis Cache access keys in the

management portal
/redis/import/action Import data of a specified format from multiple blobs into

Redis
/redis/export/action Export Redis data to prefixed storage blobs in specified format
/redis/forceReboot/action Force reboot a cache instance, potentially with data loss.
/redis/stop/action Stop a cache instance.
/redis/start/action Start a cache instance.
/redis/metricDefinitions/read Gets the available metrics for a Redis Cache
/redis/firewallRules/read Get the IP firewall rules of a Redis Cache
/redis/firewallRules/write Edit the IP firewall rules of a Redis Cache
/redis/firewallRules/delete Delete IP firewall rules of a Redis Cache
/redis/listUpgradeNotifications/read List the latest Upgrade Notifications for the cache tenant.
/redis/linkedservers/read Get Linked Servers associated with a redis cache.
/redis/linkedservers/write Add Linked Server to a Redis Cache
/redis/linkedservers/delete Delete Linked Server from a Redis Cache
/redis/patchSchedules/read Gets the patching schedule of a Redis Cache

/redis/patchSchedules/write Modify the patching schedule of a Redis Cache
/redis/patchSchedules/delete Delete the patch schedule of a Redis Cache
Microsoft.CertificateRegistration
/provisionGlobalAppServicePrincipalInUserTenant/Action Provision service principal for service app principal
/validateCertificateRegistrationInformation/Action Validate certificate purchase object without submitting it
/register/action Register the Microsoft Certificates resource provider for the

subscription
/certificateOrders/Write Add a new certificateOrder or update an existing one
/certificateOrders/Delete Delete an existing AppServiceCertificate
/certificateOrders/Read Get the list of CertificateOrders
/certificateOrders/reissue/Action Reissue an existing certificateorder
/certificateOrders/renew/Action Renew an existing certificateorder
/certificateOrders/retrieveCertificateActions/Action Retrieve the list of certificate actions
/certificateOrders/retrieveEmailHistory/Action Retrieve certificate email history
/certificateOrders/resendEmail/Action Resend certificate email
/certificateOrders/verifyDomainOwnership/Action Verify domain ownership
/certificateOrders/resendRequestEmails/Action Resend request emails to another email address
/certificateOrders/resendRequestEmails/Action Retrieve site seal for an issued App Service Certificate
/certificateOrders/certificates/Write Add a new certificate or update an existing one
/certificateOrders/certificates/Delete Delete an existing certificate
/certificateOrders/certificates/Read Get the list of certificates
Microsoft.ClassicCompute
/register/action Register to Classic Compute

/checkDomainNameAvailability/action Checks the availability of a given domain name.
/moveSubscriptionResources/action Move all classic resources to a different subscription.
/validateSubscriptionMoveAvailability/action Validate the subscription's availability for classic move

operation.
/operatingSystemFamilies/read Lists the guest operating system families available in Microsoft

Azure, and also lists the operating system versions available
for each f
/capabilities/read Shows the capabilities
/operatingSystems/read Lists the versions of the guest operating system that are
currently available in Microsoft Azure.
/resourceTypes/skus/read Gets the Sku list for supported resource types.
/domainNames/read Return the domain names for resources.
/domainNames/write Add or modify the domain names for resources.
/domainNames/delete Remove the domain names for resources.
/domainNames/swap/action Swaps the staging slot to the production slot.
/domainNames/serviceCertificates/read Returns the service certificates used.
/domainNames/serviceCertificates/write Add or modify the service certificates used.
/domainNames/serviceCertificates/delete Delete the service certificates used.
/domainNames/serviceCertificates/operationStatuses/read Reads the operation status for the domain names service
certificates.
/domainNames/capabilities/read Shows the domain name capabilities
/domainNames/extensions/read Returns the domain name extensions.
/domainNames/extensions/write Add the domain name extensions.
/domainNames/extensions/delete Remove the domain name extensions.
/domainNames/extensions/operationStatuses/read Reads the operation status for the domain names extensions.
/domainNames/active/write Sets the active domain name.
/domainNames/slots/read Shows the deployment slots.
/domainNames/slots/write Creates or update the deployment.

/domainNames/slots/delete Deletes a given deployment slot.
/domainNames/slots/start/action Starts a deployment slot.
/domainNames/slots/stop/action Suspends the deployment slot.
/domainNames/slots/operationStatuses/read Reads the operation status for the domain names slots.
/domainNames/slots/roles/read Get the role for the deployment slot.
/domainNames/slots/roles/extensionReferences/read Returns the extension reference for the deployment slot role.
/domainNames/slots/roles/extensionReferences/write Add or modify the extension reference for the deployment slot
role.
/domainNames/slots/roles/extensionReferences/delete Remove the extension reference for the deployment slot role.
/domainNames/slots/roles/extensionReferences/operationStat Reads the operation status for the domain names slots roles
uses/read extension references.
/domainNames/slots/roles/roleInstances/read Get the role instance.
/domainNames/slots/roles/roleInstances/restart/action Restarts role instances.
/domainNames/slots/roles/roleInstances/reimage/action Reimages the role instance.
/domainNames/slots/roles/roleInstances/operationStatuses/re Reads the operation status for the domain names slots roles
ad role instances.
/domainNames/slots/state/start/write Changes the deployment slot state to stopped.
/domainNames/slots/state/stop/write Changes the deployment slot state to started.
/domainNames/slots/upgradeDomain/write Walk upgrade the domain.
/domainNames/internalLoadBalancers/read Gets the internal load balancers.
/domainNames/internalLoadBalancers/write Creates a new internal load balance.
/domainNames/internalLoadBalancers/delete Remove a new internal load balance.
/domainNames/internalLoadBalancers/operationStatuses/read Reads the operation status for the domain names internal load
balancers.
/domainNames/loadBalancedEndpointSets/read Shows the load balanced endpoint sets
/domainNames/loadBalancedEndpointSets/operationStatuses/r Reads the operation status for the domain names load
ead balanced endpoint sets.
/domainNames/availabilitySets/read Show the availability set for the resource.

/quotas/read Get the quota for the subscription.
/virtualMachines/read Retrieves list of virtual machines.
/virtualMachines/write Add or modify virtual machines.
/virtualMachines/delete Removes virtual machines.
/virtualMachines/start/action Start the virtual machine.
/virtualMachines/redeploy/action Redeploys the virtual machine.
/virtualMachines/restart/action Restarts virtual machines.
/virtualMachines/stop/action Stops the virtual machine.
/virtualMachines/shutdown/action Shutdown the virtual machine.
/virtualMachines/attachDisk/action Attaches a data disk to a virtual machine.
/virtualMachines/detachDisk/action Detaches a data disk from virtual machine.
/virtualMachines/downloadRemoteDesktopConnectionFile/acti Downloads the RDP file for virtual machine.

on
/virtualMachines/networkInterfaces/ Gets the network security group associated with the network
associatedNetworkSecurityGroups/read interface.
/virtualMachines/networkInterfaces/ Adds a network security group associated with the network

associatedNetworkSecurityGroups/write interface.
/virtualMachines/networkInterfaces/ Deletes the network security group associated with the

associatedNetworkSecurityGroups/delete network interface.
/virtualMachines/networkInterfaces/ Reads the operation status for the virtual machines associated
associatedNetworkSecurityGroups/operationStatuses/read network security groups.
/virtualMachines/providers/Microsoft.Insights/metricDefinition Gets the metrics definitions.

s/read
/virtualMachines/providers/Microsoft.Insights/diagnosticSettin Get the diagnostics settings.

gs/read
/virtualMachines/providers/Microsoft.Insights/diagnosticSettin Add or modify diagnostics settings.

gs/write
/virtualMachines/metrics/read Gets the metrics.
/virtualMachines/operationStatuses/read Reads the operation status for the virtual machines.
/virtualMachines/extensions/read Gets the virtual machine extension.

/virtualMachines/extensions/write Puts the virtual machine extension.
/virtualMachines/extensions/operationStatuses/read Reads the operation status for the virtual machines extensions.
/virtualMachines/asyncOperations/read Gets the possible async operations
/virtualMachines/disks/read Retrives list of data disks
/virtualMachines/associatedNetworkSecurityGroups/read Gets the network security group associated with the virtual
machine.
/virtualMachines/associatedNetworkSecurityGroups/write Adds a network security group associated with the virtual

machine.
/virtualMachines/associatedNetworkSecurityGroups/delete Deletes the network security group associated with the virtual
machine.
/virtualMachines/associatedNetworkSecurityGroups/operation Reads the operation status for the virtual machines associated
Statuses/read network security groups.
Microsoft.ClassicNetwork
/register/action Register to Classic Network
/gatewaySupportedDevices/read Retrieves the list of supported devices.
/reservedIps/read Gets the reserved Ips
/reservedIps/write Add a new reserved Ip
/reservedIps/delete Delete a reserved Ip.
/reservedIps/link/action Link a reserved Ip
/reservedIps/join/action Join a reserved Ip
/reservedIps/operationStatuses/read Reads the operation status for the reserved ips.
/virtualNetworks/read Get the virtual network.
/virtualNetworks/write Add a new virtual network.
/virtualNetworks/delete Deletes the virtual network.
/virtualNetworks/peer/action Peers a virtual network with another virtual network.
/virtualNetworks/join/action Joins the virtual network.

/virtualNetworks/checkIPAddressAvailability/action Checks the availability of a given IP address in a virtual

network.
/virtualNetworks/capabilities/read Shows the capabilities
/virtualNetworks/subnets/ Gets the network security group associated with the subnet.
associatedNetworkSecurityGroups/read
/virtualNetworks/subnets/ Adds a network security group associated with the subnet.

associatedNetworkSecurityGroups/write
/virtualNetworks/subnets/ Deletes the network security group associated with the

associatedNetworkSecurityGroups/delete subnet.
/virtualNetworks/subnets/ Reads the operation status for the virtual network subnet
associatedNetworkSecurityGroups/operationStatuses/read associeted network security group.
/virtualNetworks/operationStatuses/read Reads the operation status for the virtual networks.
/virtualNetworks/gateways/read Gets the virtual network gateways.
/virtualNetworks/gateways/write Adds a virtual network gateway.
/virtualNetworks/gateways/delete Deletes the virtual network gateway.
/virtualNetworks/gateways/startDiagnostics/action Starts diagnositic for the virtual network gateway.
/virtualNetworks/gateways/stopDiagnostics/action Stops the diagnositic for the virtual network gateway.
/virtualNetworks/gateways/downloadDiagnostics/action Downloads the gateway diagnostics.
/virtualNetworks/gateways/listCircuitServiceKey/action Retrieves the circuit service key.
/virtualNetworks/gateways/downloadDeviceConfigurationScrip Downloads the device configuration script.

t/action
/virtualNetworks/gateways/listPackage/action Lists the virtual network gateway package.
/virtualNetworks/gateways/operationStatuses/read Reads the operation status for the virtual networks gateways.
/virtualNetworks/gateways/packages/read Gets the virtual network gateway package.
/virtualNetworks/gateways/connections/read Retrieves the list of connections.
/virtualNetworks/gateways/connections/connect/action Connects a site to site gateway connection.
/virtualNetworks/gateways/connections/disconnect/action Disconnects a site to site gateway connection.
/virtualNetworks/gateways/connections/test/action Tests a site to site gateway connection.
/virtualNetworks/gateways/clientRevokedCertificates/read Read the revoked client certificates.

/virtualNetworks/gateways/clientRevokedCertificates/write Revokes a client certificate.
/virtualNetworks/gateways/clientRevokedCertificates/delete Unrevokes a client certificate.
/virtualNetworks/gateways/clientRootCertificates/read Find the client root certificates.
/virtualNetworks/gateways/clientRootCertificates/write Uploads a new client root certificate.
/virtualNetworks/gateways/clientRootCertificates/delete Deletes the virtual network gateway client certificate.
/virtualNetworks/gateways/clientRootCertificates/download/ac Downloads certificate by thumbprint.

tion
/virtualNetworks/gateways/clientRootCertificates/listPackage/a Lists the virtual network gateway certificate package.

ction
/networkSecurityGroups/read Gets the network security group.
/networkSecurityGroups/write Adds a new network security group.
/networkSecurityGroups/delete Deletes the network security group.
/networkSecurityGroups/operationStatuses/read Reads the operation status for the network security group.
/networkSecurityGroups/securityRules/read Gets the security rule.
/networkSecurityGroups/securityRules/write Adds or update a security rule.
/networkSecurityGroups/securityRules/delete Deletes the security rule.
/networkSecurityGroups/securityRules/operationStatuses/read Reads the operation status for the network security group
security rules.
Microsoft.ClassicStorage
/register/action Register to Classic Storage
/checkStorageAccountAvailability/action Checks for the availability of a storage account.
/capabilities/read Shows the capabilities
/publicImages/read Gets the public virtual machine image.
/images/read Returns the image.
/storageAccounts/read Return the storage account with the given account.

/storageAccounts/write Adds a new storage account.
/storageAccounts/delete Delete the storage account.
/storageAccounts/listKeys/action Lists the access keys for the storage accounts.
/storageAccounts/regenerateKey/action Regenerates the existing access keys for the storage account.
/storageAccounts/operationStatuses/read Reads the operation status for the resource.
/storageAccounts/images/read Returns the storage account image.
/storageAccounts/images/delete Deletes a given storage account image.
/storageAccounts/disks/read Returns the storage account disk.
/storageAccounts/disks/write Adds a storage account disk.
/storageAccounts/disks/delete Deletes a given storage account disk.
/storageAccounts/disks/operationStatuses/read Reads the operation status for the resource.
/storageAccounts/osImages/read Returns the storage account operating system image.
/storageAccounts/osImages/delete Deletes a given storage account operating system image.
/storageAccounts/services/read Get the available services.
/storageAccounts/services/metricDefinitions/read Gets the metrics definitions.
/storageAccounts/services/metrics/read Gets the metrics.
/storageAccounts/services/diagnosticSettings/read Get the diagnostics settings.
/storageAccounts/services/diagnosticSettings/write Add or modify diagnostics settings.
/disks/read Returns the storage account disk.
/osImages/read Returns the operating system image.
Microsoft.CognitiveServices
/accounts/read Reads API accounts.
/accounts/write Writes API Accounts.

/accounts/delete Deletes API accounts
/accounts/listKeys/action List Keys
/accounts/regenerateKey/action Regenerate Key
/accounts/skus/read Reads available SKUs for an existing resource.
/accounts/usages/read Get the quota usage for an existing resource.
/Operations/read Description of the operation.
Microsoft.Commerce
/RateCard/read Returns offer data, resource/meter metadata and rates for the
given subscription.
/UsageAggregates/read Retrieves Microsoft Azure’s consumption by a subscription.

The result contains aggregates usage data, subscription and
resource related information, on a particular time range.
Microsoft.Compute
/register/action Registers Subscription with Microsoft.Compute resource

provider
/restorePointCollections/read Get the properties of a restore point collection
/restorePointCollections/write Creates a new restore point collection or updates an existing

one
/restorePointCollections/delete Deletes the restore point collection and contained restore

points
/restorePointCollections/restorePoints/read Get the properties of a restore point
/restorePointCollections/restorePoints/write Creates a new restore point
/restorePointCollections/restorePoints/delete Deletes the restore point
/restorePointCollections/restorePoints/retrieveSasUris/action Get the properties of a restore point along with blob SAS URIs
/virtualMachineScaleSets/read Get the properties of a virtual machine scale set
/virtualMachineScaleSets/write Creates a new virtual machine scale set or updates an existing

one
/virtualMachineScaleSets/delete Deletes the virtual machine scale set
/virtualMachineScaleSets/start/action Starts the instances of the virtual machine scale set
/virtualMachineScaleSets/powerOff/action Powers off the instances of the virtual machine scale set
/virtualMachineScaleSets/restart/action Restarts the instances of the virtual machine scale set
/virtualMachineScaleSets/deallocate/action Powers off and releases the compute resources for the
instances of the virtual machine scale set
/virtualMachineScaleSets/manualUpgrade/action Manually updates instances to latest model of the virtual

machine scale set
/virtualMachineScaleSets/scale/action Scale In/Scale Out instance count of an existing virtual

machine scale set
/virtualMachineScaleSets/instanceView/read Gets the instance view of the virtual machine scale set
/virtualMachineScaleSets/skus/read Lists the valid SKUs for an existing virtual machine scale set
/virtualMachineScaleSets/virtualMachines/read Retrieves the properties of a Virtual Machine in a VM Scale Set
/virtualMachineScaleSets/virtualMachines/delete Delete a specific Virtual Machine in a VM Scale Set.
/virtualMachineScaleSets/virtualMachines/start/action Starts a Virtual Machine instance in a VM Scale Set.
/virtualMachineScaleSets/virtualMachines/powerOff/action Powers Off a Virtual Machine instance in a VM Scale Set.
/virtualMachineScaleSets/virtualMachines/restart/action Restarts a Virtual Machine instance in a VM Scale Set.
/virtualMachineScaleSets/virtualMachines/deallocate/action Powers off and releases the compute resources for a Virtual
Machine in a VM Scale Set.
/virtualMachineScaleSets/virtualMachines/instanceView/read Retrieves the instance view of a Virtual Machine in a VM Scale

Set.
/images/read Get the properties of the Image
/images/write Creates a new Image or updates an existing one
/images/delete Deletes the image
/operations/read Lists operations available on Microsoft.Compute resource

provider
/disks/read Get the properties of a Disk
/disks/write Creates a new Disk or updates an existing one
/disks/delete Deletes the Disk

/disks/beginGetAccess/action Get the SAS URI of the Disk for blob access
/disks/endGetAccess/action Revoke the SAS URI of the Disk
/snapshots/read Get the properties of a Snapshot
/snapshots/write Create a new Snapshot or update an existing one
/snapshots/delete Delete a Snapshot
/availabilitySets/read Get the properties of an availability set
/availabilitySets/write Creates a new availability set or updates an existing one
/availabilitySets/delete Deletes the availability set
/availabilitySets/vmSizes/read List available sizes for creating or updating a virtual machine in

the availability set
/virtualMachines/read Get the properties of a virtual machine
/virtualMachines/write Creates a new virtual machine or updates an existing virtual

machine
/virtualMachines/delete Deletes the virtual machine
/virtualMachines/start/action Starts the virtual machine
/virtualMachines/powerOff/action Powers off the virtual machine. Note that the virtual machine
will continue to be billed.
/virtualMachines/redeploy/action Redeploys virtual machine
/virtualMachines/restart/action Restarts the virtual machine
/virtualMachines/deallocate/action Powers off the virtual machine and releases the compute
resources
/virtualMachines/generalize/action Sets the virtual machine state to Generalized and prepares the
virtual machine for capture
/virtualMachines/capture/action Captures the virtual machine by copying virtual hard disks and
generates a template that can be used to create similar virtual
machines
/virtualMachines/convertToManagedDisks/action Converts the blob based disks of the virtual machine to

managed disks
/virtualMachines/vmSizes/read Lists available sizes the virtual machine can be updated to
/virtualMachines/instanceView/read Gets the detailed runtime status of the virtual machine and its
resources
/virtualMachines/extensions/read Get the properties of a virtual machine extension
/virtualMachines/extensions/write Creates a new virtual machine extension or updates an

existing one
/virtualMachines/extensions/delete Deletes the virtual machine extension
/locations/vmSizes/read Lists available virtual machine sizes in a location
/locations/usages/read Gets service limits and current usage quantities for the
subscription's compute resources in a location
/locations/operations/read Gets the status of an asynchronous operation
Microsoft.ContainerRegistry
/register/action Registers the subscription for the container registry resource

provider and enables the creation of container registries.
/checknameavailability/read Checks that registry name is valid and is not in use.
/registries/read Returns the list of container registries or gets the properties

for the specified container registry.
/registries/write Creates a container registry with the specified parameters or

update the properties or tags for the specified container
registry.
/registries/delete Deletes an existing container registry.
/registries/listCredentials/action Lists the login credentials for the specified container registry.
/registries/regenerateCredential/action Regenerates the login credentials for the specified container

registry.
Microsoft.ContainerService
/containerServices/subscriptions/read Get the specified Container Services based on Subscription
/containerServices/resourceGroups/read Get the specified Container Services based on Resource Group
/containerServices/resourceGroups/ContainerServiceName/rea Gets the specified Container Service

d
/containerServices/resourceGroups/ContainerServiceName/writ Puts or Updates the specified Container Service

e
/containerServices/resourceGroups/ContainerServiceName/del Deletes the specified Container Service

ete
Microsoft.ContentModerator
/updateCommunicationPreference/action Update communication preference
/listCommunicationPreference/action List communication preference
/applications/read Read Operation
/applications/write Write Operation
/applications/write Write Operation
/applications/delete Delete Operation
/applications/listSecrets/action List Secrets
/applications/listSingleSignOnToken/action Read Single Sign On Tokens
/operations/read read operations
Microsoft.CustomerInsights
/hubs/read Read any Azure Customer Insights Hub
/hubs/write Create or Update any Azure Customer Insights Hub
/hubs/delete Delete any Azure Customer Insights Hub
/hubs/providers/Microsoft.Insights/metricDefinitions/read Gets the available metrics for resource
/hubs/providers/Microsoft.Insights/diagnosticSettings/read Gets the diagnostic setting for the resource
/hubs/providers/Microsoft.Insights/diagnosticSettings/write Creates or updates the diagnostic setting for the resource
/hubs/providers/Microsoft.Insights/logDefinitions/read Gets the available logs for resource
/hubs/authorizationPolicies/read Read any Azure Customer Insights Shared Access Signature

Policy
/hubs/authorizationPolicies/write Create or Update any Azure Customer Insights Shared Access

Signature Policy
/hubs/authorizationPolicies/delete Delete any Azure Customer Insights Shared Access Signature

Policy
/hubs/authorizationPolicies/regeneratePrimaryKey/action Regenerate Azure Customer Insights Shared Access Signature

Policy primary key
/hubs/authorizationPolicies/regenerateSecondaryKey/action Regenerate Azure Customer Insights Shared Access Signature

Policy secondary key
/hubs/profiles/read Read any Azure Customer Insights Profile
/hubs/profiles/write Write any Azure Customer Insights Profile
/hubs/kpi/read Read any Azure Customer Insights Key Performance Indicator
/hubs/kpi/write Create or Update any Azure Customer Insights Key

Performance Indicator
/hubs/kpi/delete Delete any Azure Customer Insights Key Performance

Indicator
/hubs/views/read Read any Azure Customer Insights App View
/hubs/views/write Create or Update any Azure Customer Insights App View
/hubs/views/delete Delete any Azure Customer Insights App View
/hubs/interactions/read Read any Azure Customer Insights Interaction
/hubs/interactions/write Create or Update any Azure Customer Insights Interaction
/hubs/roleAssignments/read Read any Azure Customer Insights Rbac Assignment
/hubs/roleAssignments/write Create or Update any Azure Customer Insights Rbac

Assignment
/hubs/roleAssignments/delete Delete any Azure Customer Insights Rbac Assignment
/hubs/connectors/read Read any Azure Customer Insights Connector
/hubs/connectors/write Create or Update any Azure Customer Insights Connector
/hubs/connectors/delete Delete any Azure Customer Insights Connector
/hubs/connectors/mappings/read Read any Azure Customer Insights Connector Mapping
/hubs/connectors/mappings/write Create or Update any Azure Customer Insights Connector

Mapping
/hubs/connectors/mappings/delete Delete any Azure Customer Insights Connector Mapping

Microsoft.DataCatalog
/checkNameAvailability/action Checks catalog name availability for tenant.
/catalogs/read Get properties for catalog or catalogs under subscription or

resource group.
/catalogs/write Creates catalog or updates the tags and properties for the
catalog.
/catalogs/delete Deletes the catalog.
Microsoft.DataFactory
/datafactories/read Reads Data Factory.
/datafactories/write Create or Update Data Factory
/datafactories/delete Deletes Data Factory.
/datafactories/datapipelines/read Reads Pipeline.
/datafactories/datapipelines/delete Deletes Pipeline.
/datafactories/datapipelines/pause/action Pauses Pipeline.
/datafactories/datapipelines/resume/action Resumes Pipeline.
/datafactories/datapipelines/update/action Updates Pipeline.
/datafactories/datapipelines/write Create or Update Pipeline
/datafactories/linkedServices/read Reads Linked service.
/datafactories/linkedServices/delete Deletes Linked service.
/datafactories/linkedServices/write Create or Update Linked service
/datafactories/tables/read Reads Table.
/datafactories/tables/delete Deletes Table.
/datafactories/tables/write Create or Update Table
Microsoft.DataLakeAnalytics
/accounts/read Get information about the DataLakeAnalytics account.
/accounts/write Create or update the DataLakeAnalytics account.
/accounts/delete Delete the DataLakeAnalytics account.
/accounts/firewallRules/read Get information about a firewall rule.
/accounts/firewallRules/write Create or update a firewall rule.
/accounts/firewallRules/delete Delete a firewall rule.
/accounts/storageAccounts/read Get linked Storage account for the DataLakeAnalytics account.
/accounts/storageAccounts/write Link a Storage account to the DataLakeAnalytics account.
/accounts/storageAccounts/delete Unlink a Storage account from the DataLakeAnalytics account.
/accounts/storageAccounts/Containers/read Get Containers under the Storage account
/accounts/storageAccounts/Containers/listSasTokens/action List SAS Tokens for the Storage container
/accounts/dataLakeStoreAccounts/read Get linked DataLakeStore account for the DataLakeAnalytics

account.
/accounts/dataLakeStoreAccounts/write Link a DataLakeStore account to the DataLakeAnalytics

account.
/accounts/dataLakeStoreAccounts/delete Unlink a DataLakeStore account from the DataLakeAnalytics

account.
Microsoft.DataLakeStore
/accounts/read Get information about an existed DataLakeStore account.
/accounts/write Create a new DataLakeStore account, or Update an existed

DataLakeStore account.
/accounts/delete Delete an existed DataLakeStore account.
/accounts/firewallRules/read Get information about a firewall rule.
/accounts/firewallRules/write Create or update a firewall rule.
/accounts/firewallRules/delete Delete a firewall rule.
/accounts/trustedIdProviders/read Get information about a trusted identity provider.

/accounts/trustedIdProviders/write Create or update a trusted identity provider.
/accounts/trustedIdProviders/delete Delete a trusted identity provider.
Microsoft.Devices
/register/action Register the subscription for the IotHub resource provider and
enables the creation of IotHub resources
/checkNameAvailability/Action Check If IotHub name is available
/usages/Read Get subscription usage details for this provider.
/operations/Read Get All ResourceProvider Operations
/iotHubs/Read Gets the IotHub resource(s)
/iotHubs/Write Create or update IotHub Resource
/iotHubs/Delete Delete IotHub Resource
/iotHubs/listkeys/Action Get all IotHub Keys
/iotHubs/exportDevices/Action Export Devices
/iotHubs/importDevices/Action Import Devices
/IotHubs/metricDefinitions/read Gets the available metrics for the IotHub service
/iotHubs/iotHubKeys/listkeys/Action Get IotHub Key for the given name
/iotHubs/iotHubStats/Read Get IotHub Statistics
/iotHubs/quotaMetrics/Read Get Quota Metrics
/iotHubs/eventHubEndpoints/consumerGroups/Write Create EventHub Consumer Group
/iotHubs/eventHubEndpoints/consumerGroups/Read Get EventHub Consumer Group(s)
/iotHubs/eventHubEndpoints/consumerGroups/Delete Delete EventHub Consumer Group
/iotHubs/routing/routes/$testall/Action Test a message against all existing Routes
/iotHubs/routing/routes/$testnew/Action Test a message against a provided test Route
/IotHubs/diagnosticSettings/read Gets the diagnostic setting for the resource
/IotHubs/diagnosticSettings/write Creates or updates the diagnostic setting for the resource

/iotHubs/skus/Read Get valid IotHub Skus
/iotHubs/jobs/Read Get Job(s) details submitted on given IotHub
/iotHubs/routingEndpointsHealth/Read Gets the health of all routing Endpoints for an IotHub
Microsoft.DevTestLab
/Subscription/register/action Registers the subscription
/labs/delete Delete labs.
/labs/read Read labs.
/labs/write Add or modify labs.
/labs/ListVhds/action List disk images available for custom image creation.
/labs/GenerateUploadUri/action Generate a URI for uploading custom disk images to a Lab.
/labs/CreateEnvironment/action Create virtual machines in a lab.
/labs/ClaimAnyVm/action Claim a random claimable virtual machine in the lab.
/labs/ExportResourceUsage/action Exports the lab resource usage into a storage account
/labs/users/delete Delete user profiles.
/labs/users/read Read user profiles.
/labs/users/write Add or modify user profiles.
/labs/users/secrets/delete Delete secrets.
/labs/users/secrets/read Read secrets.
/labs/users/secrets/write Add or modify secrets.
/labs/users/environments/delete Delete environments.
/labs/users/environments/read Read environments.
/labs/users/environments/write Add or modify environments.
/labs/users/disks/delete Delete disks.
/labs/users/disks/read Read disks.

/labs/users/disks/write Add or modify disks.
/labs/users/disks/Attach/action Attach and create the lease of the disk to the virtual machine.
/labs/users/disks/Detach/action Detach and break the lease of the disk attached to the virtual
machine.
/labs/customImages/delete Delete custom images.
/labs/customImages/read Read custom images.
/labs/customImages/write Add or modify custom images.
/labs/serviceRunners/delete Delete service runners.
/labs/serviceRunners/read Read service runners.
/labs/serviceRunners/write Add or modify service runners.
/labs/artifactSources/delete Delete artifact sources.
/labs/artifactSources/read Read artifact sources.
/labs/artifactSources/write Add or modify artifact sources.
/labs/artifactSources/artifacts/read Read artifacts.
/labs/artifactSources/artifacts/GenerateArmTemplate/action Generates an ARM template for the given artifact, uploads the
required files to a storage account, and validates the
generated artifact.
/labs/artifactSources/armTemplates/read Read azure resource manager templates.
/labs/costs/read Read costs.
/labs/costs/write Add or modify costs.
/labs/virtualNetworks/delete Delete virtual networks.
/labs/virtualNetworks/read Read virtual networks.
/labs/virtualNetworks/write Add or modify virtual networks.
/labs/formulas/delete Delete formulas.
/labs/formulas/read Read formulas.
/labs/formulas/write Add or modify formulas.
/labs/schedules/delete Delete schedules.

/labs/schedules/read Read schedules.
/labs/schedules/write Add or modify schedules.
/labs/schedules/Execute/action Execute a schedule.
/labs/schedules/ListApplicable/action Lists all applicable schedules
/labs/galleryImages/read Read gallery images.
/labs/policySets/EvaluatePolicies/action Evaluates lab policy.
/labs/policySets/policies/delete Delete policies.
/labs/policySets/policies/read Read policies.
/labs/policySets/policies/write Add or modify policies.
/labs/virtualMachines/delete Delete virtual machines.
/labs/virtualMachines/read Read virtual machines.
/labs/virtualMachines/write Add or modify virtual machines.
/labs/virtualMachines/Start/action Start a virtual machine.
/labs/virtualMachines/Stop/action Stop a virtual machine
/labs/virtualMachines/ApplyArtifacts/action Apply artifacts to virtual machine.
/labs/virtualMachines/AddDataDisk/action Attach a new or existing data disk to virtual machine.
/labs/virtualMachines/DetachDataDisk/action Detach the specified disk from the virtual machine.
/labs/virtualMachines/Claim/action Take ownership of an existing virtual machine
/labs/virtualMachines/ListApplicableSchedules/action Lists all applicable schedules
/labs/virtualMachines/schedules/delete Delete schedules.
/labs/virtualMachines/schedules/read Read schedules.
/labs/virtualMachines/schedules/write Add or modify schedules.
/labs/virtualMachines/schedules/Execute/action Execute a schedule.
/labs/notificationChannels/delete Delete notificationchannels.
/labs/notificationChannels/read Read notificationchannels.

/labs/notificationChannels/write Add or modify notificationchannels.
/labs/notificationChannels/Notify/action Send notification to provided channel.
/schedules/delete Delete schedules.
/schedules/read Read schedules.
/schedules/write Add or modify schedules.
/schedules/Execute/action Execute a schedule.
/schedules/Retarget/action Updates a schedule's target resource Id.
/locations/operations/read Read operations.
Microsoft.DocumentDB
/databaseAccountNames/read Checks for name availability.
/databaseAccounts/read Reads a database account.
/databaseAccounts/write Update a database accounts.
/databaseAccounts/listKeys/action List keys of a database account
/databaseAccounts/regenerateKey/action Rotate keys of a database account
/databaseAccounts/listConnectionStrings/action Get the connection strings for a database account
/databaseAccounts/changeResourceGroup/action Change resource group of a database account
/databaseAccounts/failoverPriorityChange/action Change failover priorities of regions of a database account.

This is used to perform manual failover operation
/databaseAccounts/delete Deletes the database accounts.
/databaseAccounts/metricDefinitions/read Reads the database account metrics definitions.
/databaseAccounts/metrics/read Reads the database account metrics.
/databaseAccounts/usages/read Reads the database account usages.
/databaseAccounts/databases/collections/metricDefinitions/rea Reads the collection metric definitions.

d
/databaseAccounts/databases/collections/metrics/read Reads the collection metrics.

/databaseAccounts/databases/collections/usages/read Reads the collection usages.
/databaseAccounts/databases/metricDefinitions/read Reads the database metric definitions
/databaseAccounts/databases/metrics/read Reads the database metrics.
/databaseAccounts/databases/usages/read Reads the database usages.
/databaseAccounts/readonlykeys/read Reads the database account readonly keys.
Microsoft.DomainRegistration
/generateSsoRequest/Action Generate a request for signing into domain control center.
/validateDomainRegistrationInformation/Action Validate domain purchase object without submitting it
/checkDomainAvailability/Action Check if a domain is available for purchase
/listDomainRecommendations/Action Retrieve the list domain recommendations based on keywords
/register/action Register the Microsoft Domains resource provider for the

subscription
/domains/Read Get the list of domains
/domains/Write Add a new Domain or update an existing one
/domains/Delete Delete an existing domain.
/domains/operationresults/Read Get a domain operation
Microsoft.DynamicsLcs
/lcsprojects/read Display Microsoft Dynamics Lifecycle Services projects that

belong to a user
/lcsprojects/write Create and update Microsoft Dynamics Lifecycle Services

projects that belong to the user. Only the name and
description properties can be updated. The subscription and
location associated with the project cannot be updated after
creation
/lcsprojects/delete Delete Microsoft Dynamics Lifecycle Services projects that

belong to the user
/lcsprojects/clouddeployments/read Display Microsoft Dynamics AX 2012 R3 Evaluation

deployments in a Microsoft Dynamics Lifecycle Services project
that belong to a user
/lcsprojects/clouddeployments/write Create Microsoft Dynamics AX 2012 R3 Evaluation

deployment in a Microsoft Dynamics Lifecycle Services project
that belong to a user. Deployments can be managed from
Azure management portal
/lcsprojects/connectors/read Read connectors that belong to a Microsoft Dynamics Lifecycle

Services project
/lcsprojects/connectors/write Create and update connectors that belong to a Microsoft

Dynamics Lifecycle Services project
Microsoft.EventHub
/checkNameAvailability/action Checks availability of namespace under given subscription.
/register/action Registers the subscription for the EventHub resource provider

and enables the creation of EventHub resources
/namespaces/write Create a Namespace Resource and Update its properties. Tags

and status of the Namespace are the properties which can be
updated.
/namespaces/read Get the list of Namespace Resource Description
/namespaces/Delete Delete Namespace Resource
/namespaces/metricDefinitions/read Get list of Namespace metrics Resource Descriptions
/namespaces/authorizationRules/read Get the list of Namespaces Authorization Rules description.
/namespaces/authorizationRules/write Create a Namespace level Authorization Rules and update its

properties. The Authorization Rules Access Rights, the Primary
and Secondary Keys can be updated.
/namespaces/authorizationRules/delete Delete Namespace Authorization Rule. The Default Namespace

Authorization Rule cannot be deleted.
/namespaces/authorizationRules/listkeys/action Get the Connection String to the Namespace
/namespaces/authorizationRules/regenerateKeys/action Regenerate the Primary or Secondary key to the Resource
/namespaces/eventhubs/write Create or Update EventHub properties.
/namespaces/eventhubs/read Get list of EventHub Resource Descriptions
/namespaces/eventhubs/Delete Operation to delete EventHub Resource

/namespaces/eventHubs/consumergroups/write Create or Update ConsumerGroup properties.
/namespaces/eventHubs/consumergroups/read Get list of ConsumerGroup Resource Descriptions
/namespaces/eventHubs/consumergroups/Delete Operation to delete ConsumerGroup Resource
/namespaces/eventhubs/authorizationRules/read Get the list of EventHub Authorization Rules
/namespaces/eventhubs/authorizationRules/write Create EventHub Authorization Rules and Update its

/namespaces/eventhubs/authorizationRules/delete Operation to delete EventHub Authorization Rules
/namespaces/eventhubs/authorizationRules/listkeys/action Get the Connection String to EventHub
/namespaces/eventhubs/authorizationRules/regenerateKeys/ac Regenerate the Primary or Secondary key to the Resource

tion
/namespaces/diagnosticSettings/read Get list of Namespace diagnostic settings Resource

Descriptions
/namespaces/diagnosticSettings/write Get list of Namespace diagnostic settings Resource

Descriptions
/namespaces/logDefinitions/read Get list of Namespace logs Resource Descriptions
Microsoft.Features
/providers/features/read Gets the feature of a subscription in a given resource provider.
/providers/features/register/action Registers the feature for a subscription in a given resource

provider.
/features/read Gets the features of a subscription.
Microsoft.HDInsight
/clusters/write Create or Update HDInsight Cluster
/clusters/read Get details about HDInsight Cluster
/clusters/delete Delete a HDInsight Cluster
/clusters/changerdpsetting/action Change RDP setting for HDInsight Cluster

/clusters/configurations/action Update HDInsight Cluster Configuration
/clusters/configurations/read Get HDInsight Cluster Configurations
/clusters/roles/resize/action Resize a HDInsight Cluster
/locations/capabilities/read Get Subscription Capabilities
/locations/checkNameAvailability/read Check Name Availability
Microsoft.ImportExport
/register/action Registers the subscription for the import/export resource

provider and enables the creation of import/export jobs.
/jobs/write Creates a job with the specified parameters or update the

properties or tags for the specified job.
/jobs/read Gets the properties for the specified job or returns the list of
jobs.
/jobs/listBitLockerKeys/action Gets the BitLocker keys for the specified job.
/jobs/delete Deletes an existing job.
/locations/read Gets the properties for the specified location or returns the list
of locations.
Microsoft.Insights
/Register/Action Register the microsoft insights provider
/AlertRules/Write Writing to an alert rule configuration
/AlertRules/Delete Deleting an alert rule configuration
/AlertRules/Read Reading an alert rule configuration
/AlertRules/Activated/Action Alert Rule activated
/AlertRules/Resolved/Action Alert Rule resolved
/AlertRules/Throttled/Action Alert rule is throttled
/AlertRules/Incidents/Read Reading an alert rule incident configuration

/MetricDefinitions/Read Read metric definitions
/eventtypes/values/Read Read management event type values
/eventtypes/digestevents/Read Read management event type digest
/Metrics/Read Read metrics
/LogProfiles/Write Writing to a log profile configuration
/LogProfiles/Delete Delete log profiles configuration
/LogProfiles/Read Read log profiles
/AutoscaleSettings/Write Writing to an autoscale setting configuration
/AutoscaleSettings/Delete Deleting an autoscale setting configuration
/AutoscaleSettings/Read Reading an autoscale setting configuration
/AutoscaleSettings/Scaleup/Action Autoscale scale up operation
/AutoscaleSettings/Scaledown/Action Autoscale scale down operation
/AutoscaleSettings/providers/Microsoft.Insights/MetricDefiniti Read metric definitions

ons/Read
/ActivityLogAlerts/Activated/Action Triggered the Activity Log Alert
/DiagnosticSettings/Write Writing to diagnostic settings configuration
/DiagnosticSettings/Delete Deleting diagnostic settings configuration
/DiagnosticSettings/Read Reading a diagnostic settings configuration
/LogDefinitions/Read Read log definitions
/ExtendedDiagnosticSettings/Write Writing to extended diagnostic settings configuration
/ExtendedDiagnosticSettings/Delete Deleting extended diagnostic settings configuration
/ExtendedDiagnosticSettings/Read Reading a extended diagnostic settings configuration
Microsoft.KeyVault
/register/action Registers a subscription
/checkNameAvailability/read Checks that a key vault name is valid and is not in use
/vaults/read View the properties of a key vault
/vaults/write Create a new key vault or update the properties of an existing

key vault
/vaults/delete Delete a key vault
/vaults/deploy/action Enables access to secrets in a key vault when deploying Azure

resources
/vaults/secrets/read View the properties of a secret, but not its value
/vaults/secrets/write Create a new secret or update the value of an existing secret
/vaults/accessPolicies/write Update an existing access policy by merging or replacing, or

add a new access policy to a vault.
/deletedVaults/read View the properties of soft deleted key vaults
/locations/operationResults/read Check the result of a long run operation
/locations/deletedVaults/read View the properties of a soft deleted key vault
/locations/deletedVaults/purge/action Purge a soft deleted key vault
Microsoft.Logic
/workflows/read Reads the workflow.
/workflows/write Creates or updates the workflow.
/workflows/delete Deletes the workflow.
/workflows/run/action Starts a run of the workflow.
/workflows/disable/action Disables the workflow.
/workflows/enable/action Enables the workflow.
/workflows/validate/action Validates the workflow.
/workflows/move/action Moves Workflow from its existing subscription id, resource

group, and/or name to a different subscription id, resource
group, and/or name.
/workflows/listSwagger/action Gets the workflow swagger definitions.
/workflows/regenerateAccessKey/action Regenerates the access key secrets.

/workflows/listCallbackUrl/action Gets the callback URL for workflow.
/workflows/versions/read Reads the workflow version.
/workflows/versions/triggers/listCallbackUrl/action Gets the callback URL for trigger.
/workflows/runs/read Reads the workflow run.
/workflows/runs/cancel/action Cancels the run of a workflow.
/workflows/runs/actions/read Reads the workflow run action.
/workflows/runs/operations/read Reads the workflow run operation status.
/workflows/triggers/read Reads the trigger.
/workflows/triggers/run/action Executes the trigger.
/workflows/triggers/listCallbackUrl/action Gets the callback URL for trigger.
/workflows/triggers/histories/read Reads the trigger histories.
/workflows/triggers/histories/resubmit/action Resubmits the workflow trigger.
/workflows/accessKeys/read Reads the access key.
/workflows/accessKeys/write Creates or updates the access key.
/workflows/accessKeys/delete Deletes the access key.
/workflows/accessKeys/list/action Lists the access key secrets.
/workflows/accessKeys/regenerate/action Regenerates the access key secrets.
/locations/workflows/validate/action Validates the workflow.
Microsoft.MachineLearning
/register/action Registers the subscription for the machine learning web

service resource provider and enables the creation of web
services.
/webServices/action Create regional Web Service Properties for supported regions
/commitmentPlans/read Read any Machine Learning Commitment Plan
/commitmentPlans/write Create or Update any Machine Learning Commitment Plan

/commitmentPlans/delete Delete any Machine Learning Commitment Plan
/commitmentPlans/join/action Join any Machine Learning Commitment Plan
/commitmentPlans/commitmentAssociations/read Read any Machine Learning Commitment Plan Association
/commitmentPlans/commitmentAssociations/move/action Move any Machine Learning Commitment Plan Association
/Workspaces/read Read any Machine Learning Workspace
/Workspaces/write Create or Update any Machine Learning Workspace
/Workspaces/delete Delete any Machine Learning Workspace
/Workspaces/listworkspacekeys/action List keys for a Machine Learning Workspace
/Workspaces/resyncstoragekeys/action Resync keys of storage account configured for a Machine

Learning Workspace
/webServices/read Read any Machine Learning Web Service
/webServices/write Create or Update any Machine Learning Web Service
/webServices/delete Delete any Machine Learning Web Service
Microsoft.MarketplaceOrdering
/agreements/offers/plans/read Return an agreement for a given marketplace item
/agreements/offers/plans/sign/action Sign an agreement for a given marketplace item
/agreements/offers/plans/cancel/action Cancel an agreement for a given marketplace item
Microsoft.Media
/mediaservices/read
/mediaservices/write
/mediaservices/delete
/mediaservices/regenerateKey/action
/mediaservices/listKeys/action
/mediaservices/syncStorageKeys/action
Microsoft.Network
/register/action Registers the subscription
/unregister/action Unregisters the subscription
/checkTrafficManagerNameAvailability/action Checks the availability of a Traffic Manager Relative DNS name.
/dnszones/read Get the DNS zone, in JSON format. The zone properties
include tags, etag, numberOfRecordSets, and
maxNumberOfRecordSets. Note that this command does not
retrieve the record sets contained within the zone.
/dnszones/write Create or update a DNS zone within a resource group. Used to

update the tags on a DNS zone resource. Note that this
command can not be used to create or update record sets
within the zone.
/dnszones/delete Delete the DNS zone, in JSON format. The zone properties
include tags, etag, numberOfRecordSets, and
maxNumberOfRecordSets.
/dnszones/MX/read Get the record set of type ‘MX’, in JSON format. The record set
contains a list of records as well as the TTL, tags, and etag.
/dnszones/MX/write Create or update a record set of type ‘MX’ within a DNS zone.
The records specified will replace the current records in the
record set.
/dnszones/MX/delete Remove the record set of a given name and type ‘MX’ from a
DNS zone.
/dnszones/NS/read Gets DNS record set of type NS
/dnszones/NS/write Creates or updates DNS record set of type NS
/dnszones/NS/delete Deletes the DNS record set of type NS
/dnszones/AAAA/read Get the record set of type ‘AAAA’, in JSON format. The record
set contains a list of records as well as the TTL, tags, and etag.
/dnszones/AAAA/write Create or update a record set of type ‘AAAA’ within a DNS

zone. The records specified will replace the current records in
the record set.
/dnszones/AAAA/delete Remove the record set of a given name and type ‘AAAA’ from
a DNS zone.
/dnszones/CNAME/read Get the record set of type ‘CNAME’, in JSON format. The
record set contains the TTL, tags, and etag.
/dnszones/CNAME/write Create or update a record set of type ‘CNAME’ within a DNS

zone. The records specified will replace the current records in
the record set.
/dnszones/CNAME/delete Remove the record set of a given name and type ‘CNAME’
from a DNS zone.
/dnszones/SOA/read Gets DNS record set of type SOA
/dnszones/SOA/write Creates or updates DNS record set of type SOA
/dnszones/SRV/read Get the record set of type ‘SRV’, in JSON format. The record
/dnszones/SRV/write Create or update record set of type SRV
/dnszones/SRV/delete Remove the record set of a given name and type ‘SRV’ from a
DNS zone.
/dnszones/PTR/read Get the record set of type ‘PTR’, in JSON format. The record
/dnszones/PTR/write Create or update a record set of type ‘PTR’ within a DNS zone.
record set.
/dnszones/PTR/delete Remove the record set of a given name and type ‘PTR’ from a
DNS zone.
/dnszones/A/read Get the record set of type ‘A’, in JSON format. The record set
contains a list of records as well as the TTL, tags, and etag.
/dnszones/A/write Create or update a record set of type ‘A’ within a DNS zone.
record set.
/dnszones/A/delete Remove the record set of a given name and type ‘A’ from a
DNS zone.
/dnszones/TXT/read Get the record set of type ‘TXT’, in JSON format. The record
/dnszones/TXT/write Create or update a record set of type ‘TXT’ within a DNS zone.
record set.
/dnszones/TXT/delete Remove the record set of a given name and type ‘TXT’ from a
DNS zone.
/dnszones/recordsets/read Gets DNS record sets across types

/networkInterfaces/read Gets a network interface definition.
/networkInterfaces/write Creates a network interface or updates an existing network

interface.
/networkInterfaces/join/action Joins a Virtual Machine to a network interface
/networkInterfaces/delete Deletes a network interface
/networkInterfaces/effectiveRouteTable/action Get Route Table configured On Network Interface Of The Vm
/networkInterfaces/effectiveNetworkSecurityGroups/action Get Network Security Groups configured On Network

Interface Of The Vm
/networkInterfaces/loadBalancers/read Gets all the load balancers that the network interface is part of
/networkInterfaces/ipconfigurations/read Gets a network interface ip configuration definition.
/publicIPAddresses/read Gets a public ip address definition.
/publicIPAddresses/write Creates a public Ip address or updates an existing public Ip

address.
/publicIPAddresses/delete Deletes a public Ip address.
/publicIPAddresses/join/action Joins a public ip address
/routeFilters/read Gets a route filter definition
/routeFilters/join/action Joins a route filter
/routeFilters/delete Deletes a route filter definition
/routeFilters/write Creates a route filter or Updates an existing rotue filter
/routeFilters/rules/read Gets a route filter rule definition
/routeFilters/rules/write Creates a route filter rule or Updates an existing route filter

rule
/routeFilters/rules/delete Deletes a route filter rule definition
/networkWatchers/read Get the network watcher definition
/networkWatchers/write Creates a network watcher or updates an existing network

watcher
/networkWatchers/delete Deletes a network watcher
/networkWatchers/configureFlowLog/action Configures flow logging for a target resource.

/networkWatchers/ipFlowVerify/action Returns whether the packet is allowed or denied to or from a

particular destination.
/networkWatchers/nextHop/action For a specified target and destination IP address, return the

next hop type and next hope IP address.
/networkWatchers/queryFlowLogStatus/action Gets the status of flow logging on a resource.
/networkWatchers/queryTroubleshootResult/action Gets the troubleshooting result from the previously run or

currently running troubleshooting operation.
/networkWatchers/securityGroupView/action View the configured and effective network security group rules
applied on a VM.
/networkWatchers/topology/action Gets a network level view of resources and their relationships

in a resource group.
/networkWatchers/troubleshoot/action Starts troubleshooting on a Networking resource in Azure.
/networkWatchers/packetCaptures/queryStatus/action Gets information about properties and status of a packet

capture resource.
/networkWatchers/packetCaptures/stop/action Stop the running packet capture session.
/networkWatchers/packetCaptures/read Get the packet capture definition
/networkWatchers/packetCaptures/write Creates a packet capture
/networkWatchers/packetCaptures/delete Deletes a packet capture
/loadBalancers/read Gets a load balancer definition
/loadBalancers/write Creates a load balancer or updates an existing load balancer
/loadBalancers/delete Deletes a load balancer
/loadBalancers/networkInterfaces/read Gets references to all the network interfaces under a load

balancer
/loadBalancers/loadBalancingRules/read Gets a load balancer load balancing rule definition
/loadBalancers/backendAddressPools/read Gets a load balancer backend address pool definition
/loadBalancers/backendAddressPools/join/action Joins a load balancer backend address pool
/loadBalancers/inboundNatPools/read Gets a load balancer inbound nat pool definition
/loadBalancers/inboundNatPools/join/action Joins a load balancer inbound nat pool
/loadBalancers/inboundNatRules/read Gets a load balancer inbound nat rule definition

/loadBalancers/inboundNatRules/write Creates a load balancer inbound nat rule or updates an

existing load balancer inbound nat rule
/loadBalancers/inboundNatRules/delete Deletes a load balancer inbound nat rule
/loadBalancers/inboundNatRules/join/action Joins a load balancer inbound nat rule
/loadBalancers/outboundNatRules/read Gets a load balancer outbound nat rule definition
/loadBalancers/probes/read Gets a load balancer probe
/loadBalancers/virtualMachines/read Gets references to all the virtual machines under a load

balancer
/loadBalancers/frontendIPConfigurations/read Gets a load balancer frontend IP configuration definition
/trafficManagerGeographicHierarchies/read Gets the Traffic Manager Geographic Hierarchy containing

regions which can be used with the Geographic traffic routing
method
/bgpServiceCommunities/read Get Bgp Service Communities
/applicationGatewayAvailableWafRuleSets/read Gets Application Gateway Available Waf Rule Sets
/virtualNetworks/read Get the virtual network definition
/virtualNetworks/write Creates a virtual network or updates an existing virtual

network
/virtualNetworks/delete Deletes a virtual network
/virtualNetworks/peer/action Peers a virtual network with another virtual network
/virtualNetworks/virtualNetworkPeerings/read Gets a virtual network peering definition
/virtualNetworks/virtualNetworkPeerings/write Creates a virtual network peering or updates an existing

virtual network peering
/virtualNetworks/virtualNetworkPeerings/delete Deletes a virtual network peering
/virtualNetworks/subnets/read Gets a virtual network subnet definition
/virtualNetworks/subnets/write Creates a virtual network subnet or updates an existing virtual

network subnet
/virtualNetworks/subnets/delete Deletes a virtual network subnet
/virtualNetworks/subnets/join/action Joins a virtual network
/virtualNetworks/subnets/joinViaServiceTunnel/action Joins resource such as storage account or SQL database to a

Service Tunneling enabled subnet.
/virtualNetworks/subnets/virtualMachines/read Gets references to all the virtual machines in a virtual network

subnet
/virtualNetworks/checkIpAddressAvailability/read Check if Ip Address is available at the specified virtual network
/virtualNetworks/virtualMachines/read Gets references to all the virtual machines in a virtual network
/expressRouteServiceProviders/read Gets Express Route Service Providers
/dnsoperationresults/read Gets results of a DNS operation
/localnetworkgateways/read Gets LocalNetworkGateway
/localnetworkgateways/write Creates or updates an existing LocalNetworkGateway
/localnetworkgateways/delete Deletes LocalNetworkGateway
/trafficManagerProfiles/read Get the Traffic Manager profile configuration. This includes

DNS settings, traffic routing settings, endpoint monitoring
settings, and the list of endpoints routed by this Traffic
Manager profile.
/trafficManagerProfiles/write Create a Traffic Manager profile, or modify the configuration of

an existing Traffic Manager profile. This includes enabling or
disabling a profile and modifying DNS settings, traffic routing
settings, or endpoint monitoring settings. Endpoints routed by
the Traffic Manager profile can be added, removed, enabled or
disabled.
/trafficManagerProfiles/delete Delete the Traffic Manager profile. All settings associated with
the Traffic Manager profile will be lost, and the profile can no
longer be used to route traffic.
/dnsoperationstatuses/read Gets status of a DNS operation
/operations/read Get Available Operations
/expressRouteCircuits/read Get an ExpressRouteCircuit
/expressRouteCircuits/write Creates or updates an existing ExpressRouteCircuit
/expressRouteCircuits/delete Deletes an ExpressRouteCircuit
/expressRouteCircuits/stats/read Gets an ExpressRouteCircuit Stat
/expressRouteCircuits/peerings/read Gets an ExpressRouteCircuit Peering
/expressRouteCircuits/peerings/write Creates or updates an existing ExpressRouteCircuit Peering
/expressRouteCircuits/peerings/delete Deletes an ExpressRouteCircuit Peering
/expressRouteCircuits/peerings/arpTables/action Gets an ExpressRouteCircuit Peering ArpTable

/expressRouteCircuits/peerings/routeTables/action Gets an ExpressRouteCircuit Peering RouteTable
/expressRouteCircuits/peerings/ Gets an ExpressRouteCircuit Peering RouteTable Summary

routeTablesSummary/action
/expressRouteCircuits/peerings/stats/read Gets an ExpressRouteCircuit Peering Stat
/expressRouteCircuits/authorizations/read Gets an ExpressRouteCircuit Authorization
/expressRouteCircuits/authorizations/write Creates or updates an existing ExpressRouteCircuit

Authorization
/expressRouteCircuits/authorizations/delete Deletes an ExpressRouteCircuit Authorization
/connections/read Gets VirtualNetworkGatewayConnection
/connections/write Creates or updates an existing

VirtualNetworkGatewayConnection
/connections/delete Deletes VirtualNetworkGatewayConnection
/connections/sharedKey/read Gets VirtualNetworkGatewayConnection SharedKey
/connections/sharedKey/write Creates or updates an existing

VirtualNetworkGatewayConnection SharedKey
/networkSecurityGroups/read Gets a network security group definition
/networkSecurityGroups/write Creates a network security group or updates an existing

network security group
/networkSecurityGroups/delete Deletes a network security group
/networkSecurityGroups/join/action Joins a network security group
/networkSecurityGroups/defaultSecurityRules/read Gets a default security rule definition
/networkSecurityGroups/securityRules/read Gets a security rule definition
/networkSecurityGroups/securityRules/write Creates a security rule or updates an existing security rule
/networkSecurityGroups/securityRules/delete Deletes a security rule
/applicationGateways/read Gets an application gateway
/applicationGateways/write Creates an application gateway or updates an application

gateway
/applicationGateways/delete Deletes an application gateway
/applicationGateways/backendhealth/action Gets an application gateway backend health

/applicationGateways/start/action Starts an application gateway
/applicationGateways/stop/action Stops an application gateway
/applicationGateways/backendAddressPools/join/action Joins an application gateway backend address pool
/routeTables/read Gets a route table definition
/routeTables/write Creates a route table or Updates an existing rotue table
/routeTables/delete Deletes a route table definition
/routeTables/join/action Joins a route table
/routeTables/routes/read Gets a route definition
/routeTables/routes/write Creates a route or Updates an existing route
/routeTables/routes/delete Deletes a route definition
/locations/operationResults/read Gets operation result of an async POST or DELETE operation
/locations/checkDnsNameAvailability/read Checks if dns label is available at the specified location
/locations/usages/read Gets the resources usage metrics
/locations/operations/read Gets operation resource that represents status of an

asynchronous operation
Microsoft.NotificationHubs
/register/action Registers the subscription for the NotifciationHubs resource

provider and enables the creation of Namespaces and
NotificationHubs
/CheckNamespaceAvailability/action Checks whether or not a given Namespace resource name is

available within the NotificationHub service.
/Namespaces/write Create a Namespace Resource and Update its properties. Tags

updated.
/Namespaces/read Get the list of Namespace Resource Description
/Namespaces/Delete Delete Namespace Resource
/Namespaces/authorizationRules/action Get the list of Namespaces Authorization Rules description.

/Namespaces/CheckNotificationHubAvailability/action Checks whether or not a given NotificationHub name is

available inside a Namespace.
/Namespaces/authorizationRules/write Create a Namespace level Authorization Rules and update its

/Namespaces/authorizationRules/read Get the list of Namespaces Authorization Rules description.
/Namespaces/authorizationRules/delete Delete Namespace Authorization Rule. The Default Namespace

/Namespaces/authorizationRules/listkeys/action Get the Connection String to the Namespace
/Namespaces/authorizationRules/regenerateKeys/action Namespace Authorization Rule Regenerate

Primary/SecondaryKey, Specify the Key that needs to be
regenerated
/Namespaces/NotificationHubs/write Create a Notification Hub and Update its properties. Its

properties mainly include PNS Credentials. Authorization Rules
and TTL
/Namespaces/NotificationHubs/read Get list of Notification Hub Resource Descriptions
/Namespaces/NotificationHubs/Delete Delete Notification Hub Resource
/Namespaces/NotificationHubs/authorizationRules/action Get the list of Notification Hub Authorization Rules
/Namespaces/NotificationHubs/pnsCredentials/action Get All Notification Hub PNS Credentials. This includes, WNS,
MPNS, APNS, GCM and Baidu credentials
/Namespaces/NotificationHubs/debugSend/action Send a test push notification.
/Namespaces/NotificationHubs/metricDefinitions/read Get list of Namespace metrics Resource Descriptions
/Namespaces/NotificationHubs/ Create Notification Hub Authorization Rules and Update its

authorizationRules/write properties. The Authorization Rules Access Rights, the Primary
/Namespaces/NotificationHubs/ Get the list of Notification Hub Authorization Rules

authorizationRules/read
/Namespaces/NotificationHubs/ Delete Notification Hub Authorization Rules

authorizationRules/delete
/Namespaces/NotificationHubs/ Get the Connection String to the Notification Hub

authorizationRules/listkeys/action
/Namespaces/NotificationHubs/ Notification Hub Authorization Rule Regenerate

authorizationRules/regenerateKeys/action Primary/SecondaryKey, Specify the Key that needs to be
regenerated
Microsoft.OperationalInsights
/register/action Register a subscription to a resource provider.
/linkTargets/read Lists existing accounts that are not associated with an Azure
subscription. To link this Azure subscription to a workspace,
use a customer id returned by this operation in the customer
id property of the Create Workspace operation.
/workspaces/write Creates a new workspace or links to an existing workspace by

providing the customer id from the existing workspace.
/workspaces/read Gets an existing workspace
/workspaces/delete Deletes a workspace. If the workspace was linked to an

existing workspace at creation time then the workspace it was
linked to is not deleted.
/workspaces/generateregistrationcertificate/action Generates Registration Certificate for the workspace. This

Certificate is used to connect Microsoft System Center
Operation Manager to the workspace.
/workspaces/sharedKeys/action Retrieves the shared keys for the workspace. These keys are
used to connect Microsoft Operational Insights agents to the
workspace.
/workspaces/search/action Executes a search query
/workspaces/datasources/read Get datasources under a workspace.
/workspaces/datasources/write Create/Update datasources under a workspace.
/workspaces/datasources/delete Delete datasources under a workspace.
/workspaces/managementGroups/read Gets the names and metadata for System Center Operations
Manager management groups connected to this workspace.
/workspaces/schema/read Gets the search schema for the workspace. Search schema
includes the exposed fields and their types.
/workspaces/usages/read Gets usage data for a workspace including the amount of data
read by the workspace.
/workspaces/intelligencepacks/read Lists all intelligence packs that are visible for a given
worksapce and also lists whether the pack is enabled or
disabled for that workspace.
/workspaces/intelligencepacks/enable/action Enables an intelligence pack for a given workspace.
/workspaces/intelligencepacks/disable/action Disables an intelligence pack for a given workspace.
/workspaces/sharedKeys/read Retrieves the shared keys for the workspace. These keys are
used to connect Microsoft Operational Insights agents to the
workspace.
/workspaces/savedSearches/read Gets a saved search query
/workspaces/savedSearches/write Creates a saved search query
/workspaces/savedSearches/delete Deletes a saved search query
/workspaces/storageinsightconfigs/write Creates a new storage configuration. These configurations are

used to pull data from a location in an existing storage
account.
/workspaces/storageinsightconfigs/read Gets a storage configuration.
/workspaces/storageinsightconfigs/delete Deletes a storage configuration. This will stop Microsoft

Operational Insights from reading data from the storage
account.
/workspaces/configurationScopes/read Get Configuration Scope
/workspaces/configurationScopes/write Set Configuration Scope
/workspaces/configurationScopes/delete Delete Configuration Scope
Microsoft.OperationsManagement
/register/action Register a subscription to a resource provider.
/solutions/write Create new OMS solution
/solutions/read Get exiting OMS solution
/solutions/delete Delete existing OMS solution
Microsoft.RecoveryServices
/Vaults/backupJobsExport/action Export Jobs
/Vaults/write Create Vault operation creates an Azure resource of type

'vault'
/Vaults/read The Get Vault operation gets an object representing the Azure
resource of type 'vault'
/Vaults/delete The Delete Vault operation deletes the specified Azure

/Vaults/refreshContainers/read Refreshes the container list

/Vaults/backupJobsExport/operationResults/read Returns the Result of Export Job Operation.
/Vaults/backupOperationResults/read Returns Backup Operation Result for Recovery Services Vault.
/Vaults/monitoringAlerts/read Gets the alerts for the Recovery services vault.
/Vaults/monitoringAlerts/{uniqueAlertId}/read Gets the details of the alert.
/Vaults/backupSecurityPIN/read Returns Security PIN Information for Recovery Services Vault.
/vaults/replicationEvents/read Read Any Events
/Vaults/backupProtectableItems/read Returns list of all Protectable Items.
/vaults/replicationFabrics/read Read Any Fabrics
/vaults/replicationFabrics/write Create or Update Any Fabrics
/vaults/replicationFabrics/remove/action Remove Fabric
/vaults/replicationFabrics/checkConsistency/action Checks Consistency of the Fabric
/vaults/replicationFabrics/delete Delete Any Fabrics
/vaults/replicationFabrics/renewcertificate/action
/vaults/replicationFabrics/deployProcessServerImage/action Deploy Process Server Image
/vaults/replicationFabrics/reassociateGateway/action Reassociate Gateway
/vaults/replicationFabrics/replicationRecoveryServicesProviders Read Any Recovery Services Providers

/
read
/vaults/replicationFabrics/replicationRecoveryServicesProviders Remove Recovery Services Provider

/
remove/action
/vaults/replicationFabrics/replicationRecoveryServicesProviders Delete Any Recovery Services Providers

/
delete
/vaults/replicationFabrics/replicationRecoveryServicesProviders Refresh Provider

/
refreshProvider/action
/vaults/replicationFabrics/replicationStorageClassifications/read Read Any Storage Classifications
/vaults/replicationFabrics/replicationStorageClassifications/ Read Any Storage Classification Mappings

replicationStorageClassificationMappings/read
/vaults/replicationFabrics/replicationStorageClassifications/ Create or Update Any Storage Classification Mappings

replicationStorageClassificationMappings/write
/vaults/replicationFabrics/replicationStorageClassifications/ Delete Any Storage Classification Mappings

replicationStorageClassificationMappings/delete
/vaults/replicationFabrics/replicationvCenters/read Read Any Jobs
/vaults/replicationFabrics/replicationvCenters/write Create or Update Any Jobs
/vaults/replicationFabrics/replicationvCenters/delete Delete Any Jobs
/vaults/replicationFabrics/replicationNetworks/read Read Any Networks
/vaults/replicationFabrics/replicationNetworks/ Read Any Network Mappings

replicationNetworkMappings/read
/vaults/replicationFabrics/replicationNetworks/ Create or Update Any Network Mappings

replicationNetworkMappings/write
/vaults/replicationFabrics/replicationNetworks/ Delete Any Network Mappings

replicationNetworkMappings/delete
/vaults/replicationFabrics/replicationProtectionContainers/ Read Any Protection Containers

read
/vaults/replicationFabrics/replicationProtectionContainers/ Discover Protectable Item

discoverProtectableItem/action
/vaults/replicationFabrics/replicationProtectionContainers/ Create or Update Any Protection Containers

write
/vaults/replicationFabrics/replicationProtectionContainers/ Remove Protection Container

remove/action
/vaults/replicationFabrics/replicationProtectionContainers/ Switch Protection Container

switchprotection/action
/vaults/replicationFabrics/replicationProtectionContainers/ Read Any Protectable Items

replicationProtectableItems/read
/vaults/replicationFabrics/replicationProtectionContainers/ Read Any Protection Container Mappings

replicationProtectionContainerMappings/read
/vaults/replicationFabrics/replicationProtectionContainers/ Create or Update Any Protection Container Mappings

replicationProtectionContainerMappings/write
/vaults/replicationFabrics/replicationProtectionContainers/ Remove Protection Container Mapping

replicationProtectionContainerMappings/remove/action
/vaults/replicationFabrics/replicationProtectionContainers/ Delete Any Protection Container Mappings

replicationProtectionContainerMappings/delete
/vaults/replicationFabrics/replicationProtectionContainers/ Read Any Protected Items

replicationProtectedItems/read
/vaults/replicationFabrics/replicationProtectionContainers/ Create or Update Any Protected Items

replicationProtectedItems/write
/vaults/replicationFabrics/replicationProtectionContainers/ Delete Any Protected Items

replicationProtectedItems/delete
/vaults/replicationFabrics/replicationProtectionContainers/ Remove Protected Item

replicationProtectedItems/remove/action
/vaults/replicationFabrics/replicationProtectionContainers/ Planned Failover

replicationProtectedItems/plannedFailover/action
/vaults/replicationFabrics/replicationProtectionContainers/ Failover
replicationProtectedItems/unplannedFailover/action
/vaults/replicationFabrics/replicationProtectionContainers/ Test Failover

replicationProtectedItems/testFailover/action
/vaults/replicationFabrics/replicationProtectionContainers/ Test Failover Cleanup

replicationProtectedItems/testFailoverCleanup/action
/vaults/replicationFabrics/replicationProtectionContainers/ Failover Commit

replicationProtectedItems/failoverCommit/action
/vaults/replicationFabrics/replicationProtectionContainers/ ReProtect Protected Item

replicationProtectedItems/reProtect/action
/vaults/replicationFabrics/replicationProtectionContainers/ Update Mobility Service

replicationProtectedItems/updateMobilityService/action
/vaults/replicationFabrics/replicationProtectionContainers/ Repair replication

replicationProtectedItems/repairReplication/action
/vaults/replicationFabrics/replicationProtectionContainers/ Apply Recovery Point

replicationProtectedItems/applyRecoveryPoint/action
/vaults/replicationFabrics/replicationProtectionContainers/ Read Any Replication Recovery Points

replicationProtectedItems/recoveryPoints/read
/vaults/replicationPolicies/read Read Any Policies
/vaults/replicationPolicies/write Create or Update Any Policies
/vaults/replicationPolicies/delete Delete Any Policies
/vaults/replicationRecoveryPlans/read Read Any Recovery Plans
/vaults/replicationRecoveryPlans/write Create or Update Any Recovery Plans
/vaults/replicationRecoveryPlans/delete Delete Any Recovery Plans

/vaults/replicationRecoveryPlans/plannedFailover/action Planned Failover Recovery Plan
/vaults/replicationRecoveryPlans/unplannedFailover/action Failover Recovery Plan
/vaults/replicationRecoveryPlans/testFailover/action Test Failover Recovery Plan
/vaults/replicationRecoveryPlans/testFailoverCleanup/action Test Failover Cleanup Recovery Plan
/vaults/replicationRecoveryPlans/failoverCommit/action Failover Commit Recovery Plan
/vaults/replicationRecoveryPlans/reProtect/action ReProtect Recovery Plan
/Vaults/extendedInformation/read The Get Extended Info operation gets an object's Extended

Info representing the Azure resource of type ?vault?
/Vaults/extendedInformation/write The Get Extended Info operation gets an object's Extended

/Vaults/extendedInformation/delete The Get Extended Info operation gets an object's Extended

/Vaults/backupManagementMetaData/read Returns Backup Management Metadata for Recovery Services

Vault.
/Vaults/backupProtectionContainers/read Returns all containers belonging to the subscription
/Vaults/backupFabrics/operationResults/read Returns status of the operation
/Vaults/backupFabrics/protectionContainers/read Returns all registered containers
/Vaults/backupFabrics/protectionContainers/ Gets result of Operation performed on Protection Container.

operationResults/read
/Vaults/backupFabrics/protectionContainers/ Returns object details of the Protected Item

protectedItems/read
/Vaults/backupFabrics/protectionContainers/ Create a backup Protected Item

protectedItems/write
/Vaults/backupFabrics/protectionContainers/ Deletes Protected Item

protectedItems/delete
/Vaults/backupFabrics/protectionContainers/ Performs Backup for Protected Item.

protectedItems/backup/action
/Vaults/backupFabrics/protectionContainers/ Gets Result of Operation Performed on Protected Items.

protectedItems/operationResults/read
/Vaults/backupFabrics/protectionContainers/ Returns the status of Operation performed on Protected

protectedItems/operationStatus/read Items.
/Vaults/backupFabrics/protectionContainers/ Get Recovery Points for Protected Items.

protectedItems/recoveryPoints/read
/Vaults/backupFabrics/protectionContainers/ Restore Recovery Points for Protected Items.

protectedItems/recoveryPoints/
restore/action
/Vaults/backupFabrics/protectionContainers/ Provision Instant Item Recovery for Protected Item

provisionInstantItemRecovery/action
/Vaults/backupFabrics/protectionContainers/ Revoke Instant Item Recovery for Protected Item

revokeInstantItemRecovery/action
/Vaults/usages/read Returns usage details for a Recovery Services Vault.
/vaults/usages/read Read Any Vault Usages
/Vaults/certificates/write The Update Resource Certificate operation updates the

resource/vault credential certificate.
/Vaults/tokenInfo/read Returns token information for Recovery Services Vault.
/vaults/replicationAlertSettings/read Read Any Alerts Settings
/vaults/replicationAlertSettings/write Create or Update Any Alerts Settings
/Vaults/backupOperations/read Returns Backup Operation Status for Recovery Services Vault.
/Vaults/storageConfig/read Returns Storage Configuration for Recovery Services Vault.
/Vaults/storageConfig/write Updates Storage Configuration for Recovery Services Vault.
/Vaults/backupUsageSummaries/read Returns summaries for Protected Items and Protected Servers

for a Recovery Services .
/Vaults/backupProtectedItems/read Returns the list of all Protected Items.
/Vaults/backupconfig/vaultconfig/read Returns Configuration for Recovery Services Vault.
/Vaults/backupconfig/vaultconfig/write Updates Configuration for Recovery Services Vault.
/Vaults/registeredIdentities/write The Register Service Container operation can be used to

register a container with Recovery Service.
/Vaults/registeredIdentities/read The Get Containers operation can be used get the containers
registered for a resource.
/Vaults/registeredIdentities/delete The UnRegister Container operation can be used to unregister

a container.
/Vaults/registeredIdentities/operationResults/read The Get Operation Results operation can be used get the
operation status and result for the asynchronously submitted
operation
/vaults/replicationJobs/read Read Any Jobs
/vaults/replicationJobs/cancel/action Cancel Job
/vaults/replicationJobs/restart/action Restart job
/vaults/replicationJobs/resume/action Resume Job
/Vaults/backupPolicies/read Returns all Protection Policies
/Vaults/backupPolicies/write Creates Protection Policy
/Vaults/backupPolicies/delete Delete a Protection Policy
/Vaults/backupPolicies/operationResults/read Get Results of Policy Operation.
/Vaults/backupPolicies/operationStatus/read Get Status of Policy Operation.
/Vaults/vaultTokens/read The Vault Token operation can be used to get Vault Token for
vault level backend operations.
/Vaults/monitoringConfigurations/notificationConfiguration/re Gets the Recovery services vault notification configuration.

ad
/Vaults/backupJobs/read Returns all Job Objects
/Vaults/backupJobs/cancel/action Cancel the Job
/Vaults/backupJobs/operationResults/read Returns the Result of Job Operation.
/locations/allocateStamp/action AllocateStamp is internal operation used by service
/locations/allocatedStamp/read GetAllocatedStamp is internal operation used by service
Microsoft.Relay
/checkNamespaceAvailability/action Checks availability of namespace under given subscription.
/register/action Registers the subscription for the Relay resource provider and
enables the creation of Relay resources

updated.


/namespaces/HybridConnections/write Create or Update HybridConnection properties.
/namespaces/HybridConnections/read Get list of HybridConnection Resource Descriptions
/namespaces/HybridConnections/Delete Operation to delete HybridConnection Resource
/namespaces/HybridConnections/authorizationRules/write Create HybridConnection Authorization Rules and Update its

/namespaces/HybridConnections/authorizationRules/delete Operation to delete HybridConnection Authorization Rules
/namespaces/HybridConnections/authorizationRules/listkeys/a Get the Connection String to HybridConnection

ction
/namespaces/WcfRelays/write Create or Update WcfRelay properties.
/namespaces/WcfRelays/read Get list of WcfRelay Resource Descriptions
/namespaces/WcfRelays/Delete Operation to delete WcfRelay Resource
/namespaces/WcfRelays/authorizationRules/write Create WcfRelay Authorization Rules and Update its

/namespaces/WcfRelays/authorizationRules/delete Operation to delete WcfRelay Authorization Rules
/namespaces/WcfRelays/authorizationRules/listkeys/action Get the Connection String to WcfRelay
Microsoft.ResourceHealth
/AvailabilityStatuses/read Gets the availability statuses for all resources in the specified
scope
/AvailabilityStatuses/current/read Gets the availability status for the specified resource

Microsoft.Resources
/checkResourceName/action Check the resource name for validity.
/providers/read Get the list of providers.
/subscriptions/read Gets the list of subscriptions.
/subscriptions/operationresults/read Get the subscription operation results.
/subscriptions/providers/read Gets or lists resource providers.
/subscriptions/tagNames/read Gets or lists subscription tags.
/subscriptions/tagNames/write Adds a subscription tag.
/subscriptions/tagNames/delete Deletes a subscription tag.
/subscriptions/tagNames/tagValues/read Gets or lists subscription tag values.
/subscriptions/tagNames/tagValues/write Adds a subscription tag value.
/subscriptions/tagNames/tagValues/delete Deletes a subscription tag value.
/subscriptions/resources/read Gets resources of a subscription.
/subscriptions/resourceGroups/read Gets or lists resource groups.
/subscriptions/resourceGroups/write Creates or updates a resource group.
/subscriptions/resourceGroups/delete Deletes a resource group and all its resources.
/subscriptions/resourceGroups/moveResources/action Moves resources from one resource group to another.
/subscriptions/resourceGroups/validateMoveResources/action Validate move of resources from one resource group to

another.
/subscriptions/resourcegroups/resources/read Gets the resources for the resource group.
/subscriptions/resourcegroups/deployments/read Gets or lists deployments.
/subscriptions/resourcegroups/deployments/write Creates or updates an deployment.
/subscriptions/resourcegroups/deployments/operationstatuses Gets or lists deployment operation statuses.

/read
/subscriptions/resourcegroups/deployments/operations/read Gets or lists deployment operations.
/subscriptions/locations/read Gets the list of locations supported.
/links/read Gets or lists resource links.

/links/write Creates or updates a resource link.
/links/delete Deletes a resource link.
/tenants/read Gets the list of tenants.
/resources/read Get the list of resources based upon filters.
/deployments/read Gets or lists deployments.
/deployments/write Creates or updates an deployment.
/deployments/delete Deletes a deployment.
/deployments/cancel/action Cancels a deployment.
/deployments/validate/action Validates an deployment.
/deployments/operations/read Gets or lists deployment operations.
Microsoft.Scheduler
/jobcollections/read Get Job Collection
/jobcollections/write Creates or updates job collection.
/jobcollections/delete Deletes job collection.
/jobcollections/enable/action Enables job collection.
/jobcollections/disable/action Disables job collection.
/jobcollections/jobs/read Gets job.
/jobcollections/jobs/write Creates or updates job.
/jobcollections/jobs/delete Deletes job.
/jobcollections/jobs/run/action Runs job.
/jobcollections/jobs/generateLogicAppDefinition/action Generates Logic App definition based on a Scheduler Job.
/jobcollections/jobs/jobhistories/read Gets job history.
Microsoft.Search
/register/action Registers the subscription for the search resource provider and
enables the creation of search services.
/checkNameAvailability/action Checks availability of the service name.
/searchServices/write Creates or updates the search service.
/searchServices/read Reads the search service.
/searchServices/delete Deletes the search service.
/searchServices/start/action Starts the search service.
/searchServices/stop/action Stops the search service.
/searchServices/listAdminKeys/action Reads the admin keys.
/searchServices/regenerateAdminKey/action Regenerates the admin key.
/searchServices/createQueryKey/action Creates the query key.
/searchServices/queryKey/read Reads the query keys.
/searchServices/queryKey/delete Deletes the query key.
Microsoft.Security
/jitNetworkAccessPolicies/read Gets the just-in-time network access policies
/jitNetworkAccessPolicies/write Creates a new just-in-time network access policy or updates

an existing one
/jitNetworkAccessPolicies/initiate/action Initiates a just-in-time network access policy
/securitySolutionsReferenceData/read Gets the security solutions reference data
/securityStatuses/read Gets the security health statuses for Azure resources
/webApplicationFirewalls/read Gets the web application firewalls
/webApplicationFirewalls/write Creates a new web application firewall or updates an existing

one
/webApplicationFirewalls/delete Deletes a web application firewall
/securitySolutions/read Gets the security solutions
/securitySolutions/write Creates a new security solution or updates an existing one

/securitySolutions/delete Deletes a security solution
/tasks/read Gets all available security recommendations
/tasks/dismiss/action Dismiss a security recommendation
/tasks/activate/action Activate a security recommendation
/policies/read Gets the security policy
/policies/write Updates the security policy
/applicationWhitelistings/read Gets the application whitelistings
/applicationWhitelistings/write Creates a new application whitelisting or updates an existing

one
Microsoft.ServerManagement
/subscriptions/write Creates or updates a subscription
/gateways/write Creates or updates a gateway
/gateways/delete Deletes a gateway
/gateways/read Gets a gateway
/gateways/regenerateprofile/action Regenerates the gateway profile
/gateways/upgradetolatest/action Upgrades the gateway to the latest version
/nodes/write creates or updates a node
/nodes/delete Deletes a node
/nodes/read Gets a node
/sessions/write Creates or updates a session
/sessions/read Gets a session
/sessions/delete Deletes a sesssion
Microsoft.ServiceBus
/checkNameAvailability/action Checks availability of namespace under given subscription.
/register/action Registers the subscription for the ServiceBus resource provider

and enables the creation of ServiceBus resources

updated.
/namespaces/metricDefinitions/read Get list of Namespace metrics Resource Descriptions

/namespaces/authorizationRules/read Get the list of Namespaces Authorization Rules description.

/namespaces/authorizationRules/regenerateKeys/action Regenerate the Primary or Secondary key to the Resource
/namespaces/diagnosticSettings/read Get list of Namespace diagnostic settings Resource

Descriptions
/namespaces/diagnosticSettings/write Get list of Namespace diagnostic settings Resource

Descriptions
/namespaces/queues/write Create or Update Queue properties.
/namespaces/queues/read Get list of Queue Resource Descriptions
/namespaces/queues/Delete Operation to delete Queue Resource
/namespaces/queues/authorizationRules/write Create Queue Authorization Rules and Update its properties.

The Authorization Rules Access Rights, the Primary and
Secondary Keys can be updated.
/namespaces/queues/authorizationRules/read Get the list of Queue Authorization Rules
/namespaces/queues/authorizationRules/delete Operation to delete Queue Authorization Rules
/namespaces/queues/authorizationRules/listkeys/action Get the Connection String to Queue
/namespaces/queues/authorizationRules/regenerateKeys/actio Regenerate the Primary or Secondary key to the Resource

n
/namespaces/logDefinitions/read Get list of Namespace logs Resource Descriptions
/namespaces/topics/write Create or Update Topic properties.
/namespaces/topics/read Get list of Topic Resource Descriptions
/namespaces/topics/Delete Operation to delete Topic Resource
/namespaces/topics/authorizationRules/write Create Topic Authorization Rules and Update its properties.

The Authorization Rules Access Rights, the Primary and
Secondary Keys can be updated.
/namespaces/topics/authorizationRules/read Get the list of Topic Authorization Rules
/namespaces/topics/authorizationRules/delete Operation to delete Topic Authorization Rules
/namespaces/topics/authorizationRules/listkeys/action Get the Connection String to Topic
/namespaces/topics/authorizationRules/regenerateKeys/action Regenerate the Primary or Secondary key to the Resource
/namespaces/topics/subscriptions/write Create or Update TopicSubscription properties.
/namespaces/topics/subscriptions/read Get list of TopicSubscription Resource Descriptions
/namespaces/topics/subscriptions/Delete Operation to delete TopicSubscription Resource
/namespaces/topics/subscriptions/rules/write Create or Update Rule properties.
/namespaces/topics/subscriptions/rules/read Get list of Rule Resource Descriptions
/namespaces/topics/subscriptions/rules/Delete Operation to delete Rule Resource
Microsoft.Sql
/servers/read Return a list of servers in a resource group on a subscription
/servers/write Create a new server or modify properties of existing server in a

resource group on a subscription
/servers/delete Delete a server and all contained databases and elastic pools
/servers/import/action Create a new database on the server and deploy schema and
data from a DacPac package
/servers/upgrade/action Enable new functionality available on the latest version of

server and specify databases edition conversion map
/servers/VulnerabilityAssessmentScans/action Execute vulnerability assessment server scan

/servers/operationResults/read Operation is used to track progress of server upgrade from

lower version to higher
/servers/operationResults/delete Abort server version upgrade in progress
/servers/securityAlertPolicies/read Retrieve details of the server threat detection policy configured

on a given server
/servers/securityAlertPolicies/write Change the server threat detection for a given server
/servers/securityAlertPolicies/operationResults/read Retrieve results of the server Threat Detection policy Set

operation
/servers/administrators/read Retrieve server administrator details
/servers/administrators/write Create or update server administrator
/servers/administrators/delete Delete server administrator from the server
/servers/recoverableDatabases/read This operation is used for disaster recovery of live database to

restore database to last-known good backup point. It returns
information about the last good backup but it doesn't actually
restore the database.
/servers/serviceObjectives/read Retrieve list of service level objectives (also known as

performance tiers) available on a given server
/servers/firewallRules/read Retrieve server firewall rule details
/servers/firewallRules/write Create or update server firewall rule that controls IP address

range allowed to connect to the server
/servers/firewallRules/delete Delete firewall rule from the server
/servers/administratorOperationResults/read Retrieve server administrator operation results
/servers/recommendedElasticPools/read Retrieve recommendation for elastic database pools to reduce

cost or improve performance based on historica resource
utilization
/servers/recommendedElasticPools/metrics/read Retrieve metrics for recommended elastic database pools for a

given server
/servers/recommendedElasticPools/databases/read Retrieve databases that should be added into recommended

elastic database pools for a given server
/servers/elasticPools/read Retrieve details of elastic database pool on a given server
/servers/elasticPools/write Create a new or change properties of existing elastic database

pool
/servers/elasticPools/delete Delete existing elastic database pool

/servers/elasticPools/operationResults/read Retrieve details on a given elastic database pool operation
/servers/elasticPools/providers/Microsoft.Insights/ Return types of metrics that are available for elastic database
metricDefinitions/read pools
/servers/elasticPools/providers/Microsoft.Insights/ Gets the diagnostic setting for the resource

diagnosticSettings/read
/servers/elasticPools/providers/Microsoft.Insights/ Creates or updates the diagnostic setting for the resource

diagnosticSettings/write
/servers/elasticPools/metrics/read Return elastic database pool resource utilization metrics
/servers/elasticPools/elasticPoolDatabaseActivity/read Retrieve activities and details on a given database that is part

of elastic database pool
/servers/elasticPools/advisors/read Returns list of advisors available for the elastic pool
/servers/elasticPools/advisors/write Update auto-execute status of an advisor on elastic pool level.
/servers/elasticPools/advisors/recommendedActions/read Returns list of recommended actions of specified advisor for

the elastic pool
/servers/elasticPools/advisors/recommendedActions/write Apply the recommended action on the elastic pool
/servers/elasticPools/elasticPoolActivity/read Retrieve activities and details on a given elastic database pool
/servers/elasticPools/databases/read Retrieve list and details of databases that are part of elastic
database pool on a given server
/servers/auditingPolicies/read Retrieve details of the default server table auditing policy

configured on a given server
/servers/auditingPolicies/write Change the default server table auditing for a given server
/servers/disasterRecoveryConfiguration/operationResults/read Get Disaster Recovery Configuration Operation Results
/servers/advisors/read Returns list of advisors available for the server
/servers/advisors/write Updates auto-execute status of an advisor on server level.
/servers/advisors/recommendedActions/read Returns list of recommended actions of specified advisor for

the server
/servers/advisors/recommendedActions/write Apply the recommended action on the server
/servers/usages/read Return server DTU quota and current DTU consuption by all
databases within the server
/servers/elasticPoolEstimates/read Returns list of elastic pool estimates already created for this
server
/servers/elasticPoolEstimates/write Creates new elastic pool estimate for list of databases

provided
/servers/auditingSettings/read Retrieve details of the server blob auditing policy configured

on a given server
/servers/auditingSettings/write Change the server blob auditing for a given server
/servers/auditingSettings/operationResults/read Retrieve result of the server blob auditing policy Set operation
/servers/backupLongTermRetentionVaults/read This operation is used to get a backup long term retention

vault. It returns information about the vault registered to this
server.
/servers/backupLongTermRetentionVaults/write Register a backup long term retention vault
/servers/restorableDroppedDatabases/read Retrieve a list of databases that were dropped on a given

server that are still within retention policy. This operation
returns a list of databases and associated metadata, like date
of deletion.
/servers/databases/read Return a list of servers in a resource group on a subscription
/servers/databases/write Create a new server or modify properties of existing server in a

resource group on a subscription
/servers/databases/delete Delete a server and all contained databases and elastic pools
/servers/databases/export/action Create a new database on the server and deploy schema and
data from a DacPac package
/servers/databases/VulnerabilityAssessmentScans/action Execute vulnerability assessment database scan.
/servers/databases/pause/action Pause a DataWarehouse edition database
/servers/databases/resume/action Resume a DataWarehouse edition database
/servers/databases/operationResults/read Operation is used to track progress of long running database

operation, such as scale.
/servers/databases/replicationLinks/read Return details about replication links established for a

particular database
/servers/databases/replicationLinks/delete Terminate the replication relationship forcefully and with

potential data loss
/servers/databases/replicationLinks/unlink/action Terminate the replication relationship forcefully or after

synchronizing with the partner
/servers/databases/replicationLinks/failover/action Failover after synchronizing all changes from the primary,

making this database into the replication relationship's
primary and making the remote primary into a secondary
/servers/databases/replicationLinks/forceFailoverAllowDataLos Failover immediately with potential data loss, making this

s/action database into the replication relationship's primary and
making the remote primary into a secondary
/servers/databases/replicationLinks/updateReplicationMode/ac Update replication mode for link to synchronous or

tion asynchronous mode
/servers/databases/replicationLinks/operationResults/read Get status of long-running operations on database replication

links
/servers/databases/dataMaskingPolicies/read Retrieve details of the data masking policy configured on a

given database
/servers/databases/dataMaskingPolicies/write Change data masking policy for a given database
/servers/databases/dataMaskingPolicies/rules/read Retrieve details of the data masking policy rule configured on

a given database
/servers/databases/dataMaskingPolicies/rules/write Change data masking policy rule for a given database
/servers/databases/securityAlertPolicies/read Retrieve details of the threat detection policy configured on a

given database
/servers/databases/securityAlertPolicies/write Change the threat detection policy for a given database
/servers/databases/providers/Microsoft.Insights/ Return types of metrics that are available for databases

metricDefinitions/read
/servers/databases/providers/Microsoft.Insights/ Gets the diagnostic setting for the resource

diagnosticSettings/read
/servers/databases/providers/Microsoft.Insights/ Creates or updates the diagnostic setting for the resource

diagnosticSettings/write
/servers/databases/providers/Microsoft.Insights/ Gets the available logs for databases

logDefinitions/read
/servers/databases/topQueries/read Returns aggregated runtime statistics for selected query in

selected time period
/servers/databases/topQueries/queryText/read Returns the Transact-SQL text for selected query ID
/servers/databases/topQueries/statistics/read Returns aggregated runtime statistics for selected query in

selected time period
/servers/databases/connectionPolicies/read Retrieve details of the connection policy configured on a given

database
/servers/databases/connectionPolicies/write Change connection policy for a given database
/servers/databases/metrics/read Return database resource utilization metrics
/servers/databases/auditRecords/read Retrieve the database blob audit records

/servers/databases/transparentDataEncryption/read Retrieve status and details of transparent data encryption

security feature for a given database
/servers/databases/transparentDataEncryption/write Enable or disable transparent data encryption for a given

database
/servers/databases/transparentDataEncryption/operationResul Retrieve status and details of transparent data encryption

ts/read security feature for a given database
/servers/databases/auditingPolicies/read Retrieve details of the table auditing policy configured on a

given database
/servers/databases/auditingPolicies/write Change the table auditing policy for a given database
/servers/databases/dataWarehouseQueries/read Returns the data warehouse distribution query information for

selected query ID
/servers/databases/dataWarehouseQueries/ Returns the distributed query step information of data

dataWarehouseQuerySteps/read warehouse query for selected step ID
/servers/databases/serviceTierAdvisors/read Return suggestion about scaling database up or down based

on query execution statistics to improve performance or
reduce cost
/servers/databases/advisors/read Returns list of advisors available for the database
/servers/databases/advisors/write Update auto-execute status of an advisor on database level.
/servers/databases/advisors/recommendedActions/read Returns list of recommended actions of specified advisor for

the database
/servers/databases/advisors/recommendedActions/write Apply the recommended action on the database
/servers/databases/usages/read Return database maxiumum size that can be reached and

current size occupied by data
/servers/databases/queryStore/read Returns current values of Query Store settings for the

database
/servers/databases/queryStore/write Updates Query Store setting for the database
/servers/databases/auditingSettings/read Retrieve details of the blob auditing policy configured on a

given database
/servers/databases/auditingSettings/write Change the blob auditing policy for a given database
/servers/databases/schemas/tables/recommendedIndexes/read Retrieve list of index recommendations on a database
/servers/databases/schemas/tables/recommendedIndexes/writ Apply index recommendation

e
/servers/databases/schemas/tables/columns/read Retrieve list of columns of a table

/servers/databases/missingindexes/read Return suggestions about database indexes to create, modify

or delete in order to improve query performance
/servers/databases/missingindexes/write Use database index recommendation in a particular database
/servers/databases/importExportOperationResults/read Return details about database import or export operation

from DacPac located in storage account
/servers/importExportOperationResults/read Return the list with details for database import operations
from storage account on a given server
Microsoft.Storage
/register/action Registers the subscription for the storage resource provider

and enables the creation of storage accounts.
/checknameavailability/read Checks that account name is valid and is not in use.
/storageAccounts/write Creates a storage account with the specified parameters or

update the properties or tags or adds custom domain for the
specified storage account.
/storageAccounts/delete Deletes an existing storage account.
/storageAccounts/listkeys/action Returns the access keys for the specified storage account.
/storageAccounts/regeneratekey/action Regenerates the access keys for the specified storage account.
/storageAccounts/read Returns the list of storage accounts or gets the properties for
the specified storage account.
/storageAccounts/listAccountSas/action Returns the Account SAS token for the specified storage
account.
/storageAccounts/listServiceSas/action Storage Service SAS Token
/storageAccounts/services/diagnosticSettings/write Create/Update storage account diagnostic settings.
/skus/read Lists the Skus supported by Microsoft.Storage.
/usages/read Returns the limit and the current usage count for resources in
the specified subscription
/operations/read Polls the status of an asynchronous operation.
/locations/deleteVirtualNetworkOrSubnets/action Notifies Microsoft.Storage that virtual network or subnet is

being deleted
Microsoft.StorSimple
/managers/clearAlerts/action Clear all the alerts associated with the device manager.
/managers/getActivationKey/action Get activation key for the device manager.
/managers/regenerateActivationKey/action Regenerate activation key for the device manager.
/managers/regenarateRegistationCertificate/action Regenerate registration certificate for the device managers.
/managers/getEncryptionKey/action Get encryption key for the device manager.
/managers/read Lists or gets the Device Managers
/managers/delete Deletes the Device Managers
/managers/write Create or update the Device Managers
/managers/configureDevice/action Configures a device
/managers/listActivationKey/action Gets the activation key of the StorSimple Device Manager.
/managers/listPublicEncryptionKey/action List public encryption keys of a StorSimple Device Manager.
/managers/listPrivateEncryptionKey/action Gets private encryption key for a StorSimple Device Manager.
/managers/provisionCloudAppliance/action Create a new cloud appliance.
/Managers/write Create Vault operation creates an Azure resource of type

'vault'
/Managers/read The Get Vault operation gets an object representing the Azure
/Managers/delete The Delete Vault operation deletes the specified Azure

/managers/storageAccountCredentials/write Create or update the Storage Account Credentials
/managers/storageAccountCredentials/read Lists or gets the Storage Account Credentials
/managers/storageAccountCredentials/delete Deletes the Storage Account Credentials
/managers/storageAccountCredentials/listAccessKey/action List access keys of Storage Account Credentials
/managers/accessControlRecords/read Lists or gets the Access Control Records
/managers/accessControlRecords/write Create or update the Access Control Records
/managers/accessControlRecords/delete Deletes the Access Control Records
/managers/metrics/read Lists or gets the Metrics

/managers/bandwidthSettings/read List the Bandwidth Settings (8000 Series Only)
/managers/bandwidthSettings/write Creates a new or updates Bandwidth Settings (8000 Series

Only)
/managers/bandwidthSettings/delete Deletes an existing Bandwidth Settings (8000 Series Only)
/Managers/extendedInformation/read The Get Extended Info operation gets an object's Extended

/Managers/extendedInformation/write The Get Extended Info operation gets an object's Extended

/Managers/extendedInformation/delete The Get Extended Info operation gets an object's Extended

/managers/alerts/read Lists or gets the Alerts
/managers/storageDomains/read Lists or gets the Storage Domains
/managers/storageDomains/write Create or update the Storage Domains
/managers/storageDomains/delete Deletes the Storage Domains
/managers/devices/scanForUpdates/action Scan for updates in a device.
/managers/devices/download/action Dowload updates for a device.
/managers/devices/install/action Install updates on a device.
/managers/devices/read Lists or gets the Devices
/managers/devices/write Create or update the Devices
/managers/devices/delete Deletes the Devices
/managers/devices/deactivate/action Deactivates a device.
/managers/devices/publishSupportPackage/action Publish support package of a device for Microsoft Support

troubleshooting.
/managers/devices/failover/action Failover of the device.
/managers/devices/sendTestAlertEmail/action Send test alert email to configured email recipients.
/managers/devices/installUpdates/action Installs updates on the devices
/managers/devices/listFailoverSets/action List the failover sets for an existing device.
/managers/devices/listFailoverTargets/action List failover targets of the devices

/managers/devices/publicEncryptionKey/action List public encryption key of the device manager
/managers/devices/hardwareComponentGroups/ List the Hardware Component Groups

read
/managers/devices/hardwareComponentGroups/ Change controller power state of hardware component groups

changeControllerPowerState/action
/managers/devices/metrics/read Lists or gets the Metrics
/managers/devices/chapSettings/write Create or update the Chap Settings
/managers/devices/chapSettings/read Lists or gets the Chap Settings
/managers/devices/chapSettings/delete Deletes the Chap Settings
/managers/devices/backupScheduleGroups/read Lists or gets the Backup Schedule Groups
/managers/devices/backupScheduleGroups/write Create or update the Backup Schedule Groups
/managers/devices/backupScheduleGroups/delete Deletes the Backup Schedule Groups
/managers/devices/updateSummary/read Lists or gets the Update Summary
/managers/devices/migrationSourceConfigurations/ Import source configurations for migration

import/action
/managers/devices/migrationSourceConfigurations/ Start a job to estimate the duration of the migration process.

startMigrationEstimate/action
/managers/devices/migrationSourceConfigurations/ Start migration using source configurations

startMigration/action
/managers/devices/migrationSourceConfigurations/ Confirms a successful migration and commit it.

confirmMigration/action
/managers/devices/migrationSourceConfigurations/ Fetch the status for the migration estimation job.

fetchMigrationEstimate/action
/managers/devices/migrationSourceConfigurations/ Fetch the status for the migration.

fetchMigrationStatus/action
/managers/devices/migrationSourceConfigurations/ Fetch the confirm status of migration.

fetchConfirmMigrationStatus/action
/managers/devices/alertSettings/read Lists or gets the Alert Settings
/managers/devices/alertSettings/write Create or update the Alert Settings
/managers/devices/networkSettings/read Lists or gets the Network Settings
/managers/devices/networkSettings/write Creates a new or updates Network Settings

/managers/devices/jobs/read Lists or gets the Jobs
/managers/devices/jobs/cancel/action Cancel a running job
/managers/devices/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/devices/volumeContainers/write Creates a new or updates Volume Containers (8000 Series

Only)
/managers/devices/volumeContainers/read List the Volume Containers (8000 Series Only)
/managers/devices/volumeContainers/delete Deletes an existing Volume Containers (8000 Series Only)
/managers/devices/volumeContainers/listEncryptionKeys/actio List encryption keys of Volume Containers

n
/managers/devices/volumeContainers/rolloverEncryptionKey/a Rollover encryption keys of Volume Containers

ction
/managers/devices/volumeContainers/metrics/read List the Metrics
/managers/devices/volumeContainers/volumes/read List the Volumes
/managers/devices/volumeContainers/volumes/write Creates a new or updates Volumes
/managers/devices/volumeContainers/volumes/delete Deletes an existing Volumes
/managers/devices/volumeContainers/volumes/metrics/read List the Metrics
/managers/devices/volumeContainers/volumes/metricsDefiniti List the Metrics Definitions

ons/read
/managers/devices/volumeContainers/metricsDefinitions/read List the Metrics Definitions
/managers/devices/iscsiservers/read Lists or gets the iSCSI Servers
/managers/devices/iscsiservers/write Create or update the iSCSI Servers
/managers/devices/iscsiservers/delete Deletes the iSCSI Servers
/managers/devices/iscsiservers/backup/action Take backup of an iSCSI server.
/managers/devices/iscsiservers/metrics/read Lists or gets the Metrics
/managers/devices/iscsiservers/disks/read Lists or gets the Disks
/managers/devices/iscsiservers/disks/write Create or update the Disks
/managers/devices/iscsiservers/disks/delete Deletes the Disks
/managers/devices/iscsiservers/disks/metrics/read Lists or gets the Metrics

/managers/devices/iscsiservers/disks/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/devices/iscsiservers/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/devices/backups/read Lists or gets the Backup Set
/managers/devices/backups/delete Deletes the Backup Set
/managers/devices/backups/restore/action Restore all the volumes from a backup set.
/managers/devices/backups/elements/clone/action Clone a share or volume using a backup element.
/managers/devices/backupPolicies/write Creates a new or updates Backup Polices (8000 Series Only)
/managers/devices/backupPolicies/read List the Backup Polices (8000 Series Only)
/managers/devices/backupPolicies/delete Deletes an existing Backup Polices (8000 Series Only)
/managers/devices/backupPolicies/backup/action Take a manual backup to create an on-demand backup of all

the volumes protected by the policy.
/managers/devices/backupPolicies/schedules/write Creates a new or updates Schedules
/managers/devices/backupPolicies/schedules/read List the Schedules
/managers/devices/backupPolicies/schedules/delete Deletes an existing Schedules
/managers/devices/securitySettings/update/action Update the security settings.
/managers/devices/securitySettings/read List the Security Settings
/managers/devices/securitySettings/ Synchronize the remote management certificate for a device.

syncRemoteManagementCertificate/action
/managers/devices/securitySettings/write Creates a new or updates Security Settings
/managers/devices/fileservers/read Lists or gets the File Servers
/managers/devices/fileservers/write Create or update the File Servers
/managers/devices/fileservers/delete Deletes the File Servers
/managers/devices/fileservers/backup/action Take backup of an File Server.
/managers/devices/fileservers/metrics/read Lists or gets the Metrics
/managers/devices/fileservers/shares/write Create or update the Shares
/managers/devices/fileservers/shares/read Lists or gets the Shares

/managers/devices/fileservers/shares/delete Deletes the Shares
/managers/devices/fileservers/shares/metrics/read Lists or gets the Metrics
/managers/devices/fileservers/shares/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/devices/fileservers/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/devices/timeSettings/read Lists or gets the Time Settings
/managers/devices/timeSettings/write Creates a new or updates Time Settings
/Managers/certificates/write The Update Resource Certificate operation updates the

resource/vault credential certificate.
/managers/cloudApplianceConfigurations/read List the Cloud Appliance Supported Configurations
/managers/metricsDefinitions/read Lists or gets the Metrics Definitions
/managers/encryptionSettings/read Lists or gets the Encryption Settings
Microsoft.StreamAnalytics
/streamingjobs/Start/action Start Stream Analytics Job
/streamingjobs/Stop/action Stop Stream Analytics Job
/streamingjobs/Read Read Stream Analytics Job
/streamingjobs/Write Write Stream Analytics Job
/streamingjobs/Delete Delete Stream Analytics Job
/streamingjobs/providers/Microsoft.Insights/metricDefinitions/ Gets the available metrics for streamingjobs

read
/streamingjobs/providers/Microsoft.Insights/diagnosticSettings Read diagnostic setting.

/read
/streamingjobs/providers/Microsoft.Insights/diagnosticSettings Write diagnostic setting.

/write
/streamingjobs/providers/Microsoft.Insights/logDefinitions/rea Gets the available logs for streamingjobs

d
/streamingjobs/transformations/Read Read Stream Analytics Job Transformation
/streamingjobs/transformations/Write Write Stream Analytics Job Transformation

/streamingjobs/transformations/Delete Delete Stream Analytics Job Transformation
/streamingjobs/inputs/Read Read Stream Analytics Job Input
/streamingjobs/inputs/Write Write Stream Analytics Job Input
/streamingjobs/inputs/Delete Delete Stream Analytics Job Input
/streamingjobs/outputs/Read Read Stream Analytics Job Output
/streamingjobs/outputs/Write Write Stream Analytics Job Output
/streamingjobs/outputs/Delete Delete Stream Analytics Job Output
Microsoft.Support
/register/action Registers to Support Resource Provider
/supportTickets/read Gets Support Ticket details (including status, severity, contact

details and communications) or gets the list of Support Tickets
across subscriptions.
/supportTickets/write Creates or Updates a Support Ticket. You can create a Support

Ticket for Technical, Billing, Quotas or Subscription
Management related issues. You can update severity, contact
details and communications for existing support tickets.
Microsoft.Web
/unregister/action Unregister Microsoft.Web resource provider for the

subscription.
/validate/action Validate .
/register/action Register Microsoft.Web resource provider for the subscription.
/hostingEnvironments/Read Get the properties of an App Service Environment
/hostingEnvironments/Write Create a new App Service Environment or update existing one
/hostingEnvironments/Delete Delete an App Service Environment
/hostingEnvironments/reboot/Action Reboot all machines in an App Service Environment
/hostingenvironments/resume/action Resume Hosting Environments.

/hostingenvironments/suspend/action Suspend Hosting Environments.
/hostingenvironments/metricdefinitions/read Get Hosting Environments Metric Definitions.
/hostingEnvironments/workerPools/Read Get the properties of a Worker Pool in an App Service

Environment
/hostingEnvironments/workerPools/Write Create a new Worker Pool in an App Service Environment or

update an existing one
/hostingenvironments/workerpools/metricdefinitions/read Get Hosting Environments Workerpools Metric Definitions.
/hostingenvironments/workerpools/metrics/read Get Hosting Environments Workerpools Metrics.
/hostingenvironments/workerpools/skus/read Get Hosting Environments Workerpools SKUs.
/hostingenvironments/workerpools/usages/read Get Hosting Environments Workerpools Usages.
/hostingenvironments/sites/read Get Hosting Environments Web Apps.
/hostingenvironments/serverfarms/read Get Hosting Environments App Service Plans.
/hostingenvironments/usages/read Get Hosting Environments Usages.
/hostingenvironments/capacities/read Get Hosting Environments Capacities.
/hostingenvironments/operations/read Get Hosting Environments Operations.
/hostingEnvironments/multiRolePools/Read Get the properties of a FrontEnd Pool in an App Service

Environment
/hostingEnvironments/multiRolePools/Write Create a new FrontEnd Pool in an App Service Environment or

update an existing one
/hostingenvironments/multirolepools/metricdefinitions/read Get Hosting Environments MultiRole Pools Metric Definitions.
/hostingenvironments/multirolepools/metrics/read Get Hosting Environments MultiRole Pools Metrics.
/hostingenvironments/multirolepools/skus/read Get Hosting Environments MultiRole Pools SKUs.
/hostingenvironments/multirolepools/usages/read Get Hosting Environments MultiRole Pools Usages.
/hostingenvironments/diagnostics/read Get Hosting Environments Diagnostics.
/publishingusers/read Get Publishing Users.
/publishingusers/write Update Publishing Users.
/checknameavailability/read Check if resource name is available.
/geoRegions/Read Get the list of Geo regions.

/sites/Read Get the properties of a Web App
/sites/Write Create a new Web App or update an existing one
/sites/Delete Delete an existing Web App
/sites/backup/Action Create a new web app backup
/sites/publishxml/Action Get publishing profile xml for a Web App
/sites/publish/Action Publish a Web App
/sites/restart/Action Restart a Web App
/sites/start/Action Start a Web App
/sites/stop/Action Stop a Web App
/sites/slotsswap/Action Swap Web App deployment slots
/sites/slotsdiffs/Action Get differences in configuration between web app and slots
/sites/applySlotConfig/Action Apply web app slot configuration from target slot to the
current web app
/sites/resetSlotConfig/Action Reset web app configuration
/sites/functions/action Functions Web Apps.
/sites/listsyncfunctiontriggerstatus/action List Sync Function Trigger Status Web Apps.
/sites/networktrace/action Network Trace Web Apps.
/sites/newpassword/action Newpassword Web Apps.
/sites/sync/action Sync Web Apps.
/sites/operationresults/read Get Web Apps Operation Results.
/sites/webjobs/read Get Web Apps WebJobs.
/sites/backup/read Get Web Apps Backup.
/sites/backup/write Update Web Apps Backup.
/sites/metricdefinitions/read Get Web Apps Metric Definitions.
/sites/metrics/read Get Web Apps Metrics.
/sites/continuouswebjobs/delete Delete Web Apps Continuous Web Jobs.

/sites/continuouswebjobs/read Get Web Apps Continuous Web Jobs.
/sites/continuouswebjobs/start/action Start Web Apps Continuous Web Jobs.
/sites/continuouswebjobs/stop/action Stop Web Apps Continuous Web Jobs.
/sites/domainownershipidentifiers/read Get Web Apps Domain Ownership Identifiers.
/sites/domainownershipidentifiers/write Update Web Apps Domain Ownership Identifiers.
/sites/premieraddons/delete Delete Web Apps Premier Addons.
/sites/premieraddons/read Get Web Apps Premier Addons.
/sites/premieraddons/write Update Web Apps Premier Addons.
/sites/triggeredwebjobs/delete Delete Web Apps Triggered WebJobs.
/sites/triggeredwebjobs/read Get Web Apps Triggered WebJobs.
/sites/triggeredwebjobs/run/action Run Web Apps Triggered WebJobs.
/sites/hostnamebindings/delete Delete Web Apps Hostname Bindings.
/sites/hostnamebindings/read Get Web Apps Hostname Bindings.
/sites/hostnamebindings/write Update Web Apps Hostname Bindings.
/sites/virtualnetworkconnections/delete Delete Web Apps Virtual Network Connections.
/sites/virtualnetworkconnections/read Get Web Apps Virtual Network Connections.
/sites/virtualnetworkconnections/write Update Web Apps Virtual Network Connections.
/sites/virtualnetworkconnections/gateways/read Get Web Apps Virtual Network Connections Gateways.
/sites/virtualnetworkconnections/gateways/write Update Web Apps Virtual Network Connections Gateways.
/sites/publishxml/read Get Web Apps Publishing XML.
/sites/hybridconnectionrelays/read Get Web Apps Hybrid Connection Relays.
/sites/perfcounters/read Get Web Apps Performance Counters.
/sites/usages/read Get Web Apps Usages.
/sites/slots/Write Create a new Web App Slot or update an existing one
/sites/slots/Delete Delete an existing Web App Slot

/sites/slots/backup/Action Create new Web App Slot backup.
/sites/slots/publishxml/Action Get publishing profile xml for Web App Slot
/sites/slots/publish/Action Publish a Web App Slot
/sites/slots/restart/Action Restart a Web App Slot
/sites/slots/start/Action Start a Web App Slot
/sites/slots/stop/Action Stop a Web App Slot
/sites/slots/slotsswap/Action Swap Web App deployment slots
/sites/slots/slotsdiffs/Action Get differences in configuration between web app and slots
/sites/slots/applySlotConfig/Action Apply web app slot configuration from target slot to the
current slot.
/sites/slots/resetSlotConfig/Action Reset web app slot configuration
/sites/slots/Read Get the properties of a Web App deployment slot
/sites/slots/newpassword/action Newpassword Web Apps Slots.
/sites/slots/sync/action Sync Web Apps Slots.
/sites/slots/operationresults/read Get Web Apps Slots Operation Results.
/sites/slots/webjobs/read Get Web Apps Slots WebJobs.
/sites/slots/backup/write Update Web Apps Slots Backup.
/sites/slots/metricdefinitions/read Get Web Apps Slots Metric Definitions.
/sites/slots/metrics/read Get Web Apps Slots Metrics.
/sites/slots/continuouswebjobs/delete Delete Web Apps Slots Continuous Web Jobs.
/sites/slots/continuouswebjobs/read Get Web Apps Slots Continuous Web Jobs.
/sites/slots/continuouswebjobs/start/action Start Web Apps Slots Continuous Web Jobs.
/sites/slots/continuouswebjobs/stop/action Stop Web Apps Slots Continuous Web Jobs.
/sites/slots/premieraddons/delete Delete Web Apps Slots Premier Addons.
/sites/slots/premieraddons/read Get Web Apps Slots Premier Addons.
/sites/slots/premieraddons/write Update Web Apps Slots Premier Addons.

/sites/slots/triggeredwebjobs/delete Delete Web Apps Slots Triggered WebJobs.
/sites/slots/triggeredwebjobs/read Get Web Apps Slots Triggered WebJobs.
/sites/slots/triggeredwebjobs/run/action Run Web Apps Slots Triggered WebJobs.
/sites/slots/hostnamebindings/delete Delete Web Apps Slots Hostname Bindings.
/sites/slots/hostnamebindings/read Get Web Apps Slots Hostname Bindings.
/sites/slots/hostnamebindings/write Update Web Apps Slots Hostname Bindings.
/sites/slots/phplogging/read Get Web Apps Slots Phplogging.
/sites/slots/virtualnetworkconnections/delete Delete Web Apps Slots Virtual Network Connections.
/sites/slots/virtualnetworkconnections/read Get Web Apps Slots Virtual Network Connections.
/sites/slots/virtualnetworkconnections/write Update Web Apps Slots Virtual Network Connections.
/sites/slots/virtualnetworkconnections/gateways/write Update Web Apps Slots Virtual Network Connections

Gateways.
/sites/slots/usages/read Get Web Apps Slots Usages.
/sites/slots/hybridconnection/delete Delete Web Apps Slots Hybrid Connection.
/sites/slots/hybridconnection/read Get Web Apps Slots Hybrid Connection.
/sites/slots/hybridconnection/write Update Web Apps Slots Hybrid Connection.
/sites/slots/config/Read Get Web App Slot's configuration settings
/sites/slots/config/list/Action List Web App Slot's security sensitive settings, such as

publishing credentials, app settings and connection strings
/sites/slots/config/Write Update Web App Slot's configuration settings
/sites/slots/config/delete Delete Web Apps Slots Config.
/sites/slots/instances/read Get Web Apps Slots Instances.
/sites/slots/instances/processes/read Get Web Apps Slots Instances Processes.
/sites/slots/instances/deployments/read Get Web Apps Slots Instances Deployments.
/sites/slots/sourcecontrols/Read Get Web App Slot's source control configuration settings
/sites/slots/sourcecontrols/Write Update Web App Slot's source control configuration settings

/sites/slots/sourcecontrols/Delete Delete Web App Slot's source control configuration settings
/sites/slots/restore/read Get Web Apps Slots Restore.
/sites/slots/analyzecustomhostname/read Get Web Apps Slots Analyze Custom Hostname.
/sites/slots/backups/Read Get the properties of a web app slots' backup
/sites/slots/backups/list/action List Web Apps Slots Backups.
/sites/slots/backups/restore/action Restore Web Apps Slots Backups.
/sites/slots/deployments/delete Delete Web Apps Slots Deployments.
/sites/slots/deployments/read Get Web Apps Slots Deployments.
/sites/slots/deployments/write Update Web Apps Slots Deployments.
/sites/slots/deployments/log/read Get Web Apps Slots Deployments Log.
/sites/hybridconnection/delete Delete Web Apps Hybrid Connection.
/sites/hybridconnection/read Get Web Apps Hybrid Connection.
/sites/hybridconnection/write Update Web Apps Hybrid Connection.
/sites/recommendationhistory/read Get Web Apps Recommendation History.
/sites/recommendations/Read Get the list of recommendations for web app.
/sites/recommendations/disable/action Disable Web Apps Recommendations.
/sites/config/Read Get Web App configuration settings
/sites/config/list/Action List Web App's security sensitive settings, such as publishing

credentials, app settings and connection strings
/sites/config/Write Update Web App's configuration settings
/sites/config/delete Delete Web Apps Config.
/sites/instances/read Get Web Apps Instances.
/sites/instances/processes/delete Delete Web Apps Instances Processes.
/sites/instances/processes/read Get Web Apps Instances Processes.
/sites/instances/deployments/read Get Web Apps Instances Deployments.
/sites/sourcecontrols/Read Get Web App's source control configuration settings

/sites/sourcecontrols/Write Update Web App's source control configuration settings
/sites/sourcecontrols/Delete Delete Web App's source control configuration settings
/sites/restore/read Get Web Apps Restore.
/sites/analyzecustomhostname/read Analyze Custom Hostname.
/sites/backups/Read Get the properties of a web app's backup
/sites/backups/list/action List Web Apps Backups.
/sites/backups/restore/action Restore Web Apps Backups.
/sites/snapshots/read Get Web Apps Snapshots.
/sites/functions/delete Delete Web Apps Functions.
/sites/functions/listsecrets/action List Secrets Web Apps Functions.
/sites/functions/read Get Web Apps Functions.
/sites/functions/write Update Web Apps Functions.
/sites/deployments/delete Delete Web Apps Deployments.
/sites/deployments/read Get Web Apps Deployments.
/sites/deployments/write Update Web Apps Deployments.
/sites/deployments/log/read Get Web Apps Deployments Log.
/sites/diagnostics/read Get Web Apps Diagnostics.
/sites/diagnostics/workerprocessrecycle/read Get Web Apps Diagnostics Worker Process Recycle.
/sites/diagnostics/workeravailability/read Get Web Apps Diagnostics Workeravailability.
/sites/diagnostics/runtimeavailability/read Get Web Apps Diagnostics Runtime Availability.
/sites/diagnostics/cpuanalysis/read Get Web Apps Diagnostics Cpuanalysis.
/sites/diagnostics/servicehealth/read Get Web Apps Diagnostics Service Health.
/sites/diagnostics/frebanalysis/read Get Web Apps Diagnostics FREB Analysis.
/availablestacks/read Get Available Stacks.
/isusernameavailable/read Check if Username is available.

/Microsoft.Web/apiManagementAccounts/ Get the list of Apis.

apis/Read
/Microsoft.Web/apiManagementAccounts/ Add a new Api or update existing one.

apis/Write
/Microsoft.Web/apiManagementAccounts/ Delete an existing Api.

apis/Delete
/Microsoft.Web/apiManagementAccounts/ Get the list of Connections.

apis/connections/Read
/Microsoft.Web/apiManagementAccounts/ Save a new Connection or update an existing one.

apis/connections/Write
/Microsoft.Web/apiManagementAccounts/ Delete an existing Connection.

apis/connections/Delete
/Microsoft.Web/apiManagementAccounts/ Read ConnectionAcls

apis/connections/connectionAcls/Read
/Microsoft.Web/apiManagementAccounts/ Add or update ConnectionAcl

apis/connections/connectionAcls/Write
/Microsoft.Web/apiManagementAccounts/ Delete ConnectionAcl

apis/connections/connectionAcls/Delete
/Microsoft.Web/apiManagementAccounts/ Read ConnectionAcls for Api

apis/connectionAcls/Read
/Microsoft.Web/apiManagementAccounts/ Read ConnectionAcls

apis/apiAcls/Read
/Microsoft.Web/apiManagementAccounts/ Create or update Api Acls

apis/apiAcls/Write
/Microsoft.Web/apiManagementAccounts/ Delete Api Acls

apis/apiAcls/Delete
/serverfarms/Read Get the properties on an App Service Plan
/serverfarms/Write Create a new App Service Plan or update an existing one
/serverfarms/Delete Delete an existing App Service Plan
/serverfarms/restartSites/Action Restart all Web Apps in an App Service Plan
/serverfarms/operationresults/read Get App Service Plans Operation Results.
/serverfarms/capabilities/read Get App Service Plans Capabilities.
/serverfarms/metricdefinitions/read Get App Service Plans Metric Definitions.

/serverfarms/metrics/read Get App Service Plans Metrics.
/serverfarms/hybridconnectionplanlimits/read Get App Service Plans Hybrid Connection Plan Limits.
/serverfarms/virtualnetworkconnections/read Get App Service Plans Virtual Network Connections.
/serverfarms/virtualnetworkconnections/routes/delete Delete App Service Plans Virtual Network Connections Routes.
/serverfarms/virtualnetworkconnections/routes/read Get App Service Plans Virtual Network Connections Routes.
/serverfarms/virtualnetworkconnections/routes/write Update App Service Plans Virtual Network Connections

Routes.
/serverfarms/virtualnetworkconnections/gateways/write Update App Service Plans Virtual Network Connections

Gateways.
/serverfarms/firstpartyapps/settings/delete Delete App Service Plans First Party Apps Settings.
/serverfarms/firstpartyapps/settings/read Get App Service Plans First Party Apps Settings.
/serverfarms/firstpartyapps/settings/write Update App Service Plans First Party Apps Settings.
/serverfarms/sites/read Get App Service Plans Web Apps.
/serverfarms/workers/reboot/action Reboot App Service Plans Workers.
/serverfarms/hybridconnectionrelays/read Get App Service Plans Hybrid Connection Relays.
/serverfarms/skus/read Get App Service Plans SKUs.
/serverfarms/usages/read Get App Service Plans Usages.
/serverfarms/hybridconnectionnamespaces/relays/sites/read Get App Service Plans Hybrid Connection Namespaces Relays

Web Apps.
/ishostnameavailable/read Check if Hostname is Available.
/connectionGateways/Read Get the list of Connection Gateways.
/connectionGateways/Write Creates or updates a Connection Gateway.
/connectionGateways/Delete Deletes a Connection Gateway.
/connectionGateways/Join/Action Joins a Connection Gateway.
/classicmobileservices/read Get Classic Mobile Services.
/skus/read Get SKUs.
/certificates/Read Get the list of certificates.

/certificates/Write Add a new certificate or update an existing one.
/certificates/Delete Delete an existing certificate.
/operations/read Get Operations.
/recommendations/Read Get the list of recommendations for subscriptions.
/ishostingenvironmentnameavailable/read Get if Hosting Environment Name is available.
/apiManagementAccounts/Read Get the list of ApiManagementAccounts.
/apiManagementAccounts/Write Add a new ApiManagementAccount or update an existing one
/apiManagementAccounts/Delete Delete an existing ApiManagementAccount
/apiManagementAccounts/connectionAcls/Read Get the list of Connection Acls.
/apiManagementAccounts/apiAcls/Read Read ConnectionAcls
/connections/Read Get the list of Connections.
/connections/Write Creates or updates a Connection.
/connections/Delete Deletes a Connection.
/connections/Join/Action Joins a Connection.
/connections/confirmconsentcode/action Confirm Connections Consent Code.
/connections/listconsentlinks/action List Consent Links for Connections.
/deploymentlocations/read Get Deployment Locations.
/sourcecontrols/read Get Source Controls.
/sourcecontrols/write Update Source Controls.
/managedhostingenvironments/read Get Managed Hosting Environments.
/managedhostingenvironments/sites/read Get Managed Hosting Environments Web Apps.
/managedhostingenvironments/serverfarms/read Get Managed Hosting Environments App Service Plans.
/locations/managedapis/read Get Locations Managed APIs.
/locations/apioperations/read Get Locations API Operations.
/locations/connectiongatewayinstallations/read Get Locations Connection Gateway Installations.

/listSitesAssignedToHostName/Read Get names of sites assigned to hostname.
Next steps
Learn how to create a custom role.
Review the built in RBAC roles.
Learn how to manage access assignments by user or by resource
Learn how to View activity logs to audit actions on resources
Manage access to Azure resources with Privileged
Identity Management (Preview)
To protect privileged accounts from malicious cyber-attacks, you can use Azure Active Directory Privileged Identity
Management (PIM) to lower the exposure time of privileges and increase your visibility into their use through
reports and alerts. PIM does this by limiting users to only taking on their privileges "just in time" (JIT), or by
assigning privileges for a shortened duration after which privileges are revoked automatically.
You can now use PIM with Azure Role-Based Access Control (RBAC) to manage, control, and monitor access to
Azure resources. PIM can manage the membership of built-in and custom roles to help you:
Enable on-demand, "just in time" access to Azure resources
Expire resource access automatically for assigned users and groups
Assign temporary access to Azure resources for quick tasks or on-call schedules
Get alerts when new users or groups are assigned resource access, and when they activate eligible assignments
For more information, see Overview of Role-Based Access Control in Azure PIM.
Manage access to Azure management with
conditional access
Conditional access in Azure Active Directory (Azure AD) controls access to cloud apps based on specific conditions
that you specify. To allow access, you create conditional access policies that allow or block access based on whether
or not the requirements in the policy are met.
Typically, you use conditional access to control access to your cloud apps. You can also set up policies to control
access to Azure management based on certain conditions (such as sign-in risk, location, or device) and to enforce
requirements like multi-factor authentication.
To create a policy for Azure management, you select Microsoft Azure Management under Cloud apps when
choosing the app to which to apply the policy.
The policy you create applies to all Azure management endpoints, including classic Azure portal, Azure portal,
Azure Resource Manager provider, classic Service Management APIs, and Azure PowerShell.
Cau t i on
Make sure you understand how conditional access works before setting up a policy to manage access to Azure
management. Make sure you don't create conditions that could block your own access to the portal.
For more information on how to set up and use conditional access, see Conditional access in Azure Active
Directory.
Managed Service Identity (MSI) for Azure
resources
Managed Service Identity (MSI) is a public preview feature of Azure Active Directory. Make sure you review the known
issues before you begin. If you would like to be considered for enrollment in the private preview, visit our sign-up page. For
more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.
A common challenge when building cloud applications is how to manage the credentials that need to be in
your code for authenticating to cloud services. Keeping these credentials secure is an important task. Ideally,
they never appear on developer workstations or get checked into source control. Azure Key Vault provides a
way to securely store credentials and other keys and secrets, but your code needs to authenticate to Key Vault
to retrieve them. Managed Service Identity (MSI) makes solving this problem simpler by giving Azure services
an automatically managed identity in Azure Active Directory (Azure AD). You can use this identity to
authenticate to any service that supports Azure AD authentication, including Key Vault, without having any
credentials in your code.
How does it work?

When you enable Managed Service Identity on an Azure service, Azure automatically creates an identity for
the service instance in the Azure AD tenant used by your Azure subscription. Under the covers, Azure
provisions the credentials for the identity onto the service instance. Your code can then make a local request
to get access tokens for services that support Azure AD authentication. Azure takes care of rolling the
credentials used by the service instance. If the service instance is deleted, Azure automatically cleans up the
credentials and the identity in Azure AD.
Here's an example of how Managed Service Identity works with Azure Virtual Machines.
1. Azure Resource Manager receives a message to enable MSI on a VM.
2. Azure Resource Manager creates a Service Principal in Azure AD to represent the identity of the VM. The
Service Principal is created in the Azure AD tenant that is trusted by this subscription.
3. Azure Resource Manager configures the Service Principal details in the MSI VM Extension of the VM. This
step includes configuring client ID and certificate used by the extension to get access tokens from Azure
AD.
4. Now that the Service Principal identity of the VM is known, it can be granted access to Azure resources. For
example, if your code needs to call Azure Resource Manager, then you would assign the VM’s Service
Principal the appropriate role using Role-Based Access Control (RBAC) in Azure AD. If your code needs to
call Key Vault, then you would grant your code access to the specific secret or key in Key Vault.
5. Your code running on the VM requests a token from a local endpoint that is hosted by the MSI VM
extension: http://localhost:50342/oauth2/token. The resource parameter specifies the service to which the
token is sent. For example, if you want your code to authenticate to Azure Resource Manager, you would
use resource=https://management.azure.com/.
6. The MSI VM Extension uses its configured client ID and certificate to request an access token from Azure
AD. Azure AD returns a JSON Web Token (JWT) access token.
7. Your code sends the access token on a call to a service that supports Azure AD authentication.
Each Azure service that supports Managed Service Identity has its own method for your code to obtain an
access token. Check out the tutorials for each service to find out the specific method to get a token.
Try Managed Service Identity

Try a Managed Service Identity tutorial to learn end-to-end scenarios for accessing different Azure resources:
FROM MSI-ENABLED RESOURCE LEARN HOW TO
Azure VM (Windows) Access Azure Data Lake Store with a Windows VM

FROM MSI-ENABLED RESOURCE LEARN HOW TO
Access Azure Resource Manager with a Windows VM

Access Azure SQL with a Windows VM Managed Service

Identity
Access Azure Storage via access key with a Windows VM

Access Azure Storage via SAS with a Windows VM

Access a non-Azure AD resource with a Windows VM

Managed Service Identity and Azure Key Vault
Azure VM (Linux) Access Azure Data Lake Store with a Linux VM Managed
Service Identity
Access Azure Resource Manager with a Linux VM Managed

Service Identity
Access Azure Storage via access key with a Linux VM

Access Azure Storage via SAS with a Linux VM Managed

Service Identity
Access a non-Azure AD resource with a Linux VM Managed

Service Identity and Azure Key Vault
Azure App Service Use Managed Service Identity with Azure App Service or
Azure Functions
Azure Function Use Managed Service Identity with Azure App Service or
Azure Functions
Which Azure services support Managed Service Identity?

Azure services that support Managed Service Identity can use MSI to authenticate to services that support
Azure AD authentication. We are in the process of integrating MSI and Azure AD authentication across Azure.
Check back often for updates.
Azure services that support Managed Service Identity
The following Azure services support Managed Service Identity.
SERVICE STATUS DATE CONFIGURE GET A TOKEN
Azure Virtual Preview September 2017 Azure portal REST

Machines PowerShell .NET
Azure CLI Bash/Curl
Azure Resource Go
Manager templates PowerShell
SERVICE STATUS DATE CONFIGURE GET A TOKEN
Azure App Service Preview September 2017 Azure portal .NET

Azure Resource REST
Manager template
Azure Functions Preview September 2017 Azure portal .NET

Azure Resource REST
Manager template
Azure Data Factory Preview November 2017 Azure portal

V2 PowerShell
REST
SDK
Azure services that support Azure AD authentication

The following services support Azure AD authentication, and have been tested with client services that use
Managed Service Identity.
SERVICE RESOURCE ID STATUS DATE ASSIGN ACCESS
Azure Resource https://management Available September 2017 Azure portal

Manager .azure.com/ PowerShell
Azure CLI
Azure Key Vault https://vault.azure.n Available September 2017

et/
Azure Data Lake https://datalake.azur Available September 2017

e.net/
Azure SQL https://database.win Available October 2017

dows.net/
Azure Event Hubs https://eventhubs.az Available December 2017

ure.net/
Azure Service Bus https://servicebus.az Available December 2017

ure.net/
How much does Managed Service Identity cost?

Managed Service Identity comes with Azure Active Directory Free, which is the default for Azure subscriptions.
There is no additional cost for Managed Service Identity.
Support and feedback

We would love to hear from you!
Ask how-to questions on Stack Overflow with the tag azure-msi.
Make feature requests or give feedback on the Azure AD feedback forum for developers.
Configure a VM Managed Service Identity (MSI)
using the Azure portal
Managed Service Identity (MSI) is a public preview feature of Azure Active Directory. Make sure you review the known issues
before you begin. If you would like to be considered for enrollment in the private preview, visit our sign-up page. For more
information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.
Managed Service Identity provides Azure services with an automatically managed identity in Azure Active
Directory. You can use this identity to authenticate to any service that supports Azure AD authentication, without
having credentials in your code.
In this article, you will learn how to enable and remove MSI for an Azure VM, using the Azure portal.
Prerequisites
If you're unfamiliar with MSI, check out the Managed Service Identity overview. If you don't already have an Azure
account, sign up for a free account before continuing.
Enable MSI during creation of an Azure VM

As of the time of this writing, enabling MSI during creation of a VM in the Azure portal is not supported. Instead,
please refer to one of the following VM creation Quickstart articles to first create a VM:
Create a Windows virtual machine with the Azure portal
Create a Linux virtual machine with the Azure portal
Then proceed to the next section for details on enabling MSI on the VM.
Enable MSI on an existing Azure VM

If you have a VM that was originally provisioned without an MSI:
1. Sign in to the Azure portal using an account associated with the Azure subscription that contains the VM.
Also make sure your account belongs to a role that gives you write permissions on the VM, such as “Virtual
Machine Contributor”.
2. Navigate to the desired Virtual Machine.
3. Click the "Configuration" page, enable MSI on the VM by selecting "Yes" under "Managed service identity",
then click Save. This operation can take 60 seconds or more to complete:
Remove MSI from an Azure VM
If you have a Virtual Machine that no longer needs an MSI:
1. Sign in to the Azure portal using an account associated with the Azure subscription that contains the VM.
Also make sure your account belongs to a role that gives you write permissions on the VM, such as “Virtual
Machine Contributor”.
2. Navigate to the desired Virtual Machine.
3. Click the "Configuration" page, remove MSI from the VM by selecting "No" under "Managed service
identity", then click Save. This operation can take 60 seconds or more to complete:
Related content
For an overview of MSI, see Managed Service Identity overview.
Next steps
Using the Azure portal, give an Azure VM's MSI access to another Azure resource.
Use the following comments section to provide feedback and help us refine and shape our content.
using PowerShell
In this article, you learn how to enable and remove MSI for an Azure VM, using PowerShell.
Prerequisites
Also, install the latest version of Azure PowerShell (version 4.3.1 or later) if you haven't already.

To create an MSI-enabled VM:
1. Refer to one of the following Azure VM Quickstarts, completing only the necessary sections ("Log in to
Azure", "Create resource group", "Create networking group", "Create the VM").
IMPORTANT
When you get to the "Create the VM" section, make a slight modification to the New-AzureRmVMConfig cmdlet
syntax. Be sure to add a -IdentityType "SystemAssigned" parameter to provision the VM with an MSI, for
example:
$vmConfig = New-AzureRmVMConfig -VMName myVM -IdentityType "SystemAssigned" ...
Create a Windows virtual machine using PowerShell

Create a Linux virtual machine using PowerShell
2. Add the MSI VM extension using the -Type parameter on the Set-AzureRmVMExtension cmdlet. You can
pass either "ManagedIdentityExtensionForWindows" or "ManagedIdentityExtensionForLinux", depending on
the type of VM, and name it using the -Name parameter. The -Settings parameter specifies the port used
by the OAuth token endpoint for token acquisition:
$settings = @{ "port" = 50342 }

Set-AzureRmVMExtension -ResourceGroupName myResourceGroup -Location WestUS -VMName myVM -Name
"ManagedIdentityExtensionForWindows" -Type "ManagedIdentityExtensionForWindows" -Publisher
"Microsoft.ManagedIdentity" -TypeHandlerVersion "1.0" -Settings $settings
If you need to enable MSI on an existing Virtual Machine:
1. Sign in to Azure using Login-AzureRmAccount . Use an account that is associated with the Azure subscription
that contains the VM. Also make sure your account belongs to a role that gives you write permissions on the
VM, such as “Virtual Machine Contributor”:
Login-AzureRmAccount
2. First retrieve the VM properties using the Get-AzureRmVM cmdlet. Then to enable MSI, use the -IdentityType
switch on the Update-AzureRmVM cmdlet:
$vm = Get-AzureRmVM -ResourceGroupName myResourceGroup -Name myVM

Update-AzureRmVM -ResourceGroupName myResourceGroup -VM $vm -IdentityType "SystemAssigned"
3. Add the MSI VM extension using the -Type parameter on the Set-AzureRmVMExtension cmdlet. You can
pass either "ManagedIdentityExtensionForWindows" or "ManagedIdentityExtensionForLinux", depending on
the type of VM, and name it using the -Name parameter. The -Settings parameter specifies the port used
by the OAuth token endpoint for token acquisition. Be sure to specify the correct -Location parameter,
matching the location of the existing VM:
$settings = @{ "port" = 50342 }

Set-AzureRmVMExtension -ResourceGroupName myResourceGroup -Location WestUS -VMName myVM -Name
"ManagedIdentityExtensionForWindows" -Type "ManagedIdentityExtensionForWindows" -Publisher
"Microsoft.ManagedIdentity" -TypeHandlerVersion "1.0" -Settings $settings

If you have a Virtual Machine that no longer needs an MSI, you can use the RemoveAzureRmVMExtension cmdlet to
remove MSI from the VM:
1. Sign in to Azure using Login-AzureRmAccount . Use an account that is associated with the Azure subscription
that contains the VM. Also make sure your account belongs to a role that gives you write permissions on the
VM, such as “Virtual Machine Contributor”:
2. Use the -Name switch with the Remove-AzureRmVMExtension cmdlet, specifying the same name you used
when you added the extension:
Remove-AzureRmVMExtension -ResourceGroupName myResourceGroup -Name "ManagedIdentityExtensionForWindows"

-VMName myVM
Related content
Managed Service Identity overview
For the full Azure VM creation Quickstarts, see:
Create a Windows virtual machine with PowerShell
Create a Linux virtual machine with PowerShell
using Azure CLI
In this article, you will learn how to enable and remove MSI for an Azure VM, using Azure CLI.
Prerequisites
To run the CLI script examples, you have three options:
Use Azure Cloud Shell from the Azure portal (see next section).
Use the embedded Azure Cloud Shell via the "Try It" button, located in the top right corner of each code block.
Install the latest version of CLI 2.0 (2.0.13 or later) if you prefer to use a local CLI console.
Launch Azure Cloud Shell

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common
Azure tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into
the Cloud Shell, and then press enter to run it. There are a few ways to launch the Cloud Shell:
Click Try It in the upper right corner of a code block.
Open Cloud Shell in your browser.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.

To create an MSI-enabled VM:
1. If you're using the Azure CLI in a local console, first sign in to Azure using az login. Use an account that is
associated with the Azure subscription under which you would like to deploy the VM:
az login
2. Create a resource group for containment and deployment of your VM and its related resources, using az
group create. You can skip this step if you already have resource group you would like to use instead:
az group create --name myResourceGroup --location westus
3. Create a VM using az vm create. The following example creates a VM named myVM with an MSI, as
requested by the --assign-identity parameter. The --admin-username and --admin-password parameters
specify the administrative user name and password account for virtual machine sign-in. Update these values
as appropriate for your environment:
az vm create --resource-group myResourceGroup --name myVM --image win2016datacenter --generate-ssh-keys

--assign-identity --admin-username azureuser --admin-password myPassword12

If you need to enable MSI on an existing Virtual Machine:
associated with the Azure subscription that contains the VM. Also make sure your account belongs to a role
that gives you write permissions on the VM, such as “Virtual Machine Contributor”:
az login
2. Use az vm assign-identity with the --assign-identity parameter to add an MSI to an existing VM:
az vm assign-identity -g myResourceGroup -n myVm

If you have a Virtual Machine that no longer needs an MSI:
associated with the Azure subscription that contains the VM. Also make sure your account belongs to a role
that gives you write permissions on the VM, such as “Virtual Machine Contributor”:
az login
2. Use the -n ManagedIdentityExtensionForWindows or -n ManagedIdentityExtensionForLinux switch (depending

on the type of VM) with az vm extension delete to remove the MSI:
az vm extension delete --resource-group myResourceGroup --vm-name myVm -n

ManagedIdentityExtensionForWindows
Related content
Managed Service Identity overview
For the full Azure VM creation Quickstarts, see:
Create a Windows virtual machine with CLI
Create a Linux virtual machine with CLI
Configure a VM Managed Service Identity by using a
template
Managed Service Identity (MSI) provides Azure services with an automatically managed identity in Azure Active
Directory (Azure AD). You can use this identity to authenticate to any service that supports Azure AD authentication,
without having credentials in your code.
In this article, you learn how to enable and remove MSI for an Azure VM, using an Azure Resource Manager
deployment template.
Prerequisites
Enable MSI during creation of an Azure VM, or on an existing VM

As with the Azure portal and scripting, Azure Resource Manager templates provide the ability to deploy new or
modified resources defined by an Azure resource group. Several options are available for template editing and
deployment, both local and portal-based, including:
Using a custom template from the Azure Marketplace, which allows you to create a template from scratch, or
base it on an existing common or QuickStart template.
Deriving from an existing resource group, by exporting a template from either the original deployment, or from
the current state of the deployment.
Using a local JSON editor (such as VS Code), and then uploading and deploying by using PowerShell or CLI.
Using the Visual Studio Azure Resource Group project to both create and deploy a template.
Regardless of the option you choose, template syntax is the same during initial deployment and redeployment.
Enabling MSI on a new or existing VM is done in the same manner. Also, by default, Azure Resource Manager does
an incremental update to deployments:
1. Whether you sign in to Azure locally or via the Azure portal, use an account that is associated with the Azure
subscription that contains the VM. Also ensure that your account belongs to a role that gives you write
permissions on the VM (for example, the role of “Virtual Machine Contributor”).
2. After loading the template into an editor, locate the Microsoft.Compute/virtualMachines resource of interest
within the resources section. Yours might look slightly different from the following screenshot, depending
on the editor you're using and whether you are editing a template for a new deployment or existing one.
NOTE
This example assumes variables such as vmName , storageAccountName , and nicName have been defined in the
template.
3. Add the "identity" property at the same level as the "type": "Microsoft.Compute/virtualMachines"
property. Use the following syntax:
"identity": {
"type": "systemAssigned"
},
4. Then add the VM MSI extension as a resources element. Use the following syntax:
NOTE
The following example assumes a Windows VM extension ( ManagedIdentityExtensionForWindows ) is being
deployed. You can also configure for Linux by using ManagedIdentityExtensionForLinux instead, for the "name"
and "type" elements.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2016-03-30",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"port": 50342
},
"protectedSettings": {}
}
}
5. When you're done, your template should look similar to the following:

If you have a VM that no longer needs an MSI:
1. Whether you sign in to Azure locally or via the Azure portal, use an account that is associated with the Azure
subscription that contains the VM. Also ensure that your account belongs to a role that gives you write
permissions on the VM (for example, the role of “Virtual Machine Contributor”).
2. Remove the two elements that were added in the previous section: the VM's "identity" property and the
"Microsoft.Compute/virtualMachines/extensions" resource.
Related content
For a broader perspective about MSI, read the Managed Service Identity overview.
using an Azure SDK
Managed Service Identity provides Azure services with an automatically managed identity in Azure Active Directory
(AD). You can use this identity to authenticate to any service that supports Azure AD authentication, without having
credentials in your code.
In this article, you learn how to enable and remove MSI for an Azure VM, using an Azure SDK.
Prerequisites
Azure SDKs with MSI support

Azure supports multiple programming platforms through a series of Azure SDKs. Several of them have been
updated to support MSI, and provide corresponding samples to demonstrate usage. This list is updated as
additional support is added:
SDK SAMPLE
.NET Manage resource from an MSI-enabled VM
Java Manage storage from an MSI-enabled VM
Node.js Create a VM with MSI enabled
Python Create a VM with MSI enabled
Ruby Create Azure VM with an MSI
Next steps
See related articles under "Configure MSI for an Azure VM", to learn how you can also use the Azure portal,
PowerShell, CLI, and resource templates.
Assign a Managed Service Identity access to a
resource by using the Azure portal
After you've configured an Azure resource with a Managed Service Identity (MSI), you can give the MSI access to
another resource, just like any security principal. This article shows you how to give an Azure virtual machine's MSI
access to an Azure storage account, by using the Azure portal.
Prerequisites
Use RBAC to assign the MSI access to another resource

After you've enabled MSI on an Azure resource, such as an Azure VM:
1. Sign in to the Azure portal using an account associated with the Azure subscription under which you have
configured the MSI.
2. Navigate to the desired resource on which you want to modify access control. In this example, we are giving
an Azure VM access to a storage account, so we navigate to the storage account.
3. Select the Access control (IAM) page of the resource, and select + Add. Then specify the Role, Assign
access to Virtual Machine, and specify the corresponding Subscription and Resource Group where the
resource resides. Under the search criteria area, you should see the resource. Select the resource, and select
Save.
4. You are returned to the main Access control (IAM) page, where you see a new entry for the resource's
MSI. In this example, the "SimpleWinVM" VM from the Demo Resource Group has Contributor access to
the storage account.
Troubleshooting
If the MSI for the resource does not show up in the list of available identities, verify that the MSI has been enabled
correctly. In our case, we can go back to the Azure VM, and check the following:
Look at the Configuration page and ensure that the value for MSI enabled is Yes.
Look at the Extensions page and ensure that the MSI extension deployed successfully.
If either is incorrect, you might need to redeploy the MSI on your resource again, or troubleshoot the deployment
failure.
Related content
To enable MSI on an Azure VM, see Configure an Azure VM Managed Service Identity (MSI) using the Azure
portal.
Assign a Managed Service Identity (MSI) access to a
resource using PowerShell
Once you've configured an Azure resource with an MSI, you can give the MSI access to another resource, just like
any security principal. This example shows you how to give an Azure virtual machine's MSI access to an Azure
storage account, using PowerShell.
Prerequisites
Also, install Azure PowerShell version 4.3.1 if you haven't already.

1. Sign in to Azure using the Login-AzureRmAccount cmdlet. Use an account that is associated with the Azure
subscription under which you have configured the MSI:
2. In this example, we are giving an Azure VM access to a storage account. First we use Get-AzureRMVM to get
the service principal for the VM named "myVM", which was created when we enabled MSI. Then, we use
New-AzureRmRoleAssignment to give the VM "Reader" access to a storage account called "myStorageAcct":
$spID = (Get-AzureRMVM -ResourceGroupName myRG -Name myVM).identity.principalid

New-AzureRmRoleAssignment -ObjectId $spID -RoleDefinitionName "Reader" -Scope
"/subscriptions/<mySubscriptionID>/resourceGroups/<myResourceGroup>/providers/Microsoft.Storage/storageA
ccounts/<myStorageAcct>"
Troubleshooting
correctly. In our case, we can go back to the Azure VM in the Azure portal and:
Look at the "Configuration" page and ensure MSI enabled = "Yes."
Look at the "Extensions" page and ensure the MSI extension deployed successfully.
If either is incorrect, you may need to redeploy the MSI on your resource again, or troubleshoot the deployment
failure.
Related content
To enable MSI on an Azure VM, see Configure an Azure VM Managed Service Identity (MSI) using PowerShell.
Assign a Managed Service Identity (MSI) access to a
resource using Azure CLI
Once you've configured an Azure resource with an MSI, you can give the MSI access to another resource, just like
any security principal. This example shows you how to give an Azure virtual machine's MSI access to an Azure
storage account, using Azure CLI.
Prerequisites
To run the CLI script examples, you have three options:
Use Azure Cloud Shell from the Azure portal (see next section).
Use the embedded Azure Cloud Shell via the "Try It" button, located in the top right corner of each code block.
Install the latest version of CLI 2.0 (2.0.13 or later) if you prefer to use a local CLI console.
Launch Azure Cloud Shell

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure
tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into the
Cloud Shell, and then press enter to run it. There are a few ways to launch the Cloud Shell:
Click Try It in the upper right corner of a code block.
Open Cloud Shell in your browser.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.

associated with the Azure subscription under which you would like to deploy the VM:
az login
2. In this example, we are giving an Azure VM access to a storage account. First we use az resource list to get
the service principal for the VM named "myVM", which was created when we enabled MSI on the VM:
spID=$(az resource list -n myVM --query [*].identity.principalId --out tsv)
3. Once we have the service principal ID, we use az role assignment create to give the VM "Reader" access to a
storage account called "myStorageAcct":
az role assignment create --assignee $spID --role 'Reader' --scope

/subscriptions/<mySubscriptionID>/resourceGroups/<myResourceGroup>/providers/Microsoft.Storage/storageAc
counts/myStorageAcct
Troubleshooting
correctly. In our case, we can go back to the Azure VM in the Azure portal and:
Look at the "Configuration" page and ensure MSI enabled = "Yes."
Look at the "Extensions" page and ensure the MSI extension deployed successfully.
failure.
Related content
To enable MSI on an Azure VM, see Configure an Azure VM Managed Service Identity (MSI) using Azure CLI.
How to use an Azure VM Managed Service Identity
(MSI) for token acquisition
Managed Service Identity (MSI) is a public preview feature of Azure Active Directory. Make sure you review the known issues before
you begin. If you would like to be considered for enrollment in the private preview, visit our sign-up page. For more information about
previews, see Supplemental Terms of Use for Microsoft Azure Previews.
This article provides various code and script examples for token acquisition, as well as guidance on important topics
such as handling token expiration and HTTP errors.
Prerequisites
If you plan to use the Azure PowerShell examples in this article, be sure to install the latest version of Azure PowerShell.
IMPORTANT
All sample code/script in this article assumes the client is running on an MSI-enabled Virtual Machine. Use the VM "Connect"
feature in the Azure portal, to remotely connect to your VM. For details on enabling MSI on a VM, see Configure a VM
Managed Service Identity (MSI) using the Azure portal, or one of the variant articles (using PowerShell, CLI, a template, or an
Azure SDK).
Overview
A client application can request an MSI app-only access token for accessing a given resource. The token is based on the
MSI service principal. As such, there is no need for the client to register itself to obtain an access token under its own
service principal. The token is suitable for use as a bearer token in service-to-service calls requiring client credentials.
Get a token using HTTP Protocol details for the MSI token endpoint
Get a token using C# Example of using the MSI REST endpoint from a C# client
Get a token using Go Example of using the MSI REST endpoint from a Go client
Get a token using Azure PowerShell Example of using the MSI REST endpoint from a PowerShell client
Get a token using CURL Example of using the MSI REST endpoint from a Bash/CURL
client
Handling token expiration Guidance for handling expired access tokens
Error handling Guidance for handling HTTP errors returned from the MSI token
endpoint
Resource IDs for Azure services Where to get resource IDs for supported Azure services
Get a token using HTTP

The fundamental interface for acquiring an access token is based on REST, making it accessible to any client application
running on the VM that can make HTTP REST calls. This is similar to the Azure AD programming model, except the
client uses a localhost endpoint on the virtual machine (vs an Azure AD endpoint).
Sample request:
GET http://localhost:50342/oauth2/token?resource=https%3A%2F%2Fmanagement.azure.com%2F HTTP/1.1

Metadata: true
ELEMENT DESCRIPTION
GET The HTTP verb, indicating you want to retrieve data from the
endpoint. In this case, an OAuth access token.
http://localhost:50342/oauth2/token The MSI endpoint, where 50342 is the default port and is
configurable.
resource A query string parameter, indicating the App ID URI of the

target resource. It also appears in the aud (audience) claim of
the issued token. This example requests a token to access Azure
Resource Manager, which has an App ID URI of
https://management.azure.com/.
Metadata An HTTP request header field, required by MSI as a mitigation

against Server Side Request Forgery (SSRF) attack. This value
must be set to "true", in all lower case.
Sample response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJ0eXAi...",
"refresh_token": "",
"expires_in": "3599",
"expires_on": "1506484173",
"not_before": "1506480273",
"resource": "https://management.azure.com/",
"token_type": "Bearer"
}
ELEMENT DESCRIPTION
access_token The requested access token. When calling a secured REST API,
the token is embedded in the Authorization request header
field as a "bearer" token, allowing the API to authenticate the
caller.
refresh_token Not used by MSI.

ELEMENT DESCRIPTION
expires_in The number of seconds the access token continues to be valid,

before expiring, from time of issuance. Time of issuance can be
found in the token's iat claim.
expires_on The timespan when the access token expires. The date is
represented as the number of seconds from "1970-01-
01T0:0:0Z UTC" (corresponds to the token's exp claim).
not_before The timespan when the access token takes effect, and can be
accepted. The date is represented as the number of seconds
from "1970-01-01T0:0:0Z UTC" (corresponds to the token's
nbf claim).
resource The resource the access token was requested for, which matches
the resource query string parameter of the request.
token_type The type of token, which is a "Bearer" access token, which means
the resource can give access to the bearer of this token.
Get a token using C#

using System;
using System.Collections.Generic;
using System.IO;
using System.Net;
using System.Web.Script.Serialization;
// Build request to acquire MSI token

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://localhost:50342/oauth2/token?
resource=https://management.azure.com/");
request.Headers["Metadata"] = "true";
request.Method = "GET";
try
{
// Call /token endpoint
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
// Pipe response Stream to a StreamReader, and extract access token

StreamReader streamResponse = new StreamReader(response.GetResponseStream());
string stringResponse = streamResponse.ReadToEnd();
JavaScriptSerializer j = new JavaScriptSerializer();
Dictionary<string, string> list = (Dictionary<string, string>) j.Deserialize(stringResponse,
typeof(Dictionary<string, string>));
string accessToken = list["access_token"];
}
catch (Exception e)
{
string errorText = String.Format("{0} \n\n{1}", e.Message, e.InnerException != null ? e.InnerException.Message
: "Acquire token failed");
}
Get a token using Go

package main
import (
"fmt"
"io/ioutil"
"net/http"
"net/http"
"net/url"
"encoding/json"
)
type responseJson struct {

AccessToken string `json:"access_token"`
RefreshToken string `json:"refresh_token"`
ExpiresIn string `json:"expires_in"`
ExpiresOn string `json:"expires_on"`
NotBefore string `json:"not_before"`
Resource string `json:"resource"`
TokenType string `json:"token_type"`
}
func main() {
// Create HTTP request for MSI token to access Azure Resource Manager
var msi_endpoint *url.URL
msi_endpoint, err := url.Parse("http://localhost:50342/oauth2/token")
if err != nil {
fmt.Println("Error creating URL: ", err)
return
}
msi_parameters := url.Values{}
msi_parameters.Add("resource", "https://management.azure.com/")
msi_endpoint.RawQuery = msi_parameters.Encode()
req, err := http.NewRequest("GET", msi_endpoint.String(), nil)
if err != nil {
fmt.Println("Error creating HTTP request: ", err)
return
}
req.Header.Add("Metadata", "true")
// Call MSI /token endpoint

client := &http.Client{}
resp, err := client.Do(req)
if err != nil{
fmt.Println("Error calling token endpoint: ", err)
return
}
// Pull out response body

responseBytes,err := ioutil.ReadAll(resp.Body)
defer resp.Body.Close()
if err != nil {
fmt.Println("Error reading response body : ", err)
return
}
// Unmarshall response body into struct

var r responseJson
err = json.Unmarshal(responseBytes, &r)
if err != nil {
fmt.Println("Error unmarshalling the response:", err)
return
}
// Print HTTP response and marshalled response body elements to console

fmt.Println("Response status:", resp.Status)
fmt.Println("access_token: ", r.AccessToken)
fmt.Println("refresh_token: ", r.RefreshToken)
fmt.Println("expires_in: ", r.ExpiresIn)
fmt.Println("expires_on: ", r.ExpiresOn)
fmt.Println("not_before: ", r.NotBefore)
fmt.Println("resource: ", r.Resource)
fmt.Println("token_type: ", r.TokenType)
}
Get a token using Azure PowerShell
The following example demonstrates how to use the MSI REST endpoint from a PowerShell client to:
1. Acquire an access token.
2. Use the access token to call an Azure Resource Manager REST API and get information about the VM. Be sure to
substitute your subscription ID, resource group name, and virtual machine name for <SUBSCRIPTION-ID> ,
<RESOURCE-GROUP> , and <VM-NAME> , respectively.
# Get an access token for the MSI

$response = Invoke-WebRequest -Uri http://localhost:50342/oauth2/token `
-Method GET -Body @{resource="https://management.azure.com/"} -Headers
@{Metadata="true"}
$content =$response.Content | ConvertFrom-Json
$access_token = $content.access_token
echo "The MSI access token is $access_token"
# Use the access token to get resource information for the VM

$vmInfoRest = (Invoke-WebRequest -Uri https://management.azure.com/subscriptions/<SUBSCRIPTION-
ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Compute/virtualMachines/<VM-NAME>?api-version=2017-12-01 -
Method GET -ContentType "application/json" -Headers @{ Authorization ="Bearer $access_token"}).content
echo "JSON returned from call to get VM info:"
echo $vmInfoRest
Get a token using CURL

response=$(curl http://localhost:50342/oauth2/token --data "resource=https://management.azure.com/" -H
Metadata:true -s)
access_token=$(echo $response | python -c 'import sys, json; print (json.load(sys.stdin)["access_token"])')
echo The MSI access token is $access_token
Handling token expiration

The local MSI subsystem caches tokens. Therefore, you can call it as often as you like, and an on-the-wire call to Azure
AD results only if:
a cache miss occurs due to no token in the cache
the token is expired
If you cache the token in your code, you should be prepared to handle scenarios where the resource indicates that the
token is expired.
Error handling
The MSI endpoint signals errors via the status code field of the HTTP response message header, as either 4xx or 5xx
errors:
STATUS CODE ERROR REASON HOW TO HANDLE
4xx Error in request. One or more of the request parameters Do not retry. Examine the error details for
was incorrect. more information. 4xx errors are design-
time errors.
5xx Transient error from service. The MSI sub-system or Azure Active It is safe to retry after waiting for at least
Directory returned a transient error. 1 second. If you retry too quickly or too
often, Azure AD may return a rate limit
error (429).
If an error occurs, the corresponding HTTP response body contains JSON with the error details:
ELEMENT DESCRIPTION
error Error identifier.
error_description Verbose description of error. Error descriptions can change at

any time. Do not write code that branches based on values
in the error description.
HTTP response reference

This section documents the possible error responses. A "200 OK" status is a successful response, and the access token
is contained in the response body JSON, in the access_token element.
STATUS CODE ERROR ERROR DESCRIPTION SOLUTION
400 Bad Request invalid_resource AADSTS50001: The (Linux only)

application named <URI>
was not found in the tenant
named <TENANT-ID>. This
can happen if the application
has not been installed by the
administrator of the tenant or
consented to by any user in
the tenant. You might have
sent your authentication
request to the wrong tenant.\
400 Bad Request bad_request_102 Required metadata header Either the Metadata request
not specified header field is missing from
your request, or is formatted
incorrectly. The value must be
specified as true , in all lower
case. See the "Sample
request" in the preceding
REST section for an example.
401 Unauthorized unknown_source Unknown Source <URI> Verify that your HTTP GET
request URI is formatted
correctly. The
scheme:host/resource-
path
portion must be specified as
http://localhost:50342/oauth2/token
. See the "Sample request" in
the preceding REST section for
an example.
invalid_request The request is missing a

required parameter, includes
an invalid parameter value,
includes a parameter more
than once, or is otherwise
malformed.
STATUS CODE ERROR ERROR DESCRIPTION SOLUTION
unauthorized_client The client is not authorized to Caused by a request that

request an access token using didn’t use local loopback to
this method. call the extension, or on a VM
that doesn’t have an MSI
configured correctly. See
Configure a VM Managed
Service Identity (MSI) using
the Azure portal if you need
assistance with VM
configuration.
access_denied The resource owner or

authorization server denied
the request.
unsupported_response_type The authorization server does

not support obtaining an
access token using this
method.
invalid_scope The requested scope is

invalid, unknown, or
malformed.
500 Internal server error unknown Failed to retrieve token from Verify that MSI has been
the Active directory. For enabled on the VM. See
details see logs in <file path> Configure a VM Managed
Service Identity (MSI) using
the Azure portal if you need
assistance with VM
configuration.
Also verify that your HTTP

GET request URI is formatted
correctly, particularly the
resource URI specified in the
query string. See the "Sample
request" in the preceding
REST section for an example,
or Azure services that support
Azure AD authentication for a
list of services and their
respective resource IDs.
Resource IDs for Azure services

See Azure services that support Azure AD authentication for a list of resources that support Azure AD and have been
tested with MSI, and their respective resource IDs.
Related content
To enable MSI on an Azure VM, see Configure a VM Managed Service Identity (MSI) using the Azure portal.
(MSI) for sign in
This article provides PowerShell and CLI script examples for sign-in using an MSI service principal, and guidance on
important topics such as error handling.
Prerequisites
If you plan to use the Azure PowerShell or Azure CLI examples in this article, be sure to install the latest version of
Azure PowerShell or Azure CLI 2.0.
IMPORTANT
All sample script in this article assumes the command-line client is running on an MSI-enabled Virtual Machine. Use the
VM "Connect" feature in the Azure portal, to remotely connect to your VM. For details on enabling MSI on a VM, see
Configure a VM Managed Service Identity (MSI) using the Azure portal, or one of the variant articles (using PowerShell,
CLI, a template, or an Azure SDK).
To prevent errors during resource access, the VM's MSI must be given at least "Reader" access at the appropriate scope
(the VM or higher) to allow Azure Resource Manager operations on the VM. See Assign a Managed Service Identity (MSI)
access to a resource using the Azure portal for details.
Overview
An MSI provides a service principal, which is created upon enabling MSI on the VM. The service principal can be
given access to Azure resources, and used as an identity by script/command-line clients for sign in and resource
access. Traditionally, in order to access secured resources under its own identity, a script client would need to:
be registered and consented with Azure AD as a confidential/web client application
sign in under its service principal, using the app's credentials (which are likely embedded in the script)
With MSI, your script client no longer needs to do either, as it can sign in under the MSI service principal.
Azure CLI
The following script demonstrates how to:
1. Sign in to Azure AD under the VM's MSI service principal
2. Call Azure Resource Manager and get the VM's service principal ID. CLI takes care of managing token
acquisition/use for you automatically. Be sure to substitute your virtual machine name for <VM-NAME> .
az login --msi
spID=$(az resource list -n <VM-NAME> --query [*].identity.principalId --out tsv)

echo The MSI service principal ID is $spID
Azure PowerShell
The following script demonstrates how to:
1. Acquire an MSI access token for the VM.
2. Use the access token to sign in to Azure AD, under the corresponding MSI service principal.
3. Call an Azure Resource Manager cmdlet to get information about the VM. PowerShell takes care of
managing token use for you automatically.
# Get an access token for the MSI

$response = Invoke-WebRequest -Uri http://localhost:50342/oauth2/token `
-Method GET -Body @{resource="https://management.azure.com/"} -Headers
@{Metadata="true"}
$content =$response.Content | ConvertFrom-Json
$access_token = $content.access_token
echo "The MSI access token is $access_token"
# Use the access token to sign in under the MSI service principal. -AccountID can be any string to
identify the session.
Login-AzureRmAccount -AccessToken $access_token -AccountId "MSI@50342"
# Call Azure Resource Manager to get the service principal ID for the VM's MSI.
$vmInfoPs = Get-AzureRMVM -ResourceGroupName <RESOURCE-GROUP> -Name <VM-NAME>
$spID = $vmInfoPs.Identity.PrincipalId
echo "The MSI service principal ID is $spID"
Resource IDs for Azure services

See Azure services that support Azure AD authentication for a list of resources that support Azure AD and have
been tested with MSI, and their respective resource IDs.
Error handling guidance

Responses such as the following may indicate that the VM's MSI has not been correctly configured:
PowerShell: Invoke-WebRequest : Unable to connect to the remote server
CLI: MSI: Failed to retrieve a token from 'http://localhost:50342/oauth2/token' with an error of
'HTTPConnectionPool(host='localhost', port=50342)
If you receive one of these errors, return to the Azure VM in the Azure portal and:
Go to the Configuration page and ensure "Managed service identity" is set to "Yes."
Go to the Extensions page and ensure the MSI extension deployed successfully.
failure. See Configure a VM Managed Service Identity (MSI) using the Azure portal if you need assistance with VM
configuration.
Related content
To enable MSI on an Azure VM, see Configure a VM Managed Service Identity (MSI) using PowerShell, or
Configure a VM Managed Service Identity (MSI) using Azure CLI
(MSI) with Azure SDKs
This article provides a list of SDK samples, which demonstrate use of their respective Azure SDK's support for MSI.
Prerequisites
IMPORTANT
All sample code/script in this article assumes the client is running on an MSI-enabled Virtual Machine. Use the VM
"Connect" feature in the Azure portal, to remotely connect to your VM. For details on enabling MSI on a VM, see
Configure a VM Managed Service Identity (MSI) using the Azure portal, or one of the variant articles (using PowerShell,
CLI, a template, or an Azure SDK).
SDK code samples

SDK CODE SAMPLE
.NET Deploy an Azure Resource Manager template from a Windows

VM using Managed Service Identity
.NET Core Call Azure services from a Linux VM using Managed Service
Identity
Node.js Manage resources using Managed Service Identity
Python Use MSI to authenticate simply from inside a VM
Ruby Manage resources from an MSI-enabled VM
Related content
See Azure SDKs for the full list of Azure SDK resources, including library downloads, documentation, and more.
To enable MSI on an Azure VM, see Configure a VM Managed Service Identity (MSI) using the Azure portal.
Use a Windows VM Managed Service Identity (MSI)
to access Azure Data Lake Store
This tutorial shows you how to use a Managed Service Identity (MSI) for a Windows virtual machine (VM) to access
an Azure Data Lake Store. Managed Service Identities are automatically managed by Azure and enable you to
authenticate to services that support Azure AD authentication, without needing to insert credentials into your code.
You learn how to:
Enable MSI on a Windows VM
Grant your VM access to an Azure Data Lake Store
Get an access token using the VM identity and use it to access an Azure Data Lake Store
Prerequisites
Your account needs to be given "Owner" permissions at the appropriate scope (your Subscription or Resource
Group), to perform the required resource creation and role management. See Use Role-Based Access Control to
manage access to your Azure subscription resources if you need assistance with role assignment.
Sign in to Azure
Sign in to the Azure portal at https://portal.azure.com.
Create a Windows virtual machine in a new resource group

For this tutorial, we create a new Windows VM. You can also enable MSI on an existing VM.
1. Click the New button found on the upper left-hand corner of the Azure portal.
2. Select Compute, and then select Windows Server 2016 Datacenter.
3. Enter the virtual machine information. The Username and Password created here is the credentials you use to
login to the virtual machine.
4. Choose the proper Subscription for the virtual machine in the dropdown.
5. To select a new Resource Group in which to create your virtual machine, choose Create New. When complete,
click OK.
6. Select the size for the VM. To see more sizes, select View all or change the Supported disk type filter. On
the Settings page, keep the defaults, and click OK.
Enable MSI on your VM
A VM MSI enables you to get access tokens from Azure AD without you needing to put credentials into your code.
Enabling MSI tells Azure to create a managed identity for your VM. Under the covers, enabling MSI does two things:
it installs the MSI VM extension on your VM, and it enables MSI in Azure Resource Manager.
1. Select the Virtual Machine that you want to enable MSI on. 
2. On the left navigation bar click Configuration.
3. You see Managed Service Identity. To register and enable the MSI, select Yes, if you wish to disable it, choose
No.
4. Ensure you click Save to save the configuration.
5. If you wish to check and verify which extensions are on this VM, click Extensions. If MSI is enabled, then
ManagedIdentityExtensionforWindows appears in the list.
Grant your VM access to Azure Data Lake Store

Now you can grant your VM access to files and folders in an Azure Data Lake Store. For this step, you can use an
existing Data Lake Store or create a new one. To create a new Data Lake Store using the Azure portal, follow this
Azure Data Lake Store quickstart. There are also quickstarts that use the Azure CLI and Azure PowerShell in the
Azure Data Lake Store documentation.
In your Data Lake Store, create a new folder and grant your VM MSI permission to read, write, and execute files in
that folder:
1. In the Azure portal, click Data Lake Store in the left-hand navigation.
2. Click the Data Lake Store you want to use for this tutorial.
3. Click Data Explorer in the command bar.
4. The root folder of the Data Lake Store is selected. Click Access in the command bar.
5. Click Add. In the Select field, enter the name of your VM, for example DevTestVM. Click to select your VM from
the search results, then click Select.
6. Click Select Permissions. Select Read and Execute, add to This folder, and add as An access permission
only. Click Ok. The permission should be added successfully.
7. Close the Access blade.
8. For this tutorial, create a new folder. Click New Folder in the command bar, and give the new folder a name, for
example TestFolder. Click Ok.
9. Click on the folder you created, then click Access in the command bar.
10. Similar to step 5, click Add, in the Select field enter the name of your VM, select it and click Select.
11. Similar to step 6, click Select Permissions, select Read, Write, and Execute, add to This folder, and add as An
access permission entry and a default permission entry. Click Ok. The permission should be added
successfully.
Your VM MSI can now perform all operations on files in the folder you created. For more information on managing
access to Data Lake Store, read this article on Access Control in Data Lake Store.
Get an access token using the VM MSI and use it to call the Azure Data
Lake Store filesystem
Azure Data Lake Store natively supports Azure AD authentication, so it can directly accept access tokens obtained
using MSI. To authenticate to the Data Lake Store filesystem you send an access token issued by Azure AD to your
Data Lake Store filesystem endpoint, in an Authorization header in the format "Bearer <ACCESS_TOKEN_VALUE>".
To learn more about Data Lake Store support for Azure AD authentication, read Authentication with Data Lake
Store using Azure Active Directory
NOTE
The Data Lake Store filesystem client SDKs do not yet support Managed Service Identity. This tutorial will be updated when
support is added to the SDK.
In this tutorial, you authenticate to the Data Lake Store filesystem REST API using PowerShell to make REST
requests. To use the VM MSI for authentication, you need to make the requests from the VM.
1. In the portal, navigate to Virtual Machines, go to your Windows VM, and in the Overview click Connect.
2. Enter in your Username and Password for which you added when you created the Windows VM.
3. Now that you have created a Remote Desktop Connection with the virtual machine, open PowerShell in the
remote session.
4. Using PowerShell’s Invoke-WebRequest , make a request to the local MSI endpoint to get an access token for
Azure Data Lake Store. The resource identifier for Data Lake Store is "https://datalake.azure.net/". Data Lake
does an exact match on the resource identifier and the trailing slash is important.
$response = Invoke-WebRequest -Uri http://localhost:50342/oauth2/token -Method GET -Body

@{resource="https://datalake.azure.net/"} -Headers @{Metadata="true"}
Convert the response from a JSON object to a PowerShell object.
$content = $response.Content | ConvertFrom-Json
Extract the access token from the response.
$AccessToken = $content.access_token
5. Using PowerShell's `Invoke-WebRequest', make a request to your Data Lake Store's REST endpoint to list the
folders in the root folder. This is a simple way to check everything is configured correctly. It is important the
string "Bearer" in the Authorization header has a capital "B". You can find the name of your Data Lake Store
in the Overview section of the Data Lake Store blade in the Azure portal.
Invoke-WebRequest -Uri https://<YOUR_ADLS_NAME>.azuredatalakestore.net/webhdfs/v1/?op=LISTSTATUS -

Headers @{Authorization="Bearer $AccessToken"}
A successful response looks like:

StatusCode : 200
StatusDescription : OK
Content : {"FileStatuses":{"FileStatus":
[{"length":0,"pathSuffix":"TestFolder","type":"DIRECTORY", "blockSize":0,"accessTime":1507934941392,
"modificationTime":1507944835699,"replication":0, "permission":"770","ow..."
RawContent : HTTP/1.1 200 OK
Pragma: no-cache
x-ms-request-id: b4b31e16-e968-46a1-879a-3474aa7d4528
x-ms-webhdfs-version: 17.04.22.00
Status: 0x0
X-Content-Type-Options: nosniff
Strict-Transport-Security: ma...
Forms : {}
Headers : {[Pragma, no-cache], [x-ms-request-id, b4b31e16-e968-46a1-879a-3474aa7d4528],
[x-ms-webhdfs-version, 17.04.22.00], [Status, 0x0]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 556
6. Now you can try uploading a file to your Data Lake Store. First, create a file to upload.
echo "Test file." > Test1.txt
7. Using PowerShell's Invoke-WebRequest , make a request to your Data Lake Store's REST endpoint to upload
the file to the folder you created earlier. This request takes two steps. In the first step, you make a request
and get a redirection to where the file should be uploaded. In the second step, you actually upload the file.
Remember to set the name of the folder and file appropriately if you used different values than in this
tutorial.
$HdfsRedirectResponse = Invoke-WebRequest -Uri

https://<YOUR_ADLS_NAME>.azuredatalakestore.net/webhdfs/v1/TestFolder/Test1.txt?op=CREATE -Method PUT -
Headers @{Authorization="Bearer $AccessToken"} -Infile Test1.txt -MaximumRedirection 0
If you inspect the value of $HdfsRedirectResponse it should look like the following response:
PS C:\> $HdfsRedirectResponse
StatusCode :
307
StatusDescription :
Temporary Redirect
Content :
{}
RawContent :
HTTP/1.1 307 Temporary Redirect
Pragma: no-cache
x-ms-request-id: b7ab492f-b514-4483-aada-4aa0611d12b3
ContentLength: 0
Status: 0x0
X-Content-Type-Options: nosn...
Headers : {[Pragma, no-cache], [x-ms-request-id, b7ab492f-b514-4483-aada-4aa0611d12b3],
[ContentLength, 0], [x-ms-webhdfs-version, 17.04.22.00]...}
Complete the upload by sending a request to the redirect endpoint:
Invoke-WebRequest -Uri $HdfsRedirectResponse.Headers.Location -Method PUT -Headers

@{Authorization="Bearer $AccessToken"} -Infile Test1.txt -MaximumRedirection 0
A successful response look like:
StatusCode :
201
StatusDescription :
Created
Content :
{}
RawContent :
HTTP/1.1 201 Created
Pragma: no-cache
x-ms-request-id: 1e70f36f-ead1-4566-acfa-d0c3ec1e2307
ContentLength: 0
Status: 0x0
Strict...
Headers : {[Pragma, no-cache], [x-ms-request-id, 1e70f36f-ead1-4566-acfa-d0c3ec1e2307],
[ContentLength, 0], [x-ms-webhdfs-version, 17.04.22.00]...}
Using other Data Lake Store filesystem APIs you can append to files, download files, and more.
Congratulations! You've authenticated to the Data Lake Store filesystem using a VM MSI.
Related content
For management operations Data Lake Store uses Azure Resource Manager. For more information on using a
VM MSI to authenticate to Resource Manager, read Use a Linux VM Managed Service Identity (MSI) to access
Resource Manager.
Learn more about Authentication with Data Lake Store using Azure Active Directory.
Learn more about Filesystem operations on Azure Data Lake Store using REST API or the WebHDFS FileSystem
APIs.
Learn more about Access Control in Data Lake Store.
Use a Linux VM Managed Service Identity (MSI) to
access Azure Data Lake Store
This tutorial shows you how to use a Managed Service Identity (MSI) for a Linux virtual machine (VM) to access an
Azure Data Lake Store. Managed Service Identities are automatically managed by Azure and enable you to
You learn how to:
Enable MSI on a Linux VM
Grant your VM access to an Azure Data Lake Store
Get an access token using the VM identity and use it to access an Azure Data Lake Store
Prerequisites
Sign in to Azure
Create a Linux Virtual Machine in a new Resource Group

For this tutorial, we create a new Linux VM. You can also enable MSI on an existing VM.
2. Select Compute, and then select Ubuntu Server 16.04 LTS.
3. Enter the virtual machine information. For Authentication type, select SSH public key or Password. The
created credentials allow you to log in to the VM.
4. Choose a Subscription for the virtual machine in the dropdown.
5. To select a new Resource Group you would like the virtual machine to be created in, choose Create New.
When complete, click OK.
6. Select the size for the VM. To see more sizes, select View all or change the Supported disk type filter. On the
settings blade, keep the defaults and click OK.

A Virtual Machine MSI enables you to get access tokens from Azure AD without you needing to put credentials into
your code. Under the covers, enabling MSI does two things: it installs the MSI VM extension on your VM and it
enables MSI in Azure Resource Manager.
1. Select the Virtual Machine that you want to enable MSI on.
No.
5. If you wish to check which extensions are on this Linux VM, click Extensions. If MSI is enabled, the
ManagedIdentityExtensionforLinux appears on the list.
Grant your VM access to Azure Data Lake Store

Now you can grant your VM access to files and folders in an Azure Data Lake Store. For this step, you can use an
existing Data Lake Store or create a new one. To create a new Data Lake Store using the Azure portal, follow this
Azure Data Lake Store quickstart. There are also quickstarts that use the Azure CLI and Azure PowerShell in the
Azure Data Lake Store documentation.
In your Data Lake Store, create a new folder and grant your VM MSI permission to read, write, and execute files in
that folder:
1. In the Azure portal, click Data Lake Store in the left-hand navigation.
2. Click the Data Lake Store you want to use for this tutorial.
3. Click Data Explorer in the command bar.
4. The root folder of the Data Lake Store is selected. Click Access in the command bar.
5. Click Add. In the Select field, enter the name of your VM, for example DevTestVM. Click to select your VM from
the search results, then click Select.
6. Click Select Permissions. Select Read and Execute, add to This folder, and add as An access permission
only. Click Ok. The permission should be added successfully.
7. Close the Access blade.
8. For this tutorial, create a new folder. Click New Folder in the command bar, and give the new folder a name, for
example TestFolder. Click Ok.
9. Click on the folder you created, then click Access in the command bar.
10. Similar to step 5, click Add, in the Select field enter the name of your VM, select it and click Select.
11. Similar to step 6, click Select Permissions, select Read, Write, and Execute, add to This folder, and add as An
access permission entry and a default permission entry. Click Ok. The permission should be added
successfully.
Your VM MSI can now perform all operations on files in the folder you created. For more information on managing
access to Data Lake Store, read this article on Access Control in Data Lake Store.
Get an access token using the VM MSI and use it to call the Azure Data
Lake Store filesystem
Azure Data Lake Store natively supports Azure AD authentication, so it can directly accept access tokens obtained
using MSI. To authenticate to the Data Lake Store filesystem you send an access token issued by Azure AD to your
Data Lake Store filesystem endpoint, in an Authorization header in the format "Bearer <ACCESS_TOKEN_VALUE>".
To learn more about Data Lake Store support for Azure AD authentication, read Authentication with Data Lake
Store using Azure Active Directory
In this tutorial, you authenticate to the Data Lake Store filesystem REST API using CURL to make REST requests.
NOTE
The Data Lake Store filesystem client SDKs do not yet support Managed Service Identity. This tutorial will be updated when
support is added to the SDK.
To complete these steps, you need an SSH client. If you are using Windows, you can use the SSH client in the
Windows Subsystem for Linux. If you need assistance configuring your SSH client's keys, see How to Use SSH keys
with Windows on Azure, or How to create and use an SSH public and private key pair for Linux VMs in Azure.
1. In the portal, navigate to your Linux VM and in the Overview, click Connect.
2. Connect to the VM with the SSH client of your choice.
3. In the terminal window, using CURL, make a request to the local MSI endpoint to get an access token for the
Data Lake Store filesystem. The resource identifier for Data Lake Store is "https://datalake.azure.net/." It is
important to include the trailing slash in the resource identifier.
curl http://localhost:50342/oauth2/token --data "resource=https://datalake.azure.net/" -H Metadata:true
A successful response returns the access token you use to authenticate to Data Lake Store:
{"access_token":"eyJ0eXAiOiJ...",
"refresh_token":"",
"expires_in":"3599",
"expires_on":"1508119757",
"not_before":"1508115857",
"resource":"https://datalake.azure.net/",
"token_type":"Bearer"}
4. Using CURL, make a request to your Data Lake Store filesystem REST endpoint to list the folders in the root
folder. This is a simple way to check everything is configured correctly. Copy the value of the access token
from the previous step. It is important the string "Bearer" in the Authorization header has a capital "B". You
can find the name of your Data Lake Store in the Overview section of the Data Lake Store blade in the Azure
portal.
curl https://<YOUR_ADLS_NAME>.azuredatalakestore.net/webhdfs/v1/?op=LISTSTATUS -H "Authorization: Bearer

<ACCESS_TOKEN>"
{"FileStatuses":{"FileStatus":
[{"length":0,"pathSuffix":"TestFolder","type":"DIRECTORY","blockSize":0,"accessTime":1507934941392,"modi
ficationTime":1508105430590,"replication":0,"permission":"770","owner":"bd0e76d8-ad45-4fe1-8941-
04a7bf27f071","group":"bd0e76d8-ad45-4fe1-8941-04a7bf27f071"}]}}
5. Now you can try uploading a file to your Data Lake Store. First, create a file to upload.
echo "Test file." > Test1.txt
6. Using CURL, make a request to your Data Lake Store filesystem REST endpoint to upload the file to the
folder you created earlier. The upload involves a redirect, and CURL follows the redirect automatically.
curl -i -X PUT -L -T Test1.txt -H "Authorization: Bearer <ACCESS_TOKEN>"

'https://<YOUR_ADLS_NAME>.azuredatalakestore.net/webhdfs/v1/<FOLDER_NAME>/Test1.txt?op=CREATE'

HTTP/1.1 100 Continue
HTTP/1.1 307 Temporary Redirect
Cache-Control: no-cache, no-cache, no-store, max-age=0
Pragma: no-cache
Expires: -1
Location: https://mytestadls.azuredatalakestore.net/webhdfs/v1/TestFolder/Test1.txt?op=CREATE&write=true
x-ms-request-id: 756f6b24-0cca-47ef-aa12-52c3b45b954c
ContentLength: 0
Status: 0x0
Strict-Transport-Security: max-age=15724800; includeSubDomains
Date: Sun, 15 Oct 2017 22:10:30 GMT
Content-Length: 0
HTTP/1.1 100 Continue
HTTP/1.1 201 Created

Cache-Control: no-cache, no-cache, no-store, max-age=0
Pragma: no-cache
Expires: -1
Location: https://mytestadls.azuredatalakestore.net/webhdfs/v1/TestFolder/Test1.txt?op=CREATE&write=true
x-ms-request-id: af5baa07-3c79-43af-a01a-71d63d53e6c4
ContentLength: 0
Status: 0x0
Strict-Transport-Security: max-age=15724800; includeSubDomains
Date: Sun, 15 Oct 2017 22:10:30 GMT
Content-Length: 0
Using other Data Lake Store filesystem APIs you can append to files, download files, and more.
Congratulations! You've authenticated to the Data Lake Store filesystem using a VM MSI.
Related content
For management operations Data Lake Store uses Azure Resource Manager. For more information on using a
VM MSI to authenticate to Resource Manager, read Use a Linux VM Managed Service Identity (MSI) to access
Resource Manager.
Learn more about Authentication with Data Lake Store using Azure Active Directory.
Learn more about Filesystem operations on Azure Data Lake Store using REST API or the WebHDFS FileSystem
APIs.
Learn more about Access Control in Data Lake Store.
to access Resource Manager
This tutorial shows you how to enable Managed Service Identity (MSI) for a Windows virtual machine (VM). You
can then use that identity to access the Azure Resource Manager API. Managed Service Identities are automatically
managed by Azure and enable you to authenticate to services that support Azure AD authentication without
needing to insert credentials into your code. You learn how to:
Grant your VM access to a Resource Group in Azure Resource Manager
Get an access token using the VM identity and use it to call Azure Resource Manager
Prerequisites
Sign in to Azure

click OK.
No.
ManagedIdentityExtensionforWindows will appear in the list.
Grant your VM access to a resource group in Resource Manager

Using MSI your code can get access tokens to authenticate to resources that support Azure AD authentication. The
Azure Resource Manager supports Azure AD authentication. First, we need to grant this VM’s identity access to a
resource in Resource Manager, in this case the Resource Group in which the VM is contained.
1. Navigate to the tab for Resource Groups.
2. Select the specific Resource Group you created for your Windows VM.
3. Go to Access control (IAM) in the left panel.
4. Then Add a new role assignment for your Windows VM. Choose Role as Reader.
5. In the next drop-down, Assign access to the resource Virtual Machine.
6. Next, ensure the proper subscription is listed in the Subscription dropdown. And for Resource Group, select
All resource groups.
7. Finally, in Select choose your Windows VM in the dropdown and click Save.
Get an access token using the VM identity and use it to call Azure
Resource Manager
You will need to use PowerShell in this portion. If you don’t have installed, download it here.
1. In the portal, navigate to Virtual Machines and go to your Windows virtual machine and in the Overview, click
Connect.
remote session.
4. Using Powershell’s Invoke-WebRequest, make a request to the local MSI endpoint to get an access token for
Azure Resource Manager.

@{resource="https://management.azure.com/"} -Headers @{Metadata="true"}
NOTE
The value of the "resource" parameter must be an exact match for what is expected by Azure AD. When using the
Azure Resource Manager resource ID, you must include the trailing slash on the URI.
Next, extract the full response, which is stored as a JavaScript Object Notation (JSON) formatted string in the
$response object.
Next, extract the access token from the response.
$ArmToken = $content.access_token
Finally, call Azure Resource Manager using the access token. In this example, we're also using PowerShell's
Invoke-WebRequest to make the call to Azure Resource Manager, and include the access token in the
Authorization header.
(Invoke-WebRequest -Uri https://management.azure.com/subscriptions/<SUBSCRIPTION

ID>/resourceGroups/<RESOURCE GROUP>?api-version=2016-06-01 -Method GET -ContentType "application/json" -
Headers @{ Authorization ="Bearer $ArmToken"}).content
NOTE
The URL is case-sensitive, so ensure if you are using the exact same case as you used earlier when you named the
Resource Group, and the uppercase "G" in "resourceGroups."
The following command returns the details of the Resource Group:
{"id":"/subscriptions/98f51385-2edc-4b79-bed9-
7718de4cb861/resourceGroups/DevTest","name":"DevTest","location":"westus","properties":
{"provisioningState":"Succeeded"}}
Related content
access Azure Resource Manager
This tutorial shows you how to enable Managed Service Identity (MSI) for a Linux Virtual Machine, and then use
that identity to access the Azure Resource Manager API. Managed Service Identities are automatically managed by
Azure and enable you to authenticate to services that support Azure AD authentication without needing to insert
credentials into your code. You learn how to:
Enable MSI on a Linux Virtual Machine
Get an access token using the VM identity and use it to call Azure Resource Manager
Prerequisites
Sign in to Azure


enables MSI for the VM.
No.

Using MSI your code can get access tokens to authenticate to resources that support Azure AD authentication. The
Azure Resource Manager API supports Azure AD authentication. First, we need to grant this VM's identity access to
a resource in Azure Resource Manager, in this case the Resource Group in which the VM is contained.
1. Navigate to the tab for Resource Groups.
2. Select the specific Resource Group you created earlier.
3. Go to Access control(IAM) in the left panel.
4. Click to Add a new role assignment for your VM. Choose Role as Reader.
5. In the next dropdown, Assign access to the resource Virtual Machine.
6. Next, ensure the proper subscription is listed in the Subscription dropdown. And for Resource Group, select
All resource groups.
7. Finally, in Select choose your Linux Virtual Machine in the dropdown and click Save.
Get an access token using the VM's identity and use it to call Resource
Manager
To complete these steps, you will need an SSH client. If you are using Windows, you can use the SSH client in the
3. In the terminal window, using CURL, make a request to the local MSI endpoint to get an access token for
The CURL request for the access token is below.
curl http://localhost:50342/oauth2/token --data "resource=https://management.azure.com/" -H

Metadata:true
NOTE
The value of the “resource” parameter must be an exact match for what is expected by Azure AD. In the case of the
Resource Manager resource ID, you must include the trailing slash on the URI.
The response includes the access token you need to access Azure Resource Manager.
Response:
{"access_token":"eyJ0eXAiOi...",
"refresh_token":"",
"expires_on":"1504130527",
"not_before":"1504126627",
"resource":"https://management.azure.com",
You can use this access token to access Azure Resource Manager, for example to read the details of the
Resource Group to which you previously granted this VM access. Replace the values of <SUBSCRIPTION
ID>, <RESOURCE GROUP>, and <ACCESS TOKEN> with the ones you created earlier.
NOTE
The URL is case-sensitive, so ensure if you are using the exact same case as you used earlier when you named the
Resource Group, and the uppercase “G” in “resourceGroup”.
curl https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE GROUP>?api-

version=2016-09-01 -H "Authorization: Bearer <ACCESS TOKEN>"
The response back with the specific Resource Group information:
{"id":"/subscriptions/98f51385-2edc-4b79-bed9-
7718de4cb861/resourceGroups/DevTest","name":"DevTest","location":"westus","properties":
{"provisioningState":"Succeeded"}}
Related content
to access Azure SQL
This tutorial shows you how to use a Managed Service Identity (MSI) for a Windows virtual machine (VM) to access
an Azure SQL server. Managed Service Identities are automatically managed by Azure and enable you to
You learn how to:
Grant your VM access to an Azure SQL server
Get an access token using the VM identity and use it to query an Azure SQL server
Prerequisites
Sign in to Azure

click OK.
No.
Grant your VM access to a database in an Azure SQL server

Now you can grant your VM access to a database in an Azure SQL server. For this step, you can use an existing SQL
server or create a new one. To create a new server and database using the Azure portal, follow this Azure SQL
quickstart. There are also quickstarts that use the Azure CLI and Azure PowerShell in the Azure SQL documentation.
There are three steps to granting your VM access to a database:
1. Create a group in Azure AD and make the VM MSI a member of the group.
2. Enable Azure AD authentication for the SQL server.
3. Create a contained user in the database that represents the Azure AD group.
NOTE
Normally you would create a contained user that maps directly to the VM's MSI. Currently, Azure SQL does not allow the
Azure AD Service Principal that represents the VM MSI to be mapped to a contained user. As a supported workaround, you
make the VM MSI a member of an Azure AD group, then create a contained user in the database that represents the group.
Create a group in Azure AD and make the VM MSI a member of the group
You can use an existing Azure AD group, or create a new one using Azure AD PowerShell.
First, install the Azure AD PowerShell module. Then sign in using Connect-AzureAD , and run the following command
to create the group, and save it in a variable:
$Group = New-AzureADGroup -DisplayName "VM MSI access to SQL" -MailEnabled $false -SecurityEnabled $true -
MailNickName "NotSet"
The output looks like the following, which also examines the value of the variable:
$Group = New-AzureADGroup -DisplayName "VM MSI access to SQL" -MailEnabled $false -SecurityEnabled $true -
MailNickName "NotSet"
$Group
ObjectId DisplayName Description
-------- ----------- -----------
6de75f3c-8b2f-4bf4-b9f8-78cc60a18050 VM MSI access to SQL
Next, add the VM's MSI to the group. You need the MSI's ObjectId, which you can get using Azure PowerShell.
First, download Azure PowerShell. Then sign in using Login-AzureRmAccount , and run the following commands to:
Ensure your session context is set to the desired Azure subscription, if you have multiple ones.
List the available resources in your Azure subscription, in verify the correct resource group and VM names.
Get the MSI VM's properties, using the appropriate values for <RESOURCE-GROUP> and <VM-NAME> .
Set-AzureRMContext -subscription "bdc79274-6bb9-48a8-bfd8-00c140fxxxx"

Get-AzureRmResource
$VM = Get-AzureRmVm -ResourceGroup <RESOURCE-GROUP> -Name <VM-NAME>
The output looks like the following, which also examines the service principal Object ID of the VM's MSI:
$VM = Get-AzureRmVm -ResourceGroup DevTestGroup -Name DevTestWinVM

$VM.Identity.PrincipalId
b83305de-f496-49ca-9427-e77512f6cc64
Now add the VM MSI to the group. You can only add a service principal to a group using Azure AD PowerShell. Run
this command:
Add-AzureAdGroupMember -ObjectId $Group.ObjectId -RefObjectId $VM.Identity.PrincipalId
If you also examine the group membership afterward, the output looks as follows:
Add-AzureAdGroupMember -ObjectId $Group.ObjectId -RefObjectId $VM.Identity.PrincipalId

Get-AzureAdGroupMember -ObjectId $Group.ObjectId
ObjectId AppId DisplayName

-------- ----- -----------
b83305de-f496-49ca-9427-e77512f6cc64 0b67a6d6-6090-4ab4-b423-d6edda8e5d9f DevTestWinVM
Enable Azure AD authentication for the SQL server

Now that you have created the group and added the VM MSI to the membership, you can configure Azure AD
authentication for the SQL server using the following steps:
1. In the Azure portal, select SQL servers from the left-hand navigation.
2. Click the SQL server to be enabled for Azure AD authentication.
3. In the Settings section of the blade, click Active Directory admin.
4. In the command bar, click Set admin.
5. Select an Azure AD user account to be made an administrator of the server, and click Select.
6. In the command bar, click Save.
Create a contained user in the database that represents the Azure AD group
For this next step, you will need Microsoft SQL Server Management Studio (SSMS). Before beginning, it may also
be helpful to review the following articles for background on Azure AD integration:
Universal Authentication with SQL Database and SQL Data Warehouse (SSMS support for MFA)
Configure and manage Azure Active Directory authentication with SQL Database or SQL Data Warehouse
1. Start SQL Server Management Studio.
2. In the Connect to Server dialog, Enter your SQL server name in the Server name field.
3. In the Authentication field, select Active Directory - Universal with MFA support.
4. In the User name field, enter the name of the Azure AD account that you set as the server administrator, for
example, helen@woodgroveonline.com
5. Click Options.
6. In the Connect to database field, enter the name of the non-system database you want to configure.
7. Click Connect. Complete the sign-in process.
8. In the Object Explorer, expand the Databases folder.
9. Right-click on a user database and click New query.
10. In the query window, enter the following line, and click Execute in the toolbar:
CREATE USER [VM MSI access to SQL] FROM EXTERNAL PROVIDER
The command should complete successfully, creating the contained user for the group.
11. Clear the query window, enter the following line, and click Execute in the toolbar:
ALTER ROLE db_datareader ADD MEMBER [VM MSI access to SQL]
The command should complete successfully, granting the contained user the ability to read the entire
database.
Code running in the VM can now get a token from MSI and use the token to authenticate to the SQL server.
Get an access token using the VM identity and use it to call Azure SQL
Azure SQL natively supports Azure AD authentication, so it can directly accept access tokens obtained using MSI.
You use the access token method of creating a connection to SQL. This is part of Azure SQL's integration with
Azure AD, and is different from supplying credentials on the connection string.
Here's a .Net code example of opening a connection to SQL using an access token. This code must run on the VM to
be able to access the VM MSI endpoint. .Net Framework 4.6 or higher is required to use the access token method.
Replace the values of AZURE-SQL-SERVERNAME and DATABASE accordingly. Note the resource ID for Azure SQL is
"https://database.windows.net/".
using System.Net;
using System.IO;
using System.Data.SqlClient;
using System.Web.Script.Serialization;
//
// Get an access token for SQL.
//
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://localhost:50342/oauth2/token?
resource=https://database.windows.net/");
request.Headers["Metadata"] = "true";
request.Method = "GET";
string accessToken = null;
try
{
// Call MSI endpoint.
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
// Pipe response Stream to a StreamReader and extract access token.

StreamReader streamResponse = new StreamReader(response.GetResponseStream());
string stringResponse = streamResponse.ReadToEnd();
JavaScriptSerializer j = new JavaScriptSerializer();
Dictionary<string, string> list = (Dictionary<string, string>) j.Deserialize(stringResponse,
typeof(Dictionary<string, string>));
accessToken = list["access_token"];
}
catch (Exception e)
{
string errorText = String.Format("{0} \n\n{1}", e.Message, e.InnerException != null ?
e.InnerException.Message : "Acquire token failed");
}
//
// Open a connection to the SQL server using the access token.
//
if (accessToken != null) {
string connectionString = "Data Source=<AZURE-SQL-SERVERNAME>; Initial Catalog=<DATABASE>;";
SqlConnection conn = new SqlConnection(connectionString);
conn.AccessToken = accessToken;
conn.Open();
}
Alternatively, a quick way to test the end to end setup without having to write and deploy an app on the VM is
using PowerShell.
Connect.
remote session.
4. Using PowerShell’s Invoke-WebRequest , make a request to the local MSI endpoint to get an access token for
Azure SQL.

@{resource="https://database.windows.net/"} -Headers @{Metadata="true"}
Convert the response from a JSON object to a PowerShell object.

Extract the access token from the response.
$AccessToken = $content.access_token
5. Open a connection to the SQL server. Remember to replace the values for AZURE-SQL-SERVERNAME and
DATABASE.
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection

$SqlConnection.ConnectionString = "Data Source = <AZURE-SQL-SERVERNAME>; Initial Catalog = <DATABASE>"
$SqlConnection.AccessToken = $AccessToken
$SqlConnection.Open()
Next, create and send a query to the server. Remember to replace the value for TABLE.
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand

$SqlCmd.CommandText = "SELECT * from <TABLE>;"
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
Examine the value of $DataSet.Tables[0] to view the results of the query. Congratulations, you've queried the
database using a VM MSI and without needing to supply credentials!
Related content
Learn more about Azure SQL support for Azure AD authentication.
Learn more about configuring Azure SQL support for Azure AD authentication.
Learn more about authentication and access in SQL server.
Use a Windows VM Managed Service Identity to
access Azure Storage via access key
This tutorial shows you how to enable Managed Service Identity (MSI) for a Windows Virtual Machine, then use
that identity to retrieve storage account access keys. You can use storage access keys as usual when doing storage
operations, for example when using the Storage SDK. For this tutorial, we upload and download blobs using Azure
Storage PowerShell. You will learn how to:
Enable MSI on a Windows Virtual Machine
Grant your VM access to storage account access keys in Resource Manager
Get an access token using your VM's identity, and use it to retrieve the storage access keys from Resource
Manager
Prerequisites
Sign in to Azure

1. Click the +/Create new service button found on the upper left-hand corner of the Azure portal.
5. To select a new Resource Group you would like to virtual machine to be created in, choose Create New. When
complete, click OK.
the settings blade, keep the defaults and click OK.
enables MSI for the Virtual Machine.
1. Navigate to the resource group of your new virtual machine, and select the virtual machine you created in the
previous step.
2. Under the VM "Settings" on the left, click Configuration.
3. To register and enable the MSI, select Yes, if you wish to disable it, choose No.
5. If you wish to check which extensions are on the VM, click Extensions. If MSI is enabled, the
Create a storage account

If you don't already have one, you will now create a storage account. You can also skip this step and grant your VM
MSI access to the keys of an existing storage account.
2. Click Storage, then Storage Account, and a new "Create storage account" panel will display.
3. Enter a name for the storage account, which you will use later.
4. Deployment model and Account kind should be set to "Resource manager" and "General purpose",
respectively.
5. Ensure the Subscription and Resource Group match the ones you specified when you created your VM in the
previous step.
6. Click Create.
Create a blob container in the storage account
Later we will upload and download a file to the new storage account. Because files require blob storage, we need to
create a blob container in which to store the file.
1. Navigate back to your newly created storage account.
2. Click the Containers link in the left, under "Blob service."
3. Click + Container on the top of the page, and a "New container" panel slides out.
4. Give the container a name, select an access level, then click OK. The name you specified will be used later in
the tutorial.
Grant your VM's MSI access to use storage account access keys
Azure Storage does not natively support Azure AD authentication. However, you can use an MSI to retrieve storage
account access keys from the Resource Manager, then use a key to access storage. In this step, you grant your VM
MSI access to the keys to your storage account.
1. Navigate back to your newly created storage account. 
2. Click the Access control (IAM) link in the left panel.
3. Click + Add on top of the page to add a new role assignment for your VM
4. Set Role to "Storage Account Key Operator Service Role", on the right side of the page.
5. In the next dropdown, set Assign access to the resource "Virtual Machine".
6. Next, ensure the proper subscription is listed in Subscription dropdown, then set Resource Group to "All
resource groups".
7. Finally, under Select choose your Windows Virtual Machine in the dropdown, then click Save.
Get an access token using the VM's identity and use it to call Azure
Resource Manager
For the remainder of the tutorial, we will work from the VM we created earlier.
You will need to use the Azure Resource Manager PowerShell cmdlets in this portion. If you don’t have it installed,
download the latest version before continuing.
1. In the Azure portal, navigate to Virtual Machines, go to your Windows virtual machine, then from the
Overview page click Connect at the top.
remote session.

NOTE
Next, extract the "Content" element, which is stored as a JavaScript Object Notation (JSON) formatted string
in the $response object.
Get storage account access keys from Azure Resource Manager to

make storage calls
Now use PowerShell to call Resource Manager using the access token we retrieved in the previous section, to
retrieve the storage access key. Once we have the storage access key, we can call storage upload/download
operations.
$keysResponse = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/<SUBSCRIPTION-

ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE-ACCOUNT>/listKeys/?
api-version=2016-12-01 -Method POST -Headers @{Authorization="Bearer $ARMToken"}
NOTE
The URL is case-sensitive, so ensure you use the exact same case used earlier, when you named the Resource Group,
including the uppercase "G" in "resourceGroups."
$keysContent = $keysResponse.Content | ConvertFrom-Json

$key = $keysContent.keys[0].value
Next we create a file called "test.txt". Then use the storage access key to authenticate with the
New-AzureStorageContent cmdlet, upload the file to our blob container, then download the file.
echo "This is a test text file." > test.txt
Be sure to install the Azure Storage cmdlets first, using Install-Module Azure.Storage . Then upload the blob you
just created, using the Set-AzureStorageBlobContent PowerShell cmdlet:
$ctx = New-AzureStorageContext -StorageAccountName <STORAGE-ACCOUNT> -StorageAccountKey $key

Set-AzureStorageBlobContent -File test.txt -Container <CONTAINER-NAME> -Blob testblob -Context $ctx
Response:
ICloudBlob : Microsoft.WindowsAzure.Storage.Blob.CloudBlockBlob
BlobType : BlockBlob
Length : 56
ContentType : application/octet-stream
LastModified : 9/13/2017 6:14:25 PM +00:00
SnapshotTime :
ContinuationToken :
Context : Microsoft.WindowsAzure.Commands.Storage.AzureStorageContext
Name : testblob
You can also download the blob you just uploaded, using the Get-AzureStorageBlobContent PowerShell cmdlet:
Get-AzureStorageBlobContent -Blob testblob -Container <CONTAINER-NAME> -Destination test2.txt -Context $ctx
Response:
Length : 56
LastModified : 9/13/2017 6:14:25 PM +00:00
SnapshotTime :
ContinuationToken :
Name : testblob
Related content
To learn how to do this same tutorial using a storage SAS credential, see Use a Windows VM Managed Service
Identity to access Azure Storage via a SAS credential
For more information about the Azure Storage account SAS feature, see:
Using shared access signatures (SAS)
Constructing a Service SAS
Use the following comments section to provide feedback and help us refine and shape our content
Use a Windows VM Managed Service Identity to
access Azure Storage via a SAS credential
This tutorial shows you how to enable Managed Service Identity (MSI) for a Windows Virtual Machine, then use the
MSI to obtain a storage Shared Access Signature (SAS) credential. Specifically, a Service SAS credential.
A Service SAS provides the ability to grant limited access to objects in a storage account, for limited time and a
specific service (in our case, the blob service), without exposing an account access key. You can use a SAS credential
as usual when doing storage operations, for example when using the Storage SDK. For this tutorial, we
demonstrate uploading and downloading a blob using Azure Storage PowerShell. You will learn how to:
Enable MSI on a Windows Virtual Machine
Grant your VM access to a storage account SAS in Resource Manager
Get an access token using your VM's identity, and use it to retrieve the SAS from Resource Manager
Prerequisites
Sign in to Azure

complete, click OK.
enables MSI for the Virtual Machine.
previous step.
2. Under the VM "Settings" on the left panel, click Configuration.

MSI access to the SAS credential of an existing storage account.
3. Enter a name for the storage account, which you will use later.
respectively.
previous step.
6. Click Create.
2. Click the Containers link in the left panel, under "Blob service."
the tutorial.
Grant your VM's MSI access to use a storage SAS
Azure Storage does not natively support Azure AD authentication. However, you can use an MSI to retrieve a
storage SAS from Resource Manager, then use the SAS to access storage. In this step, you grant your VM MSI
access to your storage account SAS.
1. Navigate back to your newly created storage account.  
4. Set Role to "Storage Account Contributor", on the right side of the page.
resource groups".
7. Finally, under Select choose your Windows Virtual Machine in the dropdown, then click Save.
Resource Manager
You will need to use the Azure Resource Manager PowerShell cmdlets in this portion. If you don’t have it installed,
download the latest version before continuing.
1. In the Azure portal, navigate to Virtual Machines, go to your Windows virtual machine, then from the
Overview page click Connect at the top.
remote session.

NOTE
Next, extract the "Content" element, which is stored as a JavaScript Object Notation (JSON) formatted string
in the $response object.
Get a SAS credential from Azure Resource Manager to make storage

calls
Now use PowerShell to call Resource Manager using the access token we retrieved in the previous section, to
create a storage SAS credential. Once we have the SAS credential, we can call storage operations.
For this request we'll use the follow HTTP request parameters to create the SAS credential:
{
"canonicalizedResource":"/blob/<STORAGE ACCOUNT NAME>/<CONTAINER NAME>",
"signedResource":"c", // The kind of resource accessible with the SAS, in this case a
container (c).
"signedPermission":"rcw", // Permissions for this SAS, in this case (r)ead, (c)reate, and
(w)rite. Order is important.
"signedProtocol":"https", // Require the SAS be used on https protocol.
"signedExpiry":"<EXPIRATION TIME>" // UTC expiration time for SAS in ISO 8601 format, for example 2017-09-
22T00:06:00Z.
}
These parameters are included in the POST body of the request for the SAS credential. For more information on the
parameters for creating a SAS credential, see the List Service SAS REST reference.
First, convert the parameters to JSON, then call the storage listServiceSas endpoint to create the SAS credential:
$params = @{canonicalizedResource="/blob/<STORAGE-ACCOUNT-NAME>/<CONTAINER-
NAME>";signedResource="c";signedPermission="rcw";signedProtocol="https";signedExpiry="2017-09-23T00:00:00Z"}
$jsonParams = $params | ConvertTo-Json
$sasResponse = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/<SUBSCRIPTION-

ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE-ACCOUNT-
NAME>/listServiceSas/?api-version=2017-06-01 -Method POST -Body $jsonParams -Headers @{Authorization="Bearer
$ArmToken"}
NOTE
The URL is case-sensitive, so ensure you use the exact same case used earlier, when you named the Resource Group,
including the uppercase "G" in "resourceGroups."
Now we can extract the SAS credential from the response:
$sasContent = $sasResponse.Content | ConvertFrom-Json

$sasCred = $sasContent.serviceSasToken
If you inspect the SAS cred you'll see something like this:
PS C:\> $sasCred
sv=2015-04-05&sr=c&spr=https&se=2017-09-
23T00%3A00%3A00Z&sp=rcw&sig=JVhIWG48nmxqhTIuN0uiFBppdzhwHdehdYan1W%2F4O0E%3D
Next we create a file called "test.txt". Then use the SAS credential to authenticate with the New-AzureStorageContent
cmdlet, upload the file to our blob container, then download the file.
echo "This is a test text file." > test.txt
Be sure to install the Azure Storage cmdlets first, using Install-Module Azure.Storage . Then upload the blob you
just created, using the Set-AzureStorageBlobContent PowerShell cmdlet:
$ctx = New-AzureStorageContext -StorageAccountName <STORAGE-ACCOUNT-NAME> -SasToken $sasCred

Set-AzureStorageBlobContent -File test.txt -Container <CONTAINER-NAME> -Blob testblob -Context $ctx
Response:
Length : 56
LastModified : 9/21/2017 6:14:25 PM +00:00
SnapshotTime :
ContinuationToken :
Name : testblob
You can also download the blob you just uploaded, using the Get-AzureStorageBlobContent PowerShell cmdlet:
Get-AzureStorageBlobContent -Blob testblob -Container <CONTAINER-NAME> -Destination test2.txt -Context $ctx

Response:
Length : 56
LastModified : 9/21/2017 6:14:25 PM +00:00
SnapshotTime :
ContinuationToken :
Name : testblob
Related content
To learn how to do this same tutorial using a storage account key, see Use a Windows VM Managed Service
Identity to access Azure Storage
Use a Linux VM Managed Service Identity to access
Azure Storage via access key
This tutorial shows you how to enable Managed Service Identity (MSI) for a Linux Virtual Machine and then use that
identity to retrieve storage account access keys. You can use a storage access key as usual when doing storage
operations, for example when using the Storage SDK. For this tutorial, we upload and download blobs using Azure
CLI. You will learn how to:
Grant your VM access to storage account access keys in Resource Manager
Get an access token using your VM's identity, and use it to retrieve the storage access keys from Resource
Manager
Prerequisites
Sign in to Azure
Create a Linux virtual machine in a new resource group


enables Managed Service Identity for the VM.
previous step.
ManagedIdentityExtensionforLinux appears in the list.

3. Enter a Name for the storage account, which you will use later.
respectively.
previous step.
6. Click Create.

2. Click the Containers link in the left, under "Blob service."
the tutorial.
Grant your VM's MSI access to use storage account access keys
Azure Storage does not natively support Azure AD authentication. However, you can use an MSI to retrieve storage
account access keys from the Resource Manager, then use a key to access storage. In this step, you grant your VM
MSI access to the keys to your storage account.
4. Set Role to "Storage Account Key Operator Service Role", on the right side of the page.
resource groups".
7. Finally, under Select choose your Linux Virtual Machine in the dropdown, then click Save.
Resource Manager
1. In the Azure portal, navigate to Virtual Machines, go to your Linux virtual machine, then from the Overview
page click Connect at the top. Copy the string to connect to your VM.
2. Connect to your VM using your SSH client.
3. Next, you will be prompted to enter in your Password you added when creating the Linux VM. You should
then be successfully signed in.
4. Use CURL to get an access token for Azure Resource Manager.
The CURL request and response for the access token is below:

Metadata:true
NOTE
In the previous request, the value of the "resource" parameter must be an exact match for what is expected by Azure
AD. When using the Azure Resource Manager resource ID, you must include the trailing slash on the URI. In the
following response, the access_token element as been shortened for brevity.
"refresh_token":"",
"expires_on":"1504130527",
"not_before":"1504126627",
Get storage account access keys from Azure Resource Manager to

make storage calls
Now use CURL to call Resource Manager using the access token we retrieved in the previous section, to retrieve the
storage access key. Once we have the storage access key, we can call storage upload/download operations. Be sure
to replace the <SUBSCRIPTION ID> , <RESOURCE GROUP> , and <STORAGE ACCOUNT NAME> parameter values with your own
values. Replace the <ACCESS TOKEN> value with the access token you retrieved earlier:
curl https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE

GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE ACCOUNT NAME>/listKeys?api-version=2016-12-01 –-
request POST -d "" -H "Authorization: Bearer <ACCESS TOKEN>"
NOTE
The text in the prior URL is case sensitive, so ensure if you are using upper-lowercase for your Resource Groups to reflect it
accordingly. Additionally, it’s important to know that this is a POST request not a GET request and ensure you pass a value to
capture a length limit with -d that can be NULL.
The CURL response gives you the list of Keys:
{"keys":[{"keyName":"key1","permissions":"Full","value":"iqDPNt..."},
{"keyName":"key2","permissions":"Full","value":"U+uI0B..."}]}
Create a sample blob file to upload to your blob storage container. On a Linux VM you can do this with the
following command.
echo "This is a test file." > test.txt
Next, authenticate with the CLI az storage command using the storage access key, and upload the file to the blob
container. For this step, you will need to install the latest Azure CLI on your VM, if you haven't already.
az storage blob upload -c <CONTAINER NAME> -n test.txt -f test.txt --account-name <STORAGE ACCOUNT NAME> --
account-key <STORAGE ACCOUNT KEY>
Response:
Finished[#############################################################] 100.0000%
{
"etag": "\"0x8D4F9929765C139\"",
"lastModified": "2017-09-12T03:58:56+00:00"
}
Additionally, you can download the file using the Azure CLI and authenticating with the storage access key.
Request:
az storage blob download -c <CONTAINER NAME> -n test.txt -f test-download.txt --account-name <STORAGE ACCOUNT
NAME> --account-key <STORAGE ACCOUNT KEY>
Response:
{
"content": null,
"metadata": {},
"name": "test.txt",
"properties": {
"appendBlobCommittedBlockCount": null,
"blobType": "BlockBlob",
"contentLength": 21,
"contentRange": "bytes 0-20/21",
"contentSettings": {
"cacheControl": null,
"contentDisposition": null,
"contentEncoding": null,
"contentLanguage": null,
"contentMd5": "LSghAvpnElYyfUdn7CO8aw==",
"contentType": "text/plain"
},
"copy": {
"completionTime": null,
"id": null,
"progress": null,
"source": null,
"status": null,
"statusDescription": null
},
"etag": "\"0x8D5067F30D0C283\"",
"lastModified": "2017-09-28T14:42:49+00:00",
"lease": {
"duration": null,
"state": "available",
"status": "unlocked"
},
"pageBlobSequenceNumber": null,
"serverEncrypted": false
},
"snapshot": null
}
Next steps
To learn how to do this same tutorial using a storage SAS credential, see Use a Linux VM Managed Service
Identity to access Azure Storage via a SAS credential
Use a Linux VM Managed Service Identity to access
Azure Storage via a SAS credential
This tutorial shows you how to enable Managed Service Identity (MSI) for a Linux Virtual Machine, then use the MSI
to obtain a storage Shared Access Signature (SAS) credential. Specifically, a Service SAS credential.
A Service SAS provides the ability to grant limited access to objects in a storage account, for a limited time and a
specific service (in our case, the blob service), without exposing an account access key. You can use a SAS credential
as usual when doing storage operations, for example when using the Storage SDK. For this tutorial, we
demonstrate uploading and downloading a blob using Azure Storage CLI. You will learn how to:
Grant your VM access to a storage account SAS in Resource Manager
Get an access token using your VM's identity, and use it to retrieve the SAS from Resource Manager
Prerequisites
Sign in to Azure
Create a Linux virtual machine in a new resource group


enables Managed Service Identity for the VM.
previous step.
ManagedIdentityExtensionforLinux appears in the list.

3. Enter a Name for the storage account, which you will use later.
respectively.
previous step.
6. Click Create.

2. Click the Containers link in the left panel, under "Blob service."
the tutorial.
Grant your VM's MSI access to use a storage SAS
Azure Storage does not natively support Azure AD authentication. However, you can use an MSI to retrieve a
storage SAS from the Resource Manager, then use the SAS to access storage. In this step, you grant your VM MSI
access to your storage account SAS.
1. Navigate back to your newly created storage account..  
4. Set Role to "Storage Account Contributor", on the right side of the page.
resource groups".
7. Finally, under Select choose your Linux Virtual Machine in the dropdown, then click Save.
Resource Manager
1. In the Azure portal, navigate to Virtual Machines, go to your Linux virtual machine, then from the Overview
page click Connect at the top. Copy the string to connect to your VM.
2. Connect to your VM using your SSH client.
3. Next, you will be prompted to enter in your Password you added when creating the Linux VM. You should
then be successfully signed in.
4. Use CURL to get an access token for Azure Resource Manager.
The CURL request and response for the access token is below:

Metadata:true
NOTE
In the previous request, the value of the "resource" parameter must be an exact match for what is expected by Azure
AD. When using the Azure Resource Manager resource ID, you must include the trailing slash on the URI. In the
following response, the access_token element as been shortened for brevity.
"refresh_token":"",
"expires_on":"1504130527",
"not_before":"1504126627",
Get a SAS credential from Azure Resource Manager to make storage

calls
Now use CURL to call Resource Manager using the access token we retrieved in the previous section, to create a
storage SAS credential. Once we have the SAS credential, we can call storage upload/download operations.
For this request we'll use the follow HTTP request parameters to create the SAS credential:
{
"canonicalizedResource":"/blob/<STORAGE ACCOUNT NAME>/<CONTAINER NAME>",
"signedResource":"c", // The kind of resource accessible with the SAS, in this case a
container (c).
"signedPermission":"rcw", // Permissions for this SAS, in this case (r)ead, (c)reate, and
(w)rite. Order is important.
"signedProtocol":"https", // Require the SAS be used on https protocol.
"signedExpiry":"<EXPIRATION TIME>" // UTC expiration time for SAS in ISO 8601 format, for example 2017-09-
22T00:06:00Z.
}
These parameters are included in the POST body of the request for the SAS credential. For more information on the
parameters for creating a SAS credential, see the List Service SAS REST reference.
Use the following CURL request to get the SAS credential. Be sure to replace the <SUBSCRIPTION ID> ,
<RESOURCE GROUP> , <STORAGE ACCOUNT NAME> , <CONTAINER NAME> , and <EXPIRATION TIME> parameter values with your
own values. Replace the <ACCESS TOKEN> value with the access token you retrieved earlier:
curl https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE
GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE ACCOUNT NAME>/listServiceSas/?api-version=2017-06-
01 -X POST -d "{\"canonicalizedResource\":\"/blob/<STORAGE ACCOUNT NAME>/<CONTAINER
NAME>\",\"signedResource\":\"c\",\"signedPermission\":\"rcw\",\"signedProtocol\":\"https\",\"signedExpiry\":\"
<EXPIRATION TIME>\"}" -H "Authorization: Bearer <ACCESS TOKEN>"
NOTE
The text in the prior URL is case sensitive, so ensure if you are using upper-lowercase for your Resource Groups to reflect it
accordingly. Additionally, it’s important to know that this is a POST request not a GET request.
The CURL response returns the SAS credential:
{"serviceSasToken":"sv=2015-04-05&sr=c&spr=https&st=2017-09-22T00%3A10%3A00Z&se=2017-09-
22T02%3A00%3A00Z&sp=rcw&sig=QcVwljccgWcNMbe9roAJbD8J5oEkYoq%2F0cUPlgriBn0%3D"}
Create a sample blob file to upload to your blob storage container. On a Linux VM you can do this with the
following command.
echo "This is a test file." > test.txt
Next, authenticate with the CLI az storage command using the SAS credential, and upload the file to the blob
container. For this step, you will need to install the latest Azure CLI on your VM, if you haven't already.
az storage blob upload --container-name

--file
--name
--account-name
--sas-token
Response:
Finished[#############################################################] 100.0000%
{
"etag": "\"0x8D4F9929765C139\"",
"lastModified": "2017-09-21T03:58:56+00:00"
}
Additionally, you can download the file using the Azure CLI and authenticating with the SAS credential.
Request:
az storage blob download --container-name

--file
--name
--account-name
--sas-token
Response:
{
"content": null,
"metadata": {},
"name": "testblob",
"properties": {
"appendBlobCommittedBlockCount": null,
"blobType": "BlockBlob",
"contentLength": 16,
"contentRange": "bytes 0-15/16",
"contentSettings": {
"cacheControl": null,
"contentDisposition": null,
"contentEncoding": null,
"contentLanguage": null,
"contentMd5": "Aryr///Rb+D8JQ8IytleDA==",
"contentType": "text/plain"
},
"copy": {
"completionTime": null,
"id": null,
"progress": null,
"source": null,
"status": null,
"statusDescription": null
},
"etag": "\"0x8D4F9929765C139\"",
"lastModified": "2017-09-21T03:58:56+00:00",
"lease": {
"duration": null,
"state": "available",
"status": "unlocked"
},
"pageBlobSequenceNumber": null,
"serverEncrypted": false
},
"snapshot": null
}
Next steps
To learn how to do this same tutorial using a storage account key, see Use a Linux VM Managed Service Identity
to access Azure Storage
to access Azure Key Vault
This tutorial shows you how to enable Managed Service Identity (MSI) for a Windows Virtual Machine, then use that
identity to access Azure Key Vault. Serving as a bootstrap, Key Vault makes it possible for your client application to
then use the secret to access resources not secured by Azure Active Directory (AD). Managed Service Identities are
automatically managed by Azure and enable you to authenticate to services that support Azure AD authentication,
without needing to insert credentials into your code.
You learn how to:
Enable Managed Service Identity on a Windows Virtual Machine
Grant your VM access to a secret stored in a Key Vault
Get an access token using the VM identity and use it to retrieve the secret from Key Vault
Prerequisites
Sign in to Azure

complete, click OK.
your code. Enabling MSI tells Azure to create a managed identity for your Virtual Machine. Under the covers,
enabling MSI does two things: it installs the MSI VM extension on your VM, and it enables MSI in Azure Resource
Manager.
No.
Grant your VM access to a Secret stored in a Key Vault

Using MSI your code can get access tokens to authenticate to resources that support Azure AD authentication. 
However, not all Azure services support Azure AD authentication. To use MSI with those services, store the service
credentials in Azure Key Vault, and use MSI to access Key Vault to retrieve the credentials.
First, we need to create a Key Vault and grant our VM’s identity access to the Key Vault.  
1. At the top of the left navigation bar select + New then Security + Identity then Key Vault.
2. Provide a Name for the new Key Vault.
3. Locate the Key Vault in the same subscription and resource group as the VM you created earlier.
4. Select Access policies and click Add new.
5. In Configure from template, select Secret Management.
6. Choose Select Principal, and in the search field enter the name of the VM you created earlier. Select the VM in
the result list and click Select.
7. Click OK to finishing adding the new access policy, and OK to finish access policy selection.
8. Click Create to finish creating the Key Vault.
Next, add a secret to the Key Vault, so that later you can retrieve the secret using code running in your VM:
1. Select All Resources, and find and select the Key Vault you created.
2. Select Secrets, and click Add.
3. Select Manual, from Upload options.
4. Enter a name and value for the secret. The value can be anything you want.
5. Leave the activation date and expiration date clear, and leave Enabled as Yes.
6. Click Create to create the secret.
Get an access token using the VM identity and use it to retrieve the
secret from the Key Vault
If you don’t have PowerShell 4.3.1 or greater installed, you'll need to download and install the latest version.
First, we use the VM’s MSI to get an access token to authenticate to Key Vault:
Connect.
remote session.
4. In PowerShell, invoke the web request on the tenant to get the token for the local host in the specific port for
the VM.
The PowerShell request:
PS C:\> $response = Invoke-WebRequest -Uri http://localhost:50342/oauth2/token -Method GET -Body

@{resource="https://vault.azure.net"} -Headers @{Metadata="true"}
Next, extract the full response which is stored as a JavaScript Object Notation (JSON) formatted string in the
$response object.
PS C:\> $content = $response.Content | ConvertFrom-Json
PS C:\> $KeyVaultToken = $content.access_token
Finally, use PowerShell’s Invoke-WebRequest command to retrieve the secret you created earlier in the Key
Vault, passing the access token in the Authorization header. You’ll need the URL of your Key Vault, which is
in the Essentials section of the Overview page of the Key Vault.
PS C:\> (Invoke-WebRequest -Uri https://<your-key-vault-URL>/secrets/<secret-name>?api-version=2016-10-

01 -Method GET -Headers @{Authorization="Bearer $KeyVaultToken"}).content
The response will look like this:
{"value":"p@ssw0rd!","id":"https://mytestkeyvault.vault.azure.net/secrets/MyTestSecret/7c2204c6093c4d859
bc5b9eff8f29050","attributes":
{"enabled":true,"created":1505088747,"updated":1505088747,"recoveryLevel":"Purgeable"}}
Once you’ve retrieved the secret from the Key Vault, you can use it to authenticate to a service that requires a name
and password.
Related content
access Azure Key Vault
This tutorial shows you how to enable Managed Service Identity (MSI) for a Linux Virtual Machine, then use that
identity to access Azure Key Vault. Serving as a bootstrap, Key Vault makes it possible for your client application to
then use the secret to access resources not secured by Azure Active Directory (AD). Managed Service Identities are
automatically managed by Azure and enable you to authenticate to services that support Azure AD authentication,
without needing to insert credentials into your code.
You learn how to:
Grant your VM access to a secret stored in a Key Vault
Get an access token using the VM identity and use it to retrieve the secret from the Key Vault
Prerequisites
Sign in to Azure

settings page, keep the defaults and click OK.

enables MSI for the VM.
No.
Grant your VM access to a Secret stored in a Key Vault

Using MSI your code can get access tokens to authenticate to resources that support Azure Active Directory
authentication. However, not all Azure services support Azure AD authentication. To use MSI with those services,
store the service credentials in Azure Key Vault, and use MSI to access Key Vault to retrieve the credentials.
First, we need to create a Key Vault and grant our VM’s identity access to the Key Vault.  
1. At the top of the left navigation bar select + New then Security + Identity then Key Vault.
2. Provide a Name for the new Key Vault.
3. Locate the Key Vault in the same subscription and resource group as the VM you created earlier.
4. Select Access policies and click Add new.
5. In Configure from template, select Secret Management.
6. Choose Select Principal, and in the search field enter the name of the VM you created earlier. Select the VM in
the result list and click Select.
7. Click OK to finishing adding the new access policy, and OK to finish access policy selection.
8. Click Create to finish creating the Key Vault.
Next, add a secret to the Key Vault, so that later you can retrieve the secret using code running in your VM:
1. Select All Resources, and find and select the Key Vault you created.
2. Select Secrets, and click Add.
3. Select Manual, from Upload options.
4. Enter a name and value for the secret. The value can be anything you want.
5. Leave the activation date and expiration date clear, and leave Enabled as Yes.
6. Click Create to create the secret.
Get an access token using the VM's identity and use it to retrieve the
secret from the Key Vault
To complete these steps, you need an SSH client. If you are using Windows, you can use the SSH client in the
3. In the terminal window, using CURL, make a request to the local MSI endpoint to get an access token for
Azure Key Vault.
The CURL request for the access token is below.
curl http://localhost:50342/oauth2/token --data "resource=https://vault.azure.net" -H Metadata:true
The response includes the access token you need to access Resource Manager.
Response:
{"access_token":"eyJ0eXAi...",
"refresh_token":"",
"expires_on":"1504130527",
"not_before":"1504126627",
"resource":"https://vault.azure.net",
You can use this access token to authenticate to Azure Key Vault. The next CURL request shows how to read
a secret from Key Vault using CURL and the Key Vault REST API. You’ll need the URL of your Key Vault, which
is in the Essentials section of the Overview page of the Key Vault. You will also need the access token you
obtained on the previous call.
curl https://<YOUR-KEY-VAULT-URL>/secrets/<secret-name>?api-version=2016-10-01 -H "Authorization: Bearer

<ACCESS TOKEN>"
The response will look like this:
{"value":"p@ssw0rd!","id":"https://mytestkeyvault.vault.azure.net/secrets/MyTestSecret/7c2204c6093c4d859
bc5b9eff8f29050","attributes":
{"enabled":true,"created":1505088747,"updated":1505088747,"recoveryLevel":"Purgeable"}}
Once you’ve retrieved the secret from the Key Vault, you can use it to authenticate to a service that requires a name
and password.
Related content
FAQs and known issues with Managed Service
Identity (MSI) for Azure Active Directory
Frequently Asked Questions (FAQs)

Is there a private preview available, for additional features?
Yes. If you would like to be considered for enrollment in the private preview, visit our sign-up page.
Does MSI work with Azure Cloud Services?
No, there are no plans to support MSI in Azure Cloud Services.
Does MSI work with the Active Directory Authentication Library (ADAL ) or the Microsoft Authentication Library
(MSAL )?
No, MSI is not yet integrated with ADAL or MSAL. For details on acquiring an MSI token using the MSI REST
endpoint, see How to use an Azure VM Managed Service Identity (MSI) for token acquisition.
What are the supported Linux distributions?
The following Linux distributions support MSI:
CoreOS Stable
CentOS 7.1
RedHat 7.2
Ubuntu 15.04
Other Linux distributions are currently not supported and extension might fail on unsupported distributions.
The extension works on CentOS 6.9. However, due to lack of system support in 6.9, the extension will not auto
restart if crashed or stopped. It restarts when the VM restarts. To restart the extension manually, see How do you
restart the MSI extension?
How do you restart the MSI extension?
On Windows and certain versions of Linux, if the extension stops, the following cmdlet may be used to manually
restart it:
Set-AzureRmVMExtension -Name <extension name> -Type <extension Type> -Location <location> -Publisher
Microsoft.ManagedIdentity -VMName <vm name> -ResourceGroupName <resource group name> -ForceRerun <Any string
different from any last value used>
Where:
Extension name and type for Windows is: ManagedIdentityExtensionForWindows
Extension name and type for Linux is: ManagedIdentityExtensionForLinux
Known issues
"Automation script" fails when attempting schema export for MSI extension
When Managed Service Identity is enabled on a VM, the following error is shown when attempting to use the
“Automation script” feature for the VM, or its resource group:
The Managed Service Identity VM extension does not currently support the ability to export its schema to a resource
group template. As a result, the generated template does not show configuration parameters to enable Managed
Service Identity on the resource. These sections can be added manually by following the examples in Configure a
VM Managed Service Identity by using a template.
When the schema export functionality becomes available for the MSI VM extension, it will be listed in Exporting
Resource Groups that contain VM extensions.
Configuration blade does not appear in the Azure portal
If the VM Configuration blade does not appear on your VM, then MSI has not been enabled in the portal in your
region yet. Check again later. You can also enable MSI for your VM using PowerShell or the Azure CLI.
Cannot assign access to virtual machines in the Access Control (IAM ) blade
If Virtual Machine does not appear in the Azure portal as a choice for Assign access to in Access Control (IAM)
> Add permissions, then Managed Service Identity has not been enabled in the portal in your region yet. Check
again later. You can still select the Managed Service Identity for the role assignment by searching for the MSI’s
Service Principal. Enter the name of the VM in the Select field, and the Service Principal appears in the search result.
VM fails to start after being moved from resource group or subscription
If you move a VM in the running state, it continues to run during the move. However, after the move, if the VM is
stopped and restarted, it will fail to start. This issue happens because the VM is not updating the reference to the
MSI identity and continues to point to it in the old resource group.
Workaround
Trigger an update on the VM so it can get correct values for the MSI. You can do a VM property change to update
the reference to the MSI identity. For example, you can set a new tag value on the VM with the following command:
az vm update -n <VM Name> -g <Resource Group> --set tags.fixVM=1
This command sets a new tag "fixVM" with a value of 1 on the VM.
By setting this property, the VM updates with the correct MSI resource URI, and then you should be able to start the
VM.
Once the VM is started, the tag can be removed by using following command:
az vm update -n <VM Name> -g <Resource Group> --remove tags.fixVM

Assigning administrator roles in Azure Active
Directory
Using Azure Active Directory (Azure AD), you can designate separate administrators to serve different functions.
Administrators have access to various features in the Azure portal and, depending on their role, can create or
edit users, assign administrative roles to others, reset user passwords, manage user licenses, and manage
domains, among other things. A user who is assigned an admin role will have the same permissions across all of
the cloud services to which your organization has subscribed to, regardless of whether you assign the role in the
Office 365 portal, or in the Azure portal, or by using the Azure AD module for Windows PowerShell.
The following administrator roles are available:
Billing Administrator: Makes purchases, manages subscriptions, manages support tickets, and monitors
service health.
Compliance Administrator:Users with this role have management permissions within in the Office 365
Security & Compliance Center and Exchange Admin Center. More information at “About Office 365
admin roles.”
Conditional Access Administrator: Users with this role have the ability to manage Azure Active
Directory conditional access settings.
NOTE
To deploy Exchange ActiveSync conditional access policy in Azure, the user must also be Global Administrator.
CRM Service Administrator: Users with this role have global permissions within Microsoft CRM Online,
when the service is present, as well as the ability to manage support tickets and monitor service health.
More information at About Office 365 admin roles.
Device Administrators: Users with this role become local machine administrators on all Windows 10
devices that are joined to Azure Active Directory. They do not have the ability to manage devices objects
in Azure Active Directory.
Directory Readers: This is a legacy role that is to be assigned to applications that do not support the
Consent Framework. It should not be assigned to any users.
Directory Synchronization Accounts: Do not use. This role is automatically assigned to the Azure AD
Connect service, and is not intended or supported for any other use.
Directory Writers: This is a legacy role that is to be assigned to applications that do not support the
Consent Framework. It should not be assigned to any users.
Exchange Service Administrator: Users with this role have global permissions within Microsoft
Exchange Online, when the service is present. More information at About Office 365 admin roles.
Global Administrator / Company Administrator: Users with this role have access to all administrative
features in Azure Active Directory, as well as services that federate to Azure Active Directory like Exchange
Online, SharePoint Online, and Skype for Business Online. The person who signs up for the Azure Active
Directory tenant becomes a global administrator. Only global administrators can assign other
administrator roles. There can be more than one global administrator at your company. Global admins
can reset the password for any user and all other administrators.
NOTE
In Microsoft Graph API, Azure AD Graph API, and Azure AD PowerShell, this role is identified as "Company
Administrator". It is "Global Administrator" in the Azure portal.
Guest Inviter: Users in this role can manage Azure Active Directory B2B guest user invitations when the
“Members can invite” user setting is set to No. More information about B2B collaboration at About the
Azure AD B2B collaboration preview. It does not include any other permissions.
Intune Service Administrator: Users with this role have global permissions within Microsoft Intune
Online, when the service is present. Additionally, this role contains the ability to manage users and
devices in order to associate policy, as well as create and manage groups.
Mailbox Administrator: This role is only used as part of Exchange Online email support for RIM
Blackberry devices. If your organization does not use Exchange Online email on RIM Blackberry devices,
do not use this role.
Partner Tier 1 Support: Do not use. This role has been deprecated and will be removed from Azure AD
in the future. This role is intended for use by a small number of Microsoft resale partners, and is not
intended for general use.
Partner Tier 2 Support: Do not use. This role has been deprecated and will be removed from Azure AD
in the future. This role is intended for use by a small number of Microsoft resale partners, and is not
intended for general use.
Password Administrator / Helpdesk Administrator: Users with this role can reset passwords, manage
service requests, and monitor service health. Password administrators can reset passwords only for users
and other password administrators.
NOTE
In Microsoft Graph API, Azure AD Graph API and Azure AD PowerShell, this role is identified as "Helpdesk
Administrator". It is "Password Administrator" in the Azure portal.
Power BI Service Administrator: Users with this role have global permissions within Microsoft Power
BI, when the service is present, as well as the ability to manage support tickets and monitor service health.
More information at About Office 365 admin roles.
Privileged Role Administrator: Users with this role can manage role assignments in Azure Active
Directory, as well as within Azure AD Privileged Identity Management. In addition, this role allows
management of all aspects of Privileged Identity Management.
Security Administrator: Users with this role have all of the read-only permissions of the Security reader
role, plus the ability to manage configuration for security-related services: Azure Active Directory Identity
Protection, Azure Information Protection, Privileged Identity Management, and Office 365 Security &
Compliance Center. More information about Office 365 permissions is available at Permissions in the
Office 365 Security & Compliance Center.
Security Reader: Users with this role have global read-only access, including all information in Azure
Active Directory, Identity Protection, Privileged Identity Management, as well as the ability to read Azure
Active Directory sign-in reports and audit logs. The role also grants read-only permission in Office 365
Security & Compliance Center. More information about Office 365 permissions is available at
Permissions in the Office 365 Security & Compliance Center.
Service Support Administrator: Users with this role can open support requests with Microsoft for
Azure and Office 365 services, and views the service dashboard and message center in the Azure portal
and Office 365 admin portal. More information at About Office 365 admin roles.
SharePoint Service Administrator: Users with this role have global permissions within Microsoft
SharePoint Online, when the service is present, as well as the ability to manage support tickets and
monitor service health. More information at About Office 365 admin roles.
Skype for Business / Lync Service Administrator: Users with this role have global permissions within
Microsoft Skype for Business, when the service is present, as well as manage Skype-specific user
attributes in Azure Active Directory. Additionally, this role grants the ability to manage support tickets and
monitor service health. More information at About Office 365 admin roles.
NOTE
In Microsoft Graph API, Azure AD Graph API and Azure AD PowerShell, this role is identified as "Lync Service
Administrator". It is "Skype for Business Service Administrator" in the Azure portal.
User Account Administrator: Users with this role can create and manage all aspects of users and
groups. Additionally, this role includes the ability to manage support tickets and monitors service health.
Some restrictions apply. For example, this role does not allow deleting a global administrator, and while it
does allow changing passwords for non-admins, it does not allow changing passwords for global
administrators or other privileged administrators.
Administrator permissions
Billing administrator
CAN DO CANNOT DO
View company and user information Reset user passwords

Manage Office support tickets Create and manage user views
Perform billing and purchasing operations for Office Create, edit, and delete users and groups, and manage
products user licenses
Manage domains
Manage company information
Delegate administrative roles to others
Use directory synchronization
View audit logs
Conditional Access administrator

CAN DO CANNOT DO
CAN DO CANNOT DO

Manage conditional access settings Create and manage user views
Create, edit, and delete users and groups, and manage
user licenses
Manage domains
View audit logs
Global administrator
CAN DO CANNOT DO
View company and user information N/A

Manage Office support tickets
Perform billing and purchasing operations for Office
products
Reset user passwords
Reset other administrator’s passwords
Create and manage user views
user licenses
Manage domains
Enable or disable multi-factor authentication
View audit logs
Password administrator
CAN DO CANNOT DO
CAN DO CANNOT DO
View company and user information Perform billing and purchasing operations for Office
products
Reset user passwords
Reset other administrator’s passwords user licenses
Manage domains
View reports
Service administrator
CAN DO CANNOT DO

Manage Office support tickets Perform billing and purchasing operations for Office
products
user licenses
Manage domains
View audit logs
User administrator
CAN DO CANNOT DO
View company and user information Perform billing and purchasing operations for Office
products
Manage domains
Reset user passwords, with limitations.
Reset other administrator’s passwords
Reset other users' passwords
Enable or disable multi-factor authentication
user licenses, with limitations. He or she cannot delete a View audit logs
global administrator or create other administrators.
Security Reader
IN CAN DO
Identity Protection Center Read all security reports and settings information for security
features
Anti-spam
Encryption
Data loss prevention
Anti-malware
Advanced threat protection
Anti-phishing
Mailflow rules
Privileged Identity Management Has read-only access to all information surfaced in Azure
AD PIM: Policies and reports for Azure AD role
assignments, security reviews and in the future read
access to policy data and reports for scenarios besides
Azure AD role assignment.
Cannot sign up for Azure AD PIM or make any changes
to it. In PIM's portal or via PowerShell, someone in this
role can activate additional roles (for example, Global
Admin or Privileged Role Administrator), if the user is a
candidate for them.
Monitor Office 365 Service Health Read and manage alerts

Read security policies
Office 365 Security & Compliance Center
Read threat intelligence, Cloud App Discovery, and
Quarantine in Search and Investigate
Read all reports
Security Administrator
IN CAN DO
Identity Protection Center All permissions of the Security Reader role.

Additionally, the ability to perform all IPC operations
except for resetting passwords.
Privileged Identity Management All permissions of the Security Reader role.

Cannot manage Azure AD role memberships or
settings.
Monitor Office 365 Service Health All permissions of the Security Reader role.
Can configure all settings in the Advanced Threat
Office 365 Security & Compliance Center Protection feature (malware & virus protection,
malicious URL config, URL tracing, etc.).
Details about the global administrator role

The global administrator has access to all administrative features. By default, the person who signs up for an
Azure subscription is assigned the global administrator role for the directory. Only global administrators can
assign other administrator roles.
To add a colleague as a global administrator
1. Sign in to the Azure Active Directory Admin Center with an account that's a global admin for the tenant
directory.
2. Select Users and groups > All users

3. Find the user you want to designate as a global administrator and open the blade for that user.
4. On the user blade, select Directory role.
5. On the directory role blade, select the Global administrator role, and save.
Assign or remove administrator roles

To learn how to assign administrative roles to a user in Azure Active Directory, see Assign a user to
administrator roles in Azure Active Directory preview.
Deprecated roles
The following roles should not be used. They been deprecated and will be removed from Azure AD in the future.
AdHoc License Administrator
Email Verified User Creator
Device Join
Device Managers
Device Users
Workplace Device Join
Next steps
To learn more about how to change administrators for an Azure subscription, see How to add or change
Azure administrator roles
To learn more about how resource access is controlled in Microsoft Azure, see Understanding resource
access in Azure
For more information on how Azure Active Directory relates to your Azure subscription, see How Azure
subscriptions are associated with Azure Active Directory
Manage users
Manage passwords
Manage groups
Assign a user to administrator roles in Azure Active
Directory
This article explains how to assign an administrative role to a user in Azure Active Directory (Azure AD). For
information about adding new users in your organization, see Add new users to Azure Active Directory. Added
users don't have administrator permissions by default, but you can assign roles to them at any time.
Assign a role to a user


5. For the selected user, select Directory role and then assign the user to a role from the Directory role list.
For more information about user and administrator roles, see Assigning administrator roles in Azure AD.
6. Select Save.
Next steps
Quickstart: Add or delete users in Azure Active Directory
Administrative units management in Azure AD -
public preview
This article describes administrative units – a new Azure Active Directory container of resources that can be used
for delegating administrative permissions over subsets of users and applying policies to a subset of users. In Azure
Active Directory, administrative units enable central administrators to delegate permissions to regional
administrators or to set policy at a granular level.
This is useful in organizations with independent divisions, for example, a large university that is made up of many
autonomous schools (Business school, Engineering school, and so on) which are independent from each other.
Such divisions have their own IT administrators who control access, manage users, and set policies specifically for
their division. Central administrators want to be able grant these divisional administrators permissions over the
users in their particular divisions. More specifically, using this example, a central administrator can, for instance,
create an administrative unit for a particular school (Business school) and populate it with only the Business school
users. Then a central administrator can add the Business school IT staff to a scoped role, in other words, grant the IT
staff of Business school administrative permissions only over the Business school administrative unit.
IMPORTANT
You can assign administrative unit-scoped admin roles only if you enable Azure Active Directory Premium. For more
information, see Getting started with Azure AD Premium.
From the central administrator’s point of view, an administrative unit is a directory object that can be created and
populated with resources. In this preview release, these resources can be only users. Once created and
populated, the administrative unit can be used as a scope to restrict the granted permission only over resources
contained in the administrative unit.
Managing administrative units

In this preview release, you can create and manage administrative units using the Azure Active Directory Module
for Windows PowerShell cmdlets. To learn more about how to do that, see Working with Administrative Units
For more information on software requirements and installing the Azure AD module, and for information on the
Azure AD Module cmdlets for managing administrative units, including syntax, parameter descriptions, and
examples, see Azure Active Directory PowerShell.
Next steps
Azure Active Directory editions
Configurable token lifetimes in Azure Active Directory
(Public Preview)
You can specify the lifetime of a token issued by Azure Active Directory (Azure AD). You can set token lifetimes for all
apps in your organization, for a multi-tenant (multi-organization) application, or for a specific service principal in your
organization.
NOTE
This capability currently is in Public Preview. Be prepared to revert or remove any changes. The feature is available in any Azure
Active Directory subscription during Public Preview. However, when the feature becomes generally available, some aspects of the
feature might require an Azure Active Directory Premium subscription.
In Azure AD, a policy object represents a set of rules that are enforced on individual applications or on all applications in
an organization. Each policy type has a unique structure, with a set of properties that are applied to objects to which
they are assigned.
You can designate a policy as the default policy for your organization. The policy is applied to any application in the
organization, as long as it is not overridden by a policy with a higher priority. You also can assign a policy to specific
applications. The order of priority varies by policy type.
Token types
You can set token lifetime policies for refresh tokens, access tokens, session tokens, and ID tokens.
Access tokens
Clients use access tokens to access a protected resource. An access token can be used only for a specific combination of
user, client, and resource. Access tokens cannot be revoked and are valid until their expiry. A malicious actor that has
obtained an access token can use it for extent of its lifetime. Adjusting the lifetime of an access token is a trade-off
between improving system performance and increasing the amount of time that the client retains access after the
user’s account is disabled. Improved system performance is achieved by reducing the number of times a client needs to
acquire a fresh access token.
Refresh tokens
When a client acquires an access token to access a protected resource, the client receives both a refresh token and an
access token. The refresh token is used to obtain new access/refresh token pairs when the current access token expires.
A refresh token is bound to a combination of user and client. A refresh token can be revoked, and the token's validity is
checked every time the token is used.
It's important to make a distinction between confidential clients and public clients. For more information about different
types of clients, see RFC 6749.
Token lifetimes with confidential client refresh tokens
Confidential clients are applications that can securely store a client password (secret). They can prove that requests are
coming from the client application and not from a malicious actor. For example, a web app is a confidential client
because it can store a client secret on the web server. It is not exposed. Because these flows are more secure, the default
lifetimes of refresh tokens issued to these flows is until-revoked , cannot be changed by using policy, and will not be
revoked on voluntary password resets.
Token lifetimes with public client refresh tokens
Public clients cannot securely store a client password (secret). For example, an iOS/Android app cannot obfuscate a
secret from the resource owner, so it is considered a public client. You can set policies on resources to prevent refresh
tokens from public clients older than a specified period from obtaining a new access/refresh token pair. (To do this, use
the Refresh Token Max Inactive Time property.) You also can use policies to set a period beyond which the refresh
tokens are no longer accepted. (To do this, use the Refresh Token Max Age property.) You can adjust the lifetime of a
refresh token to control when and how often the user is required to reenter credentials, instead of being silently
reauthenticated, when using a public client application.
ID tokens
ID tokens are passed to websites and native clients. ID tokens contain profile information about a user. An ID token is
bound to a specific combination of user and client. ID tokens are considered valid until their expiry. Usually, a web
application matches a user’s session lifetime in the application to the lifetime of the ID token issued for the user. You
can adjust the lifetime of an ID token to control how often the web application expires the application session, and how
often it requires the user to be reauthenticated with Azure AD (either silently or interactively).
Single sign-on session tokens
When a user authenticates with Azure AD, a single sign-on session (SSO) is established with the user’s browser and
Azure AD. The SSO token, in the form of a cookie, represents this session. Note that the SSO session token is not bound
to a specific resource/client application. SSO session tokens can be revoked, and their validity is checked every time
they are used.
Azure AD uses two kinds of SSO session tokens: persistent and nonpersistent. Persistent session tokens are stored as
persistent cookies by the browser. Nonpersistent session tokens are stored as session cookies. (Session cookies are
destroyed when the browser is closed.) Usually, a nonpersistent session token is stored. But, when the user selects the
Keep me signed in check box during authentication, a persistent session token is stored.
Nonpersistent session tokens have a lifetime of 24 hours. Persistent tokens have a lifetime of 180 days. Any time an
SSO session token is used within its validity period, the validity period is extended another 24 hours or 180 days,
depending on the token type. If an SSO session token is not used within its validity period, it is considered expired and
is no longer accepted.
You can use a policy to set the time after the first session token was issued beyond which the session token is no longer
accepted. (To do this, use the Session Token Max Age property.) You can adjust the lifetime of a session token to control
when and how often a user is required to reenter credentials, instead of being silently authenticated, when using a web
application.
Token lifetime policy properties
A token lifetime policy is a type of policy object that contains token lifetime rules. Use the properties of the policy to
control specified token lifetimes. If no policy is set, the system enforces the default lifetime value.
Configurable token lifetime properties
POLICY PROPERTY
PROPERTY STRING AFFECTS DEFAULT MINIMUM MAXIMUM
Access Token AccessTokenLifeti Access tokens, ID 1 hour 10 minutes 1 day

Lifetime me tokens, SAML2
tokens
Refresh Token MaxInactiveTime Refresh tokens 14 days 10 minutes 90 days

Max Inactive Time
Single-Factor MaxAgeSingleFact Refresh tokens Until-revoked 10 minutes Until-revoked1

Refresh Token or (for any users)
Max Age
Multi-Factor MaxAgeMultiFact Refresh tokens Until-revoked 10 minutes Until-revoked1

Refresh Token or (for any users)
Max Age
POLICY PROPERTY
PROPERTY STRING AFFECTS DEFAULT MINIMUM MAXIMUM
Single-Factor MaxAgeSessionSin Session tokens Until-revoked 10 minutes Until-revoked1

Session Token gleFactor2 (persistent and
Max Age nonpersistent)
Multi-Factor MaxAgeSessionM Session tokens Until-revoked 10 minutes Until-revoked1

Session Token ultiFactor3 (persistent and
Max Age nonpersistent)
1365 days is the maximum explicit length that can be set for these attributes.
2If MaxAgeSessionSingleFactor is not set, this value takes the MaxAgeSingleFactor value. If neither parameter is
set, the property takes the default value (until-revoked).
3If MaxAgeSessionMultiFactor is not set, this value takes the MaxAgeMultiFactor value. If neither parameter is
set, the property takes the default value (until-revoked).

Exceptions
PROPERTY AFFECTS DEFAULT
Refresh Token Max Age (issued for Refresh tokens (issued for federated users 12 hours
federated users who have insufficient who have insufficient revocation
revocation information1 ) information1 )
Refresh Token Max Inactive Time (issued Refresh tokens (issued for confidential 90 days
for confidential clients) clients)
Refresh Token Max Age (issued for Refresh tokens (issued for confidential Until-revoked
confidential clients) clients)
1Federated users who have insufficient revocation information include any users who do not have the
"LastPasswordChangeTimestamp" attribute synced. These users are given this short Max Age because AAD is unable
to verify when to revoke tokens that are tied to an old credential (such as a password that has been changed) and
must check back in more frequently to ensure that the user and associated tokens are still in good standing. To
improve this experience, tenant admins must ensure that they are syncing the “LastPasswordChangeTimestamp”
attribute (this can be set on the user object using Powershell or through AADSync).
Policy evaluation and prioritization
You can create and then assign a token lifetime policy to a specific application, to your organization, and to service
principals. Multiple policies might apply to a specific application. The token lifetime policy that takes effect follows these
rules:
If a policy is explicitly assigned to the service principal, it is enforced.
If no policy is explicitly assigned to the service principal, a policy explicitly assigned to the parent organization of the
service principal is enforced.
If no policy is explicitly assigned to the service principal or to the organization, the policy assigned to the application
is enforced.
If no policy has been assigned to the service principal, the organization, or the application object, the default values
is enforced. (See the table in Configurable token lifetime properties.)
For more information about the relationship between application objects and service principal objects, see Application
and service principal objects in Azure Active Directory.
A token’s validity is evaluated at the time the token is used. The policy with the highest priority on the application that is
being accessed takes effect.
NOTE
Here's an example scenario.
A user wants to access two web applications: Web Application A and Web Application B.
Factors:
Both web applications are in the same parent organization.
Token Lifetime Policy 1 with a Session Token Max Age of eight hours is set as the parent organization’s default.
Web Application A is a regular-use web application and isn’t linked to any policies.
Web Application B is used for highly sensitive processes. Its service principal is linked to Token Lifetime Policy 2, which has a
Session Token Max Age of 30 minutes.
At 12:00 PM, the user starts a new browser session and tries to access Web Application A. The user is redirected to Azure AD and
is asked to sign in. This creates a cookie that has a session token in the browser. The user is redirected back to Web Application A
with an ID token that allows the user to access the application.
At 12:15 PM, the user tries to access Web Application B. The browser redirects to Azure AD, which detects the session cookie.
Web Application B’s service principal is linked to Token Lifetime Policy 2, but it's also part of the parent organization, with default
Token Lifetime Policy 1. Token Lifetime Policy 2 takes effect because policies linked to service principals have a higher priority than
organization default policies. The session token was originally issued within the last 30 minutes, so it is considered valid. The user
is redirected back to Web Application B with an ID token that grants them access.
At 1:00 PM, the user tries to access Web Application A. The user is redirected to Azure AD. Web Application A is not linked to any
policies, but because it is in an organization with default Token Lifetime Policy 1, that policy takes effect. The session cookie that
was originally issued within the last eight hours is detected. The user is silently redirected back to Web Application A with a new ID
token. The user is not required to authenticate.
Immediately afterward, the user tries to access Web Application B. The user is redirected to Azure AD. As before, Token Lifetime
Policy 2 takes effect. Because the token was issued more than 30 minutes ago, the user is prompted to reenter their sign-in
credentials. A brand-new session token and ID token are issued. The user can then access Web Application B.
Configurable policy property details

Access Token Lifetime
String: AccessTokenLifetime
Affects: Access tokens, ID tokens
Summary: This policy controls how long access and ID tokens for this resource are considered valid. Reducing the
Access Token Lifetime property mitigates the risk of an access token or ID token being used by a malicious actor for an
extended period of time. (These tokens cannot be revoked.) The trade-off is that performance is adversely affected,
because the tokens have to be replaced more often.
Refresh Token Max Inactive Time
String: MaxInactiveTime
Affects: Refresh tokens
Summary: This policy controls how old a refresh token can be before a client can no longer use it to retrieve a new
access/refresh token pair when attempting to access this resource. Because a new refresh token usually is returned
when a refresh token is used, this policy prevents access if the client tries to access any resource by using the current
refresh token during the specified period of time.
This policy forces users who have not been active on their client to reauthenticate to retrieve a new refresh token.
The Refresh Token Max Inactive Time property must be set to a lower value than the Single-Factor Token Max Age and
the Multi-Factor Refresh Token Max Age properties.
Single-Factor Refresh Token Max Age
String: MaxAgeSingleFactor
Summary: This policy controls how long a user can use a refresh token to get a new access/refresh token pair after
they last authenticated successfully by using only a single factor. After a user authenticates and receives a new refresh
token, the user can use the refresh token flow for the specified period of time. (This is true as long as the current refresh
token is not revoked, and it is not left unused for longer than the inactive time.) At that point, the user is forced to
reauthenticate to receive a new refresh token.
Reducing the max age forces users to authenticate more often. Because single-factor authentication is considered less
secure than multi-factor authentication, we recommend that you set this property to a value that is equal to or lesser
than the Multi-Factor Refresh Token Max Age property.
Multi-Factor Refresh Token Max Age
String: MaxAgeMultiFactor
Summary: This policy controls how long a user can use a refresh token to get a new access/refresh token pair after
they last authenticated successfully by using multiple factors. After a user authenticates and receives a new refresh
token, the user can use the refresh token flow for the specified period of time. (This is true as long as the current refresh
token is not revoked, and it is not unused for longer than the inactive time.) At that point, users are forced to
reauthenticate to receive a new refresh token.
secure than multi-factor authentication, we recommend that you set this property to a value that is equal to or greater
than the Single-Factor Refresh Token Max Age property.
Single-Factor Session Token Max Age
String: MaxAgeSessionSingleFactor
Affects: Session tokens (persistent and nonpersistent)
Summary: This policy controls how long a user can use a session token to get a new ID and session token after they
last authenticated successfully by using only a single factor. After a user authenticates and receives a new session token,
the user can use the session token flow for the specified period of time. (This is true as long as the current session token
is not revoked and has not expired.) After the specified period of time, the user is forced to reauthenticate to receive a
new session token.
secure than multi-factor authentication, we recommend that you set this property to a value that is equal to or less than
the Multi-Factor Session Token Max Age property.
Multi-Factor Session Token Max Age
String: MaxAgeSessionMultiFactor
Affects: Session tokens (persistent and nonpersistent)
Summary: This policy controls how long a user can use a session token to get a new ID and session token after the last
time they authenticated successfully by using multiple factors. After a user authenticates and receives a new session
token, the user can use the session token flow for the specified period of time. (This is true as long as the current
session token is not revoked and has not expired.) After the specified period of time, the user is forced to reauthenticate
to receive a new session token.
secure than multi-factor authentication, we recommend that you set this property to a value that is equal to or greater
than the Single-Factor Session Token Max Age property.
Example token lifetime policies
Many scenarios are possible in Azure AD when you can create and manage token lifetimes for apps, service principals,
and your overall organization. In this section, we walk through a few common policy scenarios that can help you
impose new rules for:
Token Lifetime
Token Max Inactive Time
Token Max Age
In the examples, you can learn how to:
Manage an organization's default policy
Create a policy for web sign-in
Create a policy for a native app that calls a web API
Manage an advanced policy
Prerequisites
In the following examples, you create, update, link, and delete policies for apps, service principals, and your overall
organization. If you are new to Azure AD, we recommend that you learn about how to get an Azure AD tenant before
you proceed with these examples.
To get started, do the following steps:
1. Download the latest Azure AD PowerShell Module Public Preview release.
2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a
new session.
3. To see all policies that have been created in your organization, run the following command. Run this command
after most operations in the following scenarios. Running the command also helps you get the ** ** of your
policies.
Get-AzureADPolicy
Example: Manage an organization's default policy

In this example, you create a policy that lets your users sign in less frequently across your entire organization. To do
this, create a token lifetime policy for Single-Factor Refresh Tokens, which is applied across your organization. The
policy is applied to every application in your organization, and to each service principal that doesn’t already have a
policy set.
1. Create a token lifetime policy.
a. Set the Single-Factor Refresh Token to "until-revoked." The token doesn't expire until access is revoked.
Create the following policy definition:
@('{
"TokenLifetimePolicy":
{
"Version":1,
"MaxAgeSingleFactor":"until-revoked"
}
}')
b. To create the policy, run the following command:

New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSingleFactor":"until-
revoked"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type
"TokenLifetimePolicy"
c. To see your new policy, and to get the policy's ObjectId, run the following command:
Get-AzureADPolicy
2. Update the policy.

You might decide that the first policy you set in this example is not as strict as your service requires. To set your
Single-Factor Refresh Token to expire in two days, run the following command:
Set-AzureADPolicy -Id <ObjectId FROM GET COMMAND> -DisplayName "OrganizationDefaultPolicyUpdatedScenario" -

Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"2.00:00:00"}}')
Example: Create a policy for web sign-in

In this example, you create a policy that requires users to authenticate more frequently in your web app. This policy sets
the lifetime of the access/ID tokens and the max age of a multi-factor session token to the service principal of your web
app.
This policy, for web sign-in, sets the access/ID token lifetime and the max single-factor session token age to two
hours.
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":

{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName
"WebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Get-AzureADPolicy
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of

the Policy>
Example: Create a policy for a native app that calls a web API
In this example, you create a policy that requires users to authenticate less frequently. The policy also lengthens the
amount of time a user can be inactive before the user must reauthenticate. The policy is applied to the web API. When
the native app requests the web API as a resource, this policy is applied.
a. To create a strict policy for a web API, run the following command:
{"Version":1,"MaxInactiveTime":"30.00:00:00","MaxAgeMultiFactor":"until-
revoked","MaxAgeSingleFactor":"180.00:00:00"}}') -DisplayName "WebApiDefaultPolicyScenario" -
IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Get-AzureADPolicy
2. Assign the policy to your web API. You also need to get the ObjectId of your application. The best way to find
your app's ObjectId is to use the Azure portal.
When you have the ObjectId of your app, run the following command:
```PowerShell
Add-AzureADApplicationPolicy -Id <ObjectId of the Application> -RefObjectId <ObjectId of the Policy>
```
Example: Manage an advanced policy

In this example, you create a few policies, to learn how the priority system works. You also can learn how to manage
multiple policies that are applied to several objects.
a. To create an organization default policy that sets the Single-Factor Refresh Token lifetime to 30 days, run
the following command:

{"Version":1,"MaxAgeSingleFactor":"30.00:00:00"}}') -DisplayName "ComplexPolicyScenario" -
IsOrganizationDefault $true -Type "TokenLifetimePolicy"
b. To see your new policy, and to get the policy's ObjectId, run the following command:
Get-AzureADPolicy
2. Assign the policy to a service principal.

Now, you have a policy that applies to the entire organization. You might want to preserve this 30-day policy for
a specific service principal, but change the organization default policy to the upper limit of "until-revoked."
Explorer, sign in by using your Azure AD account.
```PowerShell
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of
the Policy>
```
3. Set the IsOrganizationDefault flag to false:
Set-AzureADPolicy -Id <ObjectId of Policy> -DisplayName "ComplexPolicyScenario" -IsOrganizationDefault

$false
4. Create a new organization default policy:
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSingleFactor":"until-

revoked"}}') -DisplayName "ComplexPolicyScenarioTwo" -IsOrganizationDefault $true -Type
"TokenLifetimePolicy"
You now have the original policy linked to your service principal, and the new policy is set as your organization
default policy. It's important to remember that policies applied to service principals have priority over
organization default policies.
Cmdlet reference
Manage policies
You can use the following cmdlets to manage policies.
New-AzureADPolicy
Creates a new policy.
New-AzureADPolicy -Definition <Array of Rules> -DisplayName <Name of Policy> -IsOrganizationDefault <boolean> -Type
<Policy Type>
PARAMETERS DESCRIPTION EXAMPLE
Definition Array of stringified JSON that contains all -Definition @('{"TokenLifetimePolicy":

the policy's rules. {"Version":1,"MaxInactiveTime":"20:00:00"}}')
DisplayName String of the policy name. -DisplayName "MyTokenPolicy"
IsOrganizationDefault If true, sets the policy as the -IsOrganizationDefault $true

organization's default policy. If false, does
nothing.
Type Type of policy. For token lifetimes, always -Type "TokenLifetimePolicy"

use "TokenLifetimePolicy."
AlternativeIdentifier [Optional] Sets an alternative ID for the policy. -AlternativeIdentifier "myAltId"
Get-AzureADPolicy
Gets all Azure AD policies or a specified policy.
Get-AzureADPolicy
Id [Optional] ObjectId (Id) of the policy you want. -Id <ObjectId of Policy>
Get-AzureADPolicyAppliedObject
Gets all apps and service principals that are linked to a policy.
Get-AzureADPolicyAppliedObject -Id <ObjectId of Policy>

Id ObjectId (Id) of the policy you want. -Id <ObjectId of Policy>
Set-AzureADPolicy
Updates an existing policy.
Set-AzureADPolicy -Id <ObjectId of Policy> -DisplayName <string>
DisplayName String of the policy name. -DisplayName "MyTokenPolicy"
Definition [Optional] Array of stringified JSON that contains all -Definition @('{"TokenLifetimePolicy":
the policy's rules. {"Version":1,"MaxInactiveTime":"20:00:00"}}')
IsOrganizationDefault [Optional] If true, sets the policy as the -IsOrganizationDefault $true

organization's default policy. If false, does
nothing.
Type [Optional] Type of policy. For token lifetimes, always -Type "TokenLifetimePolicy"
use "TokenLifetimePolicy."
AlternativeIdentifier [Optional] Sets an alternative ID for the policy. -AlternativeIdentifier "myAltId"
Remove-AzureADPolicy
Deletes the specified policy.
Remove-AzureADPolicy -Id <ObjectId of Policy>
Application policies
You can use the following cmdlets for application policies.
Add-AzureADApplicationPolicy
Links the specified policy to an application.
Add-AzureADApplicationPolicy -Id <ObjectId of Application> -RefObjectId <ObjectId of Policy>
Id ObjectId (Id) of the application. -Id <ObjectId of Application>

RefObjectId ObjectId of the policy. -RefObjectId <ObjectId of Policy>
Get-AzureADApplicationPolicy
Gets the policy that is assigned to an application.
Get-AzureADApplicationPolicy -Id <ObjectId of Application>
Remove-AzureADApplicationPolicy
Removes a policy from an application.
Remove-AzureADApplicationPolicy -Id <ObjectId of Application> -PolicyId <ObjectId of Policy>
PolicyId ObjectId of the policy. -PolicyId <ObjectId of Policy>
Service principal policies

You can use the following cmdlets for service principal policies.
Add-AzureADServicePrincipalPolicy
Links the specified policy to a service principal.
Add-AzureADServicePrincipalPolicy -Id <ObjectId of ServicePrincipal> -RefObjectId <ObjectId of Policy>
RefObjectId ObjectId of the policy. -RefObjectId <ObjectId of Policy>
Get-AzureADServicePrincipalPolicy
Gets any policy linked to the specified service principal.
Get-AzureADServicePrincipalPolicy -Id <ObjectId of ServicePrincipal>

Remove-AzureADServicePrincipalPolicy
Removes the policy from the specified service principal.
Remove-AzureADServicePrincipalPolicy -Id <ObjectId of ServicePrincipal> -PolicyId <ObjectId of Policy>
PolicyId ObjectId of the policy. -PolicyId <ObjectId of Policy>

Manage emergency-access administrative accounts in
Azure AD
For most day-to-day activities, global administrator rights are not needed by your users. Users should not be
permanently assigned to the role, because they might inadvertently perform a task that requires higher
permissions than they should have. When users don't need to act as a global administrator, they should activate the
role assignment by using Azure Active Directory (Azure AD) Privileged Identity Management (PIM), on either their
own account or an alternate administrative account.
In addition to users' taking on administrative access rights for themselves, you need to prevent being inadvertently
locked out of the administration of your Azure AD tenant because you can neither sign in nor activate an existing
individual user's account as an administrator. You can mitigate the impact of inadvertent lack of administrative
access by storing two or more emergency access accounts in your tenant.
Emergency access accounts can help organizations restrict privileged access within an existing Azure Active
Directory environment. Such accounts are highly privileged, and they are not assigned to specific individuals.
Emergency access accounts are limited to emergency or 'break glass' scenarios, situations where normal
administrative accounts cannot be used. Organizations must maintain a goal of restricting the emergency account's
usage to only that time during which it is necessary.
An organization might need to use an emergency access account in the following situations:
The user accounts are federated, and federation is currently unavailable because of a cell-network break or an
identity-provider outage. For example, if the identity provider host in your environment has gone down, users
might be unable to sign in when Azure AD redirects to their identity provider.
The administrators are registered through Azure Multi-Factor Authentication, and all their individual devices are
unavailable. Users might be unable to complete Multi-Factor Authentication to activate a role. For example, a cell
network outage is preventing them from answering phone calls or receiving text messages, the only two
authentication mechanisms that they registered for their device.
The person with the most recent global administrative access has left the organization. Azure AD prevents the
last global administrator account from being deleted, but it does not prevent the account from being deleted or
disabled on-premises. Either situation might make the organization unable to recover the account.
Initial configuration
Create two or more emergency access accounts. These should be cloud-only accounts that use the
*.onmicrosoft.com domain and that are not federated or synchronized from an on-premises environment.
The accounts should not be associated with any individual user in the organization. Organizations need to ensure
that the credentials for these accounts are kept secure and known only to individuals who are authorized to use
them.
NOTE
An account password for an emergency access account is usually separated into two or three parts, written on separate
pieces of paper, and stored in secure, fireproof safes that are in secure, separate locations.
Make sure that your emergency access accounts are not connected with any employee-supplied mobile phones, hardware
tokens that travel with individual employees, or other employee-specific credentials. This precaution covers instances where
an individual employee is unreachable when the credential is needed.
Initial configuration with permanent assignments

One option is to make users permanent members of the global administrator role. This option would be
appropriate for organizations that do not have Azure AD Premium P2 subscriptions.
To reduce the risk of an attack resulting from a compromised password, Azure AD recommends that you require
Multi-Factor Authentication for all individual users. This group should include administrators and all others (for
example, financial officers) whose compromised account would have a significant impact.
However, if your organization does not have shared devices, Multi-Factor Authentication might not be possible for
these emergency access accounts. If you are configuring a conditional access policy to require Multi-Factor
Authentication registration for every admin for Azure AD and other connected software as a service (SaaS) apps,
you might need to configure policy exclusions to exclude emergency access accounts from this requirement.
Initial configuration with approvals
Another option is to configure your users as eligible and approvers to activate the global administrator role. This
option would require your organization to have Azure AD Premium P2 subscriptions. It would also require a Multi-
Factor Authentication option that's suitable for shared use among multiple individuals and the network
environment. These requirements are because activation of the global administrator role requires users to have
previously performed Multi-Factor Authentication. For more information, see How to require Multi-Factor
Authentication in Azure AD Privileged Identity Management.
We do not recommend using Multi-Factor Authentication that's associated with personal devices for emergency
access accounts. In an actual emergency, the person who needs access to a Multi-Factor Authentication-registered
device might not be the one who has the personal device.
Also consider the threat landscape. For example, an unforeseen circumstance such as a natural disaster emergency
might arise, during which a mobile phone or other networks might be unavailable. It is important to ensure that
any registered devices are kept in a known, secure location that has multiple means of communicating with Azure
AD.
Ongoing monitoring
Monitor the Azure AD sign-in and audit logs for any sign-ins and audit activity from the emergency-access
accounts. Normally those accounts should not be signing in and should not be making changes, so use of them is
likely to be anomalous and require security investigation.
Account-check validation must occur at regular intervals

To validate the account, perform the following steps at minimum:
Every 90 days.
When there has been a recent change in IT staff, such as a job change, a departure, or a new hire.
When the Azure AD subscriptions in the organization have changed.
To train staff members to use emergency access accounts, do the following:
Ensure that security-monitoring staff are aware that the account-check activity is ongoing.
Validate that the cloud user accounts can sign in and activate their roles, and that users who might need to
perform these steps during an emergency are trained on the process.
Ensure that they have not registered Multi-Factor Authentication or self-service password reset (SSPR) to any
individual user’s device or personal details.
If the accounts are registered for Multi-Factor Authentication to a device, for use during role activation, ensure
that the device is accessible to all administrators who might need to use it during an emergency. Also verify that
the device is registered through at least two mechanisms that do not share a common failure mode. For
example, the device can communicate to the internet through both a facility's wireless network and a cell
provider network.
Update the account credentials.
Next steps
Add a cloud-based user and assign the new user to the global administrator role.
Sign up for Azure Active Directory Premium, if you haven’t signed up already.
Require Azure Multi-Factor Authentication for individual users assigned as administrators.
Configure additional protections for global administrators in Office 365, if you are using Office 365.
Perform an access review of global administrators and transition existing global administrators to more specific
administrator roles.
Azure AD access reviews (preview)
Azure Active Directory (Azure AD) access reviews enable organizations to efficiently manage group memberships
and access to enterprise applications.
What can you do with access reviews?

You can recertify guest user access by using access reviews of their access to applications and memberships
of groups. Reviewers can use the insights that are provided to efficiently decide whether guests should have
continued access.
You can recertify employee access to applications and group memberships with access reviews.
You can collect access review controls into programs that are relevant for your organization to track reviews
for compliance or risk-sensitive applications.
Next steps
Manage user access with Azure AD access reviews
Manage guest access with Azure AD access reviews
Manage programs and controls for Azure AD access reviews
Create an access review for members of a group or access to an application
Create an access review of users in an Azure AD administrative role
Complete an access review of members of a group or
users' access to an application in Azure AD
Administrators can use Azure Active Directory (Azure AD) to create an access review for group members or users
assigned to an application. Azure AD automatically sends reviewers an email that prompts them to review access.
If a user didn't get an email, you can send them the instructions in Review your access. After the access review
period is over or if an administrator stops the access review, follow the steps in this article to see and apply the
results.
View an access review in the Azure portal

1. Go to the access reviews page, select Programs, and select the program that contains the access review
control.
2. Select Manage, and select the access review control. If there are many controls in the program, you can
filter for controls of a specific type and sort by their status. You also can search by the name of the access
review control or the display name of the owner who created it.
Stop a review that hasn't finished

If the review hasn't reached the scheduled end date, an administrator can select Stop to end the review early. After
you stop the review, users can no longer be reviewed. You can't restart a review after it's stopped.
Apply the changes

After an access review is finished, either because it reached the end date or an administrator stopped it manually,
select Apply. The outcome of the review is implemented by updating the group or application. If a user's access
was denied in the review, when an administrator selects this option, Azure AD removes their membership or
application assignment.
Selecting Apply doesn't have an effect on a group that originates in an on-premises directory or a dynamic group.
If you want to change a group that originates on-premises, download the results and apply those changes to the
representation of the group in that directory.
Download the results of the review

To retrieve the results of the review, select Approvals and then select Download. The resulting CSV file can be
viewed in Excel or in other programs that open CSV files.
Optional: Delete a review

If you're no longer interested in the review, you can delete it. Select Delete to remove the review from Azure AD.
IMPORTANT
There's no warning before deletion occurs, so be sure that you want to delete the review.
Next steps
Manage programs and controls for Azure AD access reviews
Create an access review of users in an Azure AD administrative role
Create an access review of group members or
application access with Azure AD
Access assignments become "stale" when users have access they don't need any more. To reduce the risk
associated with stale access assignments, administrators can use Azure Active Directory (Azure AD) to create an
access review for group members or users assigned to an application. For more information on these scenarios,
see Manage user access and Manage guest access.
Create an access review

1. As a global administrator, go to the access reviews page, and select Programs.
2. Select the program that holds the access review control you want to create. Default Program is always
present, or you can create a different program. For example, you can choose to have one program for each
compliance initiative or business goal.
3. Within the program, select Controls, and then select Add to add a control.
4. Name each access review. Optionally, give each review a description. The name is shown to the reviewers.
5. Set the start and end dates. By default, an access review starts the same day it's created, and it ends in one
month. You can change the start and end dates to have an access review start in the future and last
however many days you want.
6. Access reviews can be for the members of a group or for users who were assigned to an application. You
can further scope the access review to review only the guest users who are members (or assigned to the
app), rather than reviewing all the users who are members or who have access to the application.
7. Select either one or more people to review all the users in scope. Or you can select to have the members
review their own access. If the resource is a group, you can ask the group owners to review. You also can
require that the reviewers supply a reason when they approve access.
8. Finally, select Start.
Manage the access review

By default, Azure AD sends an email to reviewers shortly after the review starts. If you choose not to have Azure
AD send the email, be sure to inform the reviewers that an access review is waiting for them to complete. You can
show them the instructions for how to review access. If your review is for guests to review their own access, show
them the instructions for how to review your own access.
If some of the reviewers are guests, guests are notified via email only if they've already accepted their invitation.
You can track the progress as the reviewers complete their reviews in the Azure AD dashboard in the Access
Reviews section. No access rights are changed in the directory until the review is completed.
Next steps
When an access review has started, Azure AD automatically sends reviewers an email that prompts them to
review access. If a user didn't get an email, you can send them the instructions for how to review access.
After the access review period is over or the administrator stops the access review, follow the steps in Complete
an access review to see and apply the results.
Review access with Azure AD access reviews
Azure Active Directory (Azure AD) simplifies how enterprises manage access to applications and members of
groups in Azure AD and other Microsoft Online Services with a feature called access reviews. Perhaps you
received an email from Microsoft that asks you to review access for members of a group or users with access to
an application.
Open an access review

To see the pending access reviews, select the link in the email. If you don't have the email, you can locate the
access reviews by following these steps:
1. Sign in on the Azure AD access panel.
2. Select the user symbol in the upper-right corner of the page, which displays your name and default
organization. If more than one organization is listed, select the organization that requested an access
review.
3. If a tile labeled Access reviews is on the right side of the page, select it. If the tile isn't visible, there are no
access reviews to perform for that organization and no action is needed at this time.
Fill out an access review

When you select an access review from the list, you see the names of users who need to be reviewed. You might
see only one name--your own--if the request was to review your own access.
For each row on the list, you can decide whether to approve or deny the user's access. Select the row, and choose
whether to approve or deny. (If you don't know the user, you can indicate that, too.)
The reviewer might require that you supply a justification for approving continued access or group membership.
Next steps
A user's denied access isn't removed immediately. It can be removed when the review is finished or when an
administrator stops the review. If you want to change your answer and approve a previously denied user or deny
a previously approved user, select the row, reset the response, and select a new response. You can do this step
until the access review is finished.
Review your access
Azure Active Directory (Azure AD) simplifies how enterprises manage access to applications and members of
groups in Azure AD and other Microsoft Online Services with a feature called access reviews. Perhaps you received
an email from Microsoft that asks you to review access for members of a group or users with access to an
application.
Open an access review

To see the pending access reviews, select the link in the email. If you don't have the email, you can locate the access
reviews by following these steps:
1. Sign in on the Azure AD access panel.
2. Select the user symbol in the upper-right corner of the page, which displays your name and default
organization. If more than one organization is listed, select the organization that requested an access review.
3. If a tile labeled Access reviews is on the right side of the page, select it. If the tile isn't visible, there are no
access reviews to perform for that organization and no action is needed at this time.
Fill out an access review

When you select an access review from the list, you can see your access. Select the row, and choose whether to
approve or deny your need for continued access.
The reviewer might require that you supply a justification for approving continued access.
Next steps
Denied access isn't removed immediately. If you want to change your answer and approve, reset the response and
select a new response. You can do this step until the access review is finished.
With Azure Active Directory (Azure AD), you can easily enable collaboration across organizational boundaries by
using the Azure AD B2B feature. Guest users from other tenants can be invited by administrators or by other users.
This capability also applies to social identities such as Microsoft accounts.
You also can easily ensure that guest users have appropriate access. You can ask the guests themselves or a
decision maker to participate in an access review and recertify (or attest) to the guests' access. The reviewers can
give their input on each user's need for continued access, based on suggestions from Azure AD. When an access
review is finished, you can then make changes and remove access for guests who no longer need it.
NOTE
This document focuses on reviewing guest users' access. If you want to review all users' access, not just guests, see Manage
user access with access reviews. If you want to review users' membership in administrative roles, such as global
administrator, see Start an access review in Azure AD Privileged Identity Management.
Prerequisites
Access reviews are available with the Premium P2 edition of Azure AD, which is included in Microsoft Enterprise
Mobility + Security, E5. For more information, see Azure Active Directory editions. Each user who interacts with
this feature to create a review, access a review, or apply a review requires a license.
If you plan to ask guest users to review their own access, read about guest user licensing. For more information,
see Azure AD B2B collaboration licensing.
Create and perform an access review for guests

First, enable access reviews to appear on a reviewer's access panels. As a global administrator, go to the access
reviews page.
Azure AD enables several scenarios for reviewing guest users.
Select one of the following:
A group in Azure AD that has one or more guests as members.
An application connected to Azure AD that has one or more guest users assigned to it.
You can then decide whether to ask each guest to review their own access or to ask one or more users to review
every guest's access.
These scenarios are covered in the following sections.
Ask guests to review their own membership in a group
You can use access reviews to ensure that users who were invited and added to a group continue to need access.
You can easily ask guests to review their own membership in that group.
1. To start an access review for the group, select the review to include guest user members only and that
members review themselves. For more information, see Create an access review.
2. Ask each guest to review their own membership. By default, each guest who accepted an invitation receives
an email from Azure AD with a link to the access review. Azure AD has instructions for guests on how to
review their access.
3. After the reviewers give input, stop the access review and apply the changes. For more information, see
Complete an access review.
4. In addition to users who denied their own need for continued access, you can also remove users who didn't
respond. Non-responding users potentially no longer receive email.
5. If the group isn't used for access management, you also can remove users who weren't selected to
participate in the review because they didn't accept their invitation. Not accepting might indicate that the
invited user's email address had a typo. If a group is used as a distribution list, perhaps some guest users
weren't selected to participate because they're contact objects.
Ask a sponsor to review a guest's membership in a group
You can ask a sponsor, such as the owner of a group, to review a guest's need for continued membership in a
group.
1. To start an access review for the group, select the review to include guest user members only. Then specify
one or more reviewers. For more information, see Create an access review.
2. Ask the reviewers to give input. By default, they each receive an email from Azure AD with a link to the
access panel, where they perform their access review.
Ask guests to review their own access to an application
You can use access reviews to ensure that users who were invited for a particular application continue to need
access. You can easily ask the guests themselves to review their own need for access.
1. To start an access review for the application, select the review to include guests only and that users review
their own access. For more information, see Create an access review.
2. Ask each guest to review their own access to the application. By default, each guest who accepted an
invitation receives an email from Azure AD with a link to the access review in your organization's access
panel. Azure AD has instructions for guests on how to review their access.
4. In addition to users who denied their own need for continued access, you also can remove guest users who
didn't respond. Non-responding users potentially no longer receive email. You also can remove guest users
who weren't selected to participate, especially if they weren't recently invited. Those users didn't accept
their invitation and so didn't have access to the application.
Ask a sponsor to review a guest's access to an application
You can ask a sponsor, such as the owner of an application, to review a guest's need for continued access to the
application.
1. To start an access review for the application, select the review to include guests only. Then specify one or
more users as reviewers. For more information, see Create an access review.
Ask guests to review their need for access, in general
In some organizations, guests might not be aware of their group memberships.
NOTE
Earlier versions of the Azure portal didn't permit administrative access by users with the UserType of Guest. In some cases,
an administrator in your directory might have changed a guest's UserType value to Member by using PowerShell. If this
change previously occurred in your directory, the previous query might not include all guest users who historically had
administrative access rights. In this case, you need to either change the guest's UserType or manually include the guest in
the group membership.
1. Create a security group in Azure AD with the guests as members, if a suitable group doesn't already exist.
For example, you can create a group with a manually maintained membership of guests. Or, you can create
a dynamic group with a name such as "Guests of Contoso" for users in the Contoso tenant who have the
UserType attribute value of Guest.
2. To start an access review for that group, select the reviewers to be the members themselves. For more
information, see Create an access review.
3. Ask each guest to review their own membership. By default, each guest who accepted an invitation receives
an email from Azure AD with a link to the access review in your organization's access panel. Azure AD has
instructions for guests on how to review their access.
4. After the reviewers give input, stop the access review. For more information, see Complete an access
review.
5. Remove guest access for guests who were denied, didn't complete the review, or didn't previously accept
their invitation. If some of the guests are contacts who were selected to participate in the review because
they didn't previously accept an invitation, you can disable their accounts by using the Azure portal or
PowerShell. If the guest no longer needs access and isn't a contact, you can remove their user object from
your directory by using the Azure portal or PowerShell.
Next steps
With Azure Active Directory (Azure AD), you can easily ensure that users have appropriate access. You can ask the
users themselves or a decision maker to participate in an access review and recertify (or attest) to users' access.
The reviewers can give their input on each user's need for continued access based on suggestions from Azure AD.
When an access review is finished, you can then make changes and remove access from users who no longer need
it.
NOTE
If you want to review only guest users' access and not review all types of users' access, see Manage guest user access with
access reviews. If you want to review users' membership in administrative roles such as global administrator, see Start an
access review in Azure AD Privileged Identity Management.
Prerequisites
Access reviews are available with the Premium P2 edition of Azure AD, which is included in Microsoft Enterprise
Mobility + Security, E5. For more information, see Azure Active Directory editions. Each user who interacts with
this feature to create a review, access a review, or apply a review requires a license.
Create and perform an access review

You can have one or more users as reviewers in an access review.
1. Select a group in Azure AD that has one or more members. Or select an application connected to Azure AD
that has one or more users assigned to it.
2. Decide whether to have each user review their own access or to have one or more users review everyone's
access.
3. Enable access reviews to appear on the reviewers' access panels. As a global administrator, go to the access
reviews page.
4. Start the access review. For more information, see Create an access review.
6. If the reviewers haven't given input, you can ask Azure AD to send them a reminder. By default, Azure AD
automatically sends a reminder halfway to the end date to reviewers who haven't yet responded.
Next steps
Manage programs and their controls
Azure Active Directory (Azure AD) includes access reviews of group members and application access. These
examples of controls ensure oversight for who has access to your organization's group memberships and
applications. Organizations can use these controls to efficiently address their governance, risk management, and
compliance requirements.
Create and manage programs and their controls

You can simplify how to track and collect access reviews for different purposes by organizing them into programs.
Each access review can be linked to a program. Then when you prepare reports for an auditor, only the access
reviews in scope for a particular initiative are visible.
To see a list of programs, go to the access reviews page and select Programs.
Default Program is always present. If you're in a global administrator role, you can create additional programs.
For example, you can choose to have one program for each compliance initiative or business goal.
If you no longer need a program and it doesn't have any controls linked to it, you can delete it.
Next steps
In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, apps, and
services from anywhere. With the proliferation of devices (including BYOD), work off corporate networks, and
3rd party SaaS apps, IT professionals are faced with two opposing goals:
Empower the end users to be productive wherever and whenever
Protect the corporate assets at any time
To improve productivity, Azure Active Directory provides your users with a broad range of options to access
your corporate assets. With application access management, Azure Active Directory enables you to ensure
that only the right people can access your applications. What if you want to have more control over how the
right people are accessing your resources under certain conditions? What if you even have conditions under
which you want to block access to certain apps even for the right people? For example, it might be OK for you
if the right people are accessing certain apps from a trusted network; however, you might not want them to
access these apps from a network you don't trust. You can address these questions using conditional access.
Conditional access is a capability of Azure Active Directory that enables you to enforce controls on the access
to apps in your environment based on specific conditions. With controls, you can either tie additional
requirements to the access or you can block it. The implementation of conditional access is based on policies.
A policy-based approach simplifies your configuration experience because it follows the way you think about
your access requirements.
Typically, you define your access requirements using statements that are based on the following pattern:
When you replace the two occurrences of “this” with real-world information, you have an example for a
policy statement that probably looks familiar to you:
When contractors are trying to access our cloud apps from networks that are not trusted, then block access.
The policy statement above highlights the power of conditional access. While you can enable contractors to
basically access your cloud apps (who), with conditional access, you can also define conditions under which
the access is possible (how).
In the context of Azure Active Directory conditional access,
"When this happens" is called condition statement
"Then do this" is called controls
The combination of a condition statement with your controls represents a conditional access policy.
Controls
In a conditional access policy, controls define what it is that should happen when a condition statement has
been satisfied.
With controls, you can either block access or allow access with additional requirements. When you configure
a policy that allows access, you need to select at least one requirement.
There are two types of controls:
Grant controls - Grant controls govern whether or not a user can complete authentication and reach
the resource that they’re attempting to sign-in to. If you have multiple controls selected, you can
configure whether all of them are required when your policy is processed. The current implementation
of Azure Active Directory enables you to configure the following grant control requirements:
Session controls - Session controls enable limiting experience within a cloud app. The session
controls are enforced by cloud apps and rely on additional information provided by Azure AD to the
app about the session.
For more information, see controls in Azure Active Directory Conditional Access.
Condition Statement
The previous section has introduced you to supported options to block or restrict access to your resources in
form of controls. In a conditional access policy, you define the criteria that need to be met for your controls to
be applied in form of a condition statement.
You can include the following assignments into your condition statement:
Who?
When you configure a conditional access policy, you need to select the users or groups your policy applies to.
In many cases, you want your controls to be applied to a specific set of users. In a condition statement, you
can define this set by selecting the required users and groups your policy applies to. If necessary, you can
also explicitly exclude a set of users from your policy by exempting them.
What?
When you configure a conditional access policy, you need to select the cloud apps your policy applies to.
Typically, there are certain apps in your environment requiring, from a protection perspective, more attention
than others. This affects, for example, apps that have access to sensitive data. By selecting cloud apps, you
define the scope of cloud apps your policy applies to. If necessary, you can also explicitly exclude a set of apps
from your policy.
For a complete list of the cloud apps you can use in your conditional access policy, see the Azure Active
Directory Conditional Access technical reference.
How?
As long as access to your apps is performed under conditions you can control, there might be no need for
imposing additional controls on how your cloud apps are accessed by your users. However, things might
look different if access to your cloud apps is performed, for example, from networks that are not trusted or
devices that are not compliant. In a condition statement, you can define certain access conditions that have
additional requirements for how access to your apps is performed.
Conditions
In the current implementation of Azure Active Directory, you can define conditions for the following areas:
Sign-in risk
Device platforms
Locations
Client apps
Sign-in risk
A sign-in risk is an object that is used by Azure Active Directory to track the likelihood that a sign-in attempt
was not performed by the legitimate owner of a user account. In this object, the likelihood (High, Medium, or
Low) is stored in form of an attribute called sign-in risk level. This object is generated during a sign-in of a
user if sign-in risks have been detected by Azure Active Directory. For more information, see Risky sign-ins.
You can use the calculated sign-in risk level as condition in a conditional access policy.
Device platforms
The device platform is characterized by the operating system that is running on your device: You can define
the device platforms that are included as well as device platforms that are exempted from a policy.
To use device platforms in the policy, first change the configure toggles to Yes, and then select all or
individual device platforms the policy applies to. If you select individual device platforms, the policy has only
an impact on these platforms. In this case, sign-ins to other supported platforms are not impacted by the
policy.
For a complete list of the supported device platforms, see device platform condition.
Locations
With locations, you have the option to define conditions that are based on where a connection attempt was
initiated from. The entries in the locations list are either named locations or MFA trusted IPs.
Named locations is a feature of Azure Active Directory that allows you to define labels for the locations
connection attempts were made from. To define a location, you can either configure an IP address ranges or
you select a country / region.
Additionally, you can mark a named location as trusted location. For a conditional access policy, the trusted
location is another filter option that enables you to select All trusted locations in your locations condition.
Named locations are also important in the context of the detection of risk events to reduce the number of
false-positives for the impossible travel to atypical locations risk event.
The number of named locations you can configure is constrained by the size of the related object in Azure
AD. You can configure:
One named location with up to 500 IP ranges
A maximum of 60 named locations (preview) with one IP range assigned to each of them
For more information, see named locations in Azure Active Directory.
MFA trusted IPs is a feature of multi-factor authentication that enables you to define trusted IP address
ranges representing your organization's local intranet. When you configure a location condition, Trusted IPs
enables you to distinguish between connections made from your organization's network and all other
locations. For more information, see trusted IPs.
In your conditional access policy, you can:
Include
Any location
All trusted locations
Selected locations
Exclude
Selected locations
Client apps
The client app can be either on a generic level the app (web browser, mobile app, desktop client) you have
used to connect to Azure Active Directory or you can specifically select Exchange Active Sync.
Legacy authentication refers to clients using basic authentication such as older Office clients that don’t use
modern authentication. Conditional access is currently not supported with legacy authentication.
For a complete list of the client apps you can use in your conditional access policy, see the Azure Active
Directory Conditional Access technical reference.
Common scenarios
Requiring multi-factor authentication for apps
Many environments have apps requiring a higher level of protection than the others. This is, for example, the
case for apps that have access to sensitive data. If you want to add another layer of protection to these apps,
you can configure a conditional access policy that requires multi-factor authentication when users are
accessing these apps.
Requiring multi-factor authentication for access from networks that are not trusted
This scenario is similar to the previous scenario because it adds a requirement for multi-factor authentication.
However, the main difference is the condition for this requirement.
While the focus of the previous scenario was on apps with access to sensitive data, the focus of this scenario
is on trusted locations.
In other words, you might have a requirement for multi-factor authentication if an app is accessed by a user
from a network you don't trust.
Only trusted devices can access Office 365 services
If you are using Intune in your environment, you can immediately start using the conditional access policy
interface in the Azure console.
Many Intune customers are using conditional access to ensure that only trusted devices can access Office 365
services. This means that mobile devices are enrolled with Intune and meet compliance policy requirements,
and that Windows PCs are joined to an on-premises domain. A key improvement is that you do not have to
set the same policy for each of the Office 365 services. When you create a new policy, configure the Cloud
apps to include each of the O365 apps that you wish to protect with Conditional Access.
Switching a device from corporate -owned to Bring Your Own Device (BYOD)
If you want to block enrolled devices by changing the device ownership from corporate to personal, you can
accomplish this using Azure Active Directory (AAD) conditional access. You must first create a conditional
access policy where Block access is selected from the access controls Grant blade. Next, create a Dynamic
Device group by setting the deviceOwnership property to Personal. Then, target the above policy to the
new group.
Next steps
If you want to know how to configure a conditional access policy, see Get started with conditional
access in Azure Active Directory.
If you are ready to configure conditional access policies for your environment, see the best practices
for conditional access in Azure Active Directory.
Controls in Azure Active Directory conditional access
With Azure Active Directory (Azure AD) conditional access, you can control how authorized users access your cloud
apps. In a conditional access policy, you define the response ("do this") to a specific condition ("when this
happens"). In the context of conditional access,
"When this happens" is called condition statement
"Then do this" is called controls
The combination of a condition statement with your controls represents a conditional access policy.
Each control is either a requirement that must be fulfilled by the person or system signing in, or a restriction on
what the user can do after signing in.
There are two types of controls:
Grant controls - To gate access
Session controls - To restrict access within a session
This topic explains the various controls that are available in Azure AD conditional access.
Grant controls
With grant controls, you can either block access altogether or allow access with additional requirements by
selecting the desired controls. For multiple controls, you can require:
All selected controls to be fulfilled (AND)
One selected control to be fulfilled (OR)
Multi-factor authentication
You can use this control to require multi-factor authentication to access the specified cloud app. This control
supports the following multi-factor providers:
An on-premises multi-factor authentication provider, combined with Active Directory Federation Services
(AD FS).
Using multi-factor authentication helps protect resources from being accessed by an unauthorized user who might
have gained access to the primary credentials of a valid user.
Compliant device
You can configure conditional access policies that are device-based. The objective of a device-based conditional
access policy is to grant access to the configured resources only from trusted devices. Requiring a compliant device
is one option you have to define what a trusted device is. For more information, see set up Azure Active Directory
device-based conditional access policies.
Domain-joined device
Requiring a domain-joined device is another option you have to configure device-based conditional access policies.
This requirement refers to Windows desktops, laptops, and enterprise tablets that are joined to an on-premises
Active Directory. For more information, see set up Azure Active Directory device-based conditional access policies.
Approved client app
Because your employees use mobile devices for both personal and work tasks, you might want to have the ability
to protect company data accessed using devices even in the case where they are not managed by you. You can use
Intune app protection policies to help protect your company’s data independent of any mobile-device management
(MDM) solution.
With approved client apps, you can require a client app that attempts to access your cloud apps to support Intune
app protection policies. For example, you can restrict access to Exchange Online to the Outlook app. A conditional
access policy that requires approved client apps is also known as app-based conditional access policy. For a list of
supported approved client apps, see approved client app requirement.
Terms of Use
You can require a user in your tenant to consent to the terms of use before being granted access to a resource. As
an administrator, you can configure and customize terms of use by uploading a PDF document. If a user falls in
scope of this control access to an application is only granted if the terms of use have been agreed.
Custom controls
You can create custom controls in Conditional Access that redirect your users to a compatible service to satisfy
further requirements outside of Azure Active Directory. This allows you to use certain external multi-factor
authentication and verification providers to enforce Conditional Access rules, or to build your own custom service.
To satisfy this control, a user’s browser is redirected to the external service, performs any required authentication
or validation activities, and is then redirected back to Azure Active Directory. If the user was successfully
authenticated or validated, the user continues in the Conditional Access flow.
Custom controls
Custom controls are a capability of the Azure Active Directory Premium P2 edition. When using custom controls,
your users are redirected to a compatible service to satisfy further requirements outside of Azure Active Directory.
To satisfy this control, a user’s browser is redirected to the external service, performs any required authentication
or validation activities, and is then redirected back to Azure Active Directory. Azure Active Directory verifies the
response and, if the user was successfully authenticated or validated, the user continues in the conditional access
flow.
These controls allow the use of certain external or custom services as conditional access controls, and generally
extend the capabilities of Conditional Access.
Providers currently offering a compatible service include:
Duo Security
RSA
Trusona
For more information on those services, contact the providers directly.
Creating custom controls
To create a custom control, you should first contact the provider that you wish to utilize. Each non-Microsoft
provider has its own process and requirements to sign up, subscribe, or otherwise become a part of the service,
and to indicate that you wish to integrate with conditional access. At that point, the provider will provide you with a
block of data in JSON format. This data allows the provider and conditional access to work together for your
tenant, creates the new control and defines how conditional access can tell if your users have successfully
performed verification with the provider.
Copy the JSON data and then paste it into the related textbox. Do not make any changes to the JSON unless you
explicitly understand the change you’re making. Making any change could break the connection between the
provider and Microsoft and potentially lock you and your users out of your accounts.
The option to create a custom control is in the Manage section of the Conditional access page.
Clicking New custom control, opens a blade with a textbox for the JSON data of your control.
Deleting custom controls

To delete a custom control, you must first ensure that it isn’t being used in any conditional access policy. Once
complete:
1. Go to the Custom controls list
2. Click …
3. Select Delete.
Editing custom controls
To edit a custom control, you must delete the current control and create a new control with the updated
information.
Session controls
Session controls enable limited experience within a cloud app. The session controls are enforced by cloud apps and
rely on additional information provided by Azure AD to the app about the session.
Use app enforced restrictions
You can use this control to require Azure AD to pass the device information to the cloud app. This helps the cloud
app know if the user is coming from a compliant device or domain joined device. This control is currently only
supported with SharePoint as the cloud app. SharePoint uses the device information to provide users a limited or
full experience depending on the device state. To learn more about how to require limited access with SharePoint,
see control access from unmanaged devices.
Next steps
If you want to know how to configure a conditional access policy, see get started with conditional access in
If you are ready to configure conditional access policies for your environment, see the best practices for
conditional access in Azure Active Directory.
Location conditions in Azure Active Directory
conditional access
With Azure Active Directory (Azure AD) conditional access, you can control how authorized users can access your
cloud apps. The location condition of a conditional access policy enables you to tie access controls settings to the
network locations of your users.
This article provides you with the information you need to configure the location condition.
Locations
Azure AD enables single sign on to devices, apps, and services from anywhere on the public internet. With the
location condition, you can control access to your cloud apps based on the network location of a user. Common use
cases for the location condition are:
Requiring multi-factor authentication for users accessing a service when they are off the corporate network
Blocking access for users accessing a service from specific countries or regions.
A location is a label for a network location that either represents a named location or multi-factor authentication
trusted IPs.
Named locations
With named locations, you can create logical groupings of IP address ranges, countries and regions.
A name location has the following components:
Name - The display name of a named location.

IP ranges - One or more IP address ranges in CIDR format.
Mark as trusted location - A flag you can set for a named location to indicate a trusted location. Typically,
trusted locations are network areas that are controlled by your IT department. In addition to conditional
access, trusted named locations are also used by Azure Identity Protection and Azure AD security reports to
reduce false positives.
Country / Regions - This option enables you to select one or more country or region to define a named
location.
Include unknown areas - Some IP addresses are not mapped to a specific country. This option allows you
to choose if these IP addresses should be included in the named location. They could be check when the
policy using the named location should apply to unknown locations.
The number of named locations you can configure is constrained by the size of the related object in Azure AD. You
can configure:
One named location with up to 1200 IP ranges.
A maximum of 90 named locations with one IP range assigned to each of them.
Trusted IPs
You can also configure IP address ranges representing your organization's local intranet in the multi-factor
authentication service settings. This feature enables you to configure up to 50 IP address ranges. The IP address
ranges are in CIDR format. For more information, see trusted IPs.
If you have trusted IPs configured, they show up as MFA Trusted IPS in the list of locations for the location
condition.
Skipping multi-factor authentication
On the multi-factor authentication service settings page, you can identify corporate intranet users by selecting Skip
multi-factor authentication for requests from federated users on my intranet. This setting indicates that the
inside corporate network claim, which is issued by AD FS, should be trusted and used to identify the user as being
on the corporate network. For more information, see Enable the Trusted IPs feature by using conditional access.
After checking this option, including the named location MFA Trusted IPS will apply to any policies with this
selected.
For mobile and desktop applications, which have long lived session lifetimes, conditional access is periodically re-
evaluated. The default is once an hour. When the inside corporate network claim is and only issued at the time of
the initial authentication, Azure AD may not have a list of trusted IP ranges. In this case, it is more difficult to
determine if the user is still on the corporate network:
1. Check if the user’s IP address is in one of the trusted IP ranges.
2. Check whether the first three octets of the user’s IP address match the first 3 octets of the IP address of the
initial authentication. The IP address is compared with the initial authentication because this is when the
inside corporate network claim was originally issued and the user location was validated.
If both steps fail, a user is considered to be no longer on a trusted IP.
Location condition configuration

When you configure the location condition, you have the option to distinguish between:
Any location
Selected locations
Any location
By default, selecting Any location causes a policy to be applied to all IP addresses, which means any address on
the Internet. This setting is not not limited to IP addresses you have configured as named location. When you select
Any location, you can still exclude specific locations from a policy. For example, you can apply a policy to all
locations excepts trusted locations to set the scope to all locations, except the corporate network.
This option applies to:
All locations that have been marked as trusted location
MFA Trusted IPS (if configured)
Selected locations
With this option, you can select one or more named locations. For a policy with this setting to apply, a user needs to
connect from any of the selected locations. Whe you click Select the named network selection control that shows
the list of named networks opens. The list also shows if the network location has been marked as trusted. The
named location called MFA Trusted IPs is used to include the IP settings that can be configured in the multi-factor
authentication service setting page.

When is a location evaluated?
Conditional access policies are evaluated when:
A user initially signs in
Azure AD issues a token for the cloud app the conditional access policy has been set on.
By default, Azure AD issues a token on an hourly basis. After moving off the corporate network, within an hour the
policy is enforced for applications using modern authentication.
User IP address
The IP address that is used in policy evaluation is the public IP address of the user. For devices on a private network,
this is not the client IP of the user’s device on the intranet, it is the address used by the network to connect to the
public internet.
Bulk uploading and downloading of named locations
When you create or update named locations, for bulk updates, you can upload or download a CSV file with the IP
ranges. An upload replaces the IP ranges in the list with those from the file. Each row of the file contains one IP
Address range in CIDR format.
Cloud proxies and VPNs
When you use a cloud hosted proxy or VPN solution, the IP address Azure AD uses while evaluating a policy is the
IP address of the proxy. The X-Forwarded-For (XFF) header that contains the users public IP address is not used
because there is no validation that it comes from a trusted source, so would present a method for faking an IP
address.
When a cloud proxy is in place, a policy that is used to require a domain joined device can be used, or the inside
corpnet claim from AD FS.
API support and PowerShell
API and PowerShell is not yet supported for named locations, or for conditional access policies.
Next steps
If you want to know how to configure a conditional access policy, see Get started with conditional access in
Get started with conditional access in Azure Active
Directory
Conditional access is a capability of Azure Active Directory that enables you to define conditions under which
authorized users can access your apps.
This topic provides you with instructions for testing a conditional access based on a location condition in your
environment.
Scenario description
One common requirement in many organizations is to only require multi-factor authentication for access to
apps that is not performed from the corporate intranet. With Azure Active Directory, you can easily accomplish
this goal by configuring a location-based conditional access policy. This topic provides you with detailed
instructions for configuring a related policy. The policy leverages Trusted IPs to distinguish between access
attempts made from the corporate's intranet and all other locations.
Prerequisites
The scenario outlined in this topic assumes that you are familiar with the concepts outlined in Azure Active
Directory conditional access.
To test this scenario, you need to:
Create a test user
Assign an Azure AD Premium license to the test user
Configure a managed app and assign your test user to it
Configure trusted IPs
If you need more details about Trusted IPs, see Trusted IPs.
Policy configuration steps

To configure your conditional access policy, do:
1. In the Azure portal, on the left navbar, click Azure Active Directory.
2. On the Azure Active Directory blade, in the Manage section, click Conditional access.
3. On the Conditional Access blade, to open the New blade, in the toolbar on the top, click Add.
4. On the New blade, in the Name textbox, type a name for your policy.
5. In the Assignment section, click Users and groups.
6. On the Users and groups blade, perform the following steps:
a. Click Select users and groups.

b. Click Select.
c. On the Select blade, select your test user, and then click Select.
d. On the Users and groups blade, click Done.
7. On the New blade, to open the Cloud apps blade, in the Assignment section, click Cloud apps.
8. On the Cloud apps blade, perform the following steps:
a. Click Select apps.

b. Click Select.
c. On the Select blade, select your cloud app, and then click Select.
d. On the Cloud apps blade, click Done.
9. On the New blade, to open the Conditions blade, in the Assignment section, click Conditions.
10. On the Conditions blade, to open the Locations blade, click Locations.
11. On the Locations blade, perform the following steps:

a. Under Configure, click Yes.
b. Under Include, click All locations.
c. Click Exclude, and then click All trusted IPs.
d. Click Done.
12. On the Conditions blade, click Done.
13. On the New blade, to open the Grant blade, in the Controls section, click Grant.
14. On the Grant blade, perform the following steps:

a. Select Require multi-factor authentication.
b. Click Select.
15. On the New blade, under Enable policy, click On.
16. On the New blade, click Create.
Testing the policy

To test your policy, you should access your app from a device that:
1. Has an IP address that is within your configured Trusted IPs
2. Has an IP address that is not within your configured Trusted IPs
Multi-factor authentication should only be required during a connection attempt that was made from a device
that is not within your configured Trusted IPs.
Next steps
If you would like to learn more about conditional access, see Azure Active Directory conditional access.
Best practices for conditional access in Azure Active
Directory
This topic provides you with information about things you should know and what it is you should avoid doing
when configuring conditional access policies. Before reading this topic, you should familiarize yourself with the
concepts and the terminology outlined in Conditional access in Azure Active Directory

What’s required to make a policy work?
When you create a new policy, there are no users, groups, apps or access controls selected.
To make your policy work, you must configure the following:
WHAT HOW WHY
Cloud apps You need to select one or more apps. The goal of a conditional access policy
is to enable you to fine-tune how
authorized users can access your apps.
Users and groups You need to select at least one user or A conditional access policy that has no
group that is authorized to access the users and groups assigned, is never
cloud apps you have selected. triggered.
Access controls You need to select at least one access Your policy processor needs to know
control. what to do if your conditions are
satisfied.
In addition to these basic requirements, in many cases, you should also configure a condition. While a policy
would also work without a configured condition, conditions are the driving factor for fine-tuning access to your
apps.
How are assignments evaluated?
All assignments are logically ANDed. If you have more than one assignment configured, to trigger a policy, all
assignments must be satisfied.
If you need to configure a location condition that applies to all connections made from outside your
organization's network, you can accomplish this by:
Including All locations
Excluding All trusted IPs
What happens if you have policies in the Azure classic portal and Azure portal configured?
Both policies are enforced by Azure Active Directory and the user gets access only when all requirements are met.
What happens if you have policies in the Intune Silverlight portal and the Azure Portal?
Both policies are enforced by Azure Active Directory and the user gets access only when all requirements are met.
What happens if I have multiple policies for the same user configured?
For every sign-in, Azure Active Directory evaluates all policies and ensures that all requirements are met before
granted access to the user.
Does conditional access work with Exchange ActiveSync?
Yes, you can use Exchange ActiveSync in a conditional access policy.
What you should avoid doing

The conditional access framework provides you with a great configuration flexibility. However, great flexibility
also means that you should carefully review each configuration policy prior to releasing it to avoid undesirable
results. In this context, you should pay special attention to assignments affecting complete sets such as all users /
groups / cloud apps.
In your environment, you should avoid the following configurations:
For all users, all cloud apps:
Block access - This configuration blocks your entire organization, which is definitely not a good idea.
Require compliant device - For users that don't have enrolled their devices yet, this policy blocks all
access including access to the Intune portal. If you are an administrator without an enrolled device, this
policy blocks you from getting back into the Azure portal to change the policy.
Require domain join - This policy block access has also the potential to block access for all users in your
organization if you don't have a domain-joined device yet.
For all users, all cloud apps, all device platforms:
Block access - This configuration blocks your entire organization, which is definitely not a good idea.
Policy migration
You should consider migrating the policies you have not created in the Azure portal because:
You can now address scenarios you could not handle before.
You can reduce the number of policies you have to manage by consolidating them.
You can manage all your conditional access policies in one central location.
The Azure classic portal will be retired.
For more information, see Migrate classic policies in the Azure portal.
Next steps
If you want to know how to configure a conditional access policy, see Get started with conditional access in Azure
Active Directory.
Active Directory conditional access device policies for
Office 365 services
Conditional access requires multiple pieces to work. It involves a multi-factor authenticated user, an authenticated
device, and a compliant device, among other factors. In this article, we primarily focus on device-based conditions
that your organization can use to help you control access to Office 365 services.
Corporate users want to access Office 365 services like Exchange and SharePoint Online at work or school from
their personal devices. You want the access to be secure. You can provision conditional access device policies to
help make corporate resources more secure, while granting access to services for users who are using compliant
devices. You can set conditional access policies to Office 365 in the Microsoft Intune conditional access portal.
Azure Active Directory (Azure AD) enforces conditional access policies to help secure access to Office 365 services.
You can create a conditional access policy that blocks a user who is using a noncompliant device from accessing an
Office 365 service. The user must conform to the company’s device policies before access to the service is granted.
Alternately, you can create a policy that requires users to enroll their devices to gain access to an Office 365 service.
Policies can be applied to all users in an organization, or limited to a few target groups. You can add more target
groups to a policy over time.
A prerequisite for enforcing device policies is that users must register their devices with the Azure AD device
registration service. You can opt to turn on multi-factor authentication for devices that register with the Azure AD
device registration service. Multi-factor authentication is recommended for the Azure Active Directory device
registration service. When multi-factor authentication is turned on, users who register their devices with the Azure
AD device registration service are challenged for second-factor authentication.
How does a conditional access policy work?

When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates
the user and the device. Azure AD grants access to the service only if the user conforms to the policy set for the
service. Users on devices that are not enrolled are given instructions on how to enroll and become compliant to
access corporate Office 365 services. Users on iOS and Android devices are required to enroll their devices by
using the Intune Company Portal application. When a user enrolls a device, the device is registered with Azure AD
and it's enrolled for device management and compliance. You must use the Azure AD device registration service
with Microsoft Intune for mobile device management for Office 365 services. Device enrollment is required for
users to access Office 365 services when device policies are enforced.
When a user successfully enrolls a device, the device becomes trusted. Azure AD gives the authenticated user single
sign-on access to company applications. Azure AD enforces a conditional access policy to grant access to a service
not only the first time the user requests access, but every time the user renews a request for access. The user is
denied access to services when sign-in credentials are changed, the device is lost or stolen, or the conditions of the
policy are not met at the time of request for renewal.
Deployment considerations
You must use the Azure AD device registration service to register devices.
When on-premises users are about to be authenticated, Active Directory Federation Services (AD FS) (version 1.0
and later versions) is required. Multi-factor authentication for Workplace Join fails when the identity provider is not
capable of multi-factor authentication. For example, you can't use multi-factor authentication with AD FS 2.0.
Ensure that the on-premises AD FS works with multi-factor authentication, and that a valid multi-factor
authentication method is in place before you turn on multi-factor authentication for the Azure AD device
registration service. For example, AD FS on Windows Server 2012 R2 has multi-factor authentication capabilities.
You also must set an additional valid authentication (multi-factor authentication) method on the AD FS server
before you turn on multi-factor authentication for the Azure AD device registration service. For more information
about supported multi-factor authentication methods in AD FS, see Configure additional authentication methods
for AD FS.
Next steps
For answers to common questions, see Azure Active Directory conditional access FAQs.
Migrate classic policies in the Azure portal
Conditional access is a capability of Azure Active directory (Azure AD) that enables you to control how authorized
users access your cloud apps. While the purpose is still the same, the release of the new Azure portal has
introduced significant improvements to how conditional access works.
You should consider migrating the policies you have not created in the Azure portal because:
You can now address scenarios you could not handle before.
You can reduce the number of policies you have to manage by consolidating them.
You can manage all your conditional access policies in one central location.
The Azure classic portal will be retired.
This article explains what you need to know to migrate your existing conditional access policies to the new
framework.
Classic policies
In the Azure portal, the Conditional access - Policies page is your entry point to your conditional access polices.
However, in your environment, you might also have conditional access policies you have not created using this
page. These policies are known as classic policies. Classic policies are conditional access policies, you have created
in:
The Azure classic portal
The Intune classic portal
The Intune App Protection portal
On the Conditional access page, you can access your classic policies by clicking Classic policies (preview) in
the Manage section.
The Classic policies view provides you with an option to:

Filter your classic policies.
Disable classic policies.
Review the settings of a classic policies (and to disable it).
If you have disabled a classic policy, you can't revert this step anymore. This is why you can modify the group
membership in a classic policy using the Details view.
By either changing the selected groups or by excluding specific groups, you can test the effect of a disabled classic
policy for a few test users before disabling the policy for all included users and groups.
Azure AD conditional access policies

With conditional access in the Azure portal, you can manage all your policies in one central location. Because the
implementation of how conditional access has significantly changed, you should familiarize yourself with the basic
concepts before migrating your classic policies.
See:
Conditional access in Azure Active Directory to learn about the basic concepts and the terminology.
Best practices for conditional access in Azure Active Directory to get some guidance on deploying
conditional access in your organization.
Get started with conditional access in Azure Active Directory to familiarize yourself with the user interface in
the Azure portal.
Migration considerations
In this article, Azure AD conditional access policies are also referred to as new policies. Your classic policies
continue to work side by side with your new policies until you disable or delete them.
The following aspects are important in the context of a policy consolidation:
While classic policies are tied to a specific cloud app, you can select as many cloud apps as you need to in a
new policy.
Controls of a classic policy and a new policy for a cloud app require all controls (AND) to be fulfilled.
In a new policy, you can:
Combine multiple conditions if required by your scenario.
Select several grant requirements as access control and combine them with a logical OR (require one
of the selected controls) or with a logical AND (require all of the selected controls).
Office 365 Exchange online

If you want to migrate classic policies for Office 365 Exchange online that include Exchange Active Sync as
client apps condition, you might not be able to consolidate them into one new policy.
This is, for example, the case if you want to support all client app types. In a new policy that has Exchange Active
Sync as client apps condition, you can't select other client apps.
A consolidation into one new policy is also not possible if your classic policies contain several conditions. A new
policy that has Exchange Active Sync as client apps condition configured does not support other conditions:
If you have a new policy that has Exchange Active Sync as client apps condition configured, you need to make
sure that all other conditions are not configured.
App-based classic policies for Office 365 Exchange Online that include Exchange Active Sync as client apps
condition allow supported and unsupported device platforms. While you can't configure individual device
platforms in a related new policy, you can limit the support to supported device platforms only.
You can consolidate multiple classic policies that include Exchange Active Sync as client apps condition if they
have:
Only Exchange Active Sync as condition
Several requirements for granting access configured
One common scenario is the consolidation of:
A device-based classic policy from the Azure classic portal
An app-based classic policy in the Intune app protection portal
In this case, you can consolidate your classic policies into one new policy that has both requirements selected.
Device platforms
Classic policies with app-based controls are pre-configured with iOS and Android as the device platform condition.
In a new policy, you need to select the device platforms you want to support individually.
Next steps
Azure Active Directory conditional access what if tool
- preview
Conditional access is a capability of Azure Active Directory (Azure AD) that enables you to control how authorized
users access your cloud apps. How do you know what to expect form the conditional access policies in your
environment? To answer this question, you can use the conditional access what if tool.
This article explains how you can use this tool to test your conditional access policies.
What it is
The conditional access what if policy tool allows you to understand the impact of your conditional access
policies on your environment. Instead of test driving your policies by performing multiple sign-ins manually, this
tool enables you to evaluate a simulated sign-in of a user. The simulation estimates the impact this sign-in has on
your policies and generates a simulation report. The report does not only list the applied conditional access policies
but also classic policies if they exist.
The what if tools also provides a way to quickly determine the policies that apply to a specific user. You can use the
information, for example, if you need to troubleshoot an issue.
How it works
In the conditional access what if tool, you first need to configure the settings of the sign-in scenario you want to
simulate. These settings include:
The user you want to test
The cloud apps the user would attempt to access
The conditions under which access to the configures cloud apps is performed
As a next step, you can initiate a simulation run that evaluates your settings. Only policies that are enabled are part
of an evaluation run.
When the evaluation has finished, the tool generates a report of the affected policies.
Running the tool

You can find the what if tool on the Conditional access - Policies page in the Azure portal.
To start the tool, in the toolbar on top of the list of policies, click What if.
Before you can run an evaluation, you must configure the settings.
Settings
This section provides you with information about the settings of simulation run.
User
You can only select one user. This is the only required field.
Cloud apps
The default for this setting is All cloud apps. The default setting performs an evaluation of all available policies in
your environment. You can narrow down the scope to policies affecting specific cloud apps.
IP address
The IP address is a single IPv4 address to mimic the location condition. The address represents Internet facing
address of the device used by your user to sign in. You can verify the IP address of a device by, for example,
navigating to What is my IP address.
Device platforms
This setting mimics the device platforms condition and represents the equivalent of All platforms (including
unsupported).
Client apps
This setting mimics the client apps condition. By default, this setting causes an evaluation of all policies having
Browser or Mobile apps and desktop clients either individually or both selected. It also detects policies that
enforce Exchange ActiveSync (EAS). You can narrow this setting down by selecting:
Browser to evaluate all policies having at least Browser selected.
Mobile apps and desktop clients to evaluate all policies having at least Mobile apps and desktop
clients selected.
Sign-in risk
This setting mimics the sign-in risk condition.
Evaluation
You start an evaluation by clicking What if. The evaluation result provides you with a report that consists of:
An indicator whether classic policies exist in your environment

Policies that apply to your user
Policies that don't apply to your user
If classic policies exist for the selected cloud apps, an indicator is presented to you. By clicking the indicator, you are
redirected to the classic policies page. On the classic policies page, you can migrate a classic policy or just disable it.
You can return to your evaluation result by closing this page.
On the list of policies that apply to your selected user, you can also find a list of grant controls and session controls
your user must satisfy.
On the list of policies that don't apply to your user, you can and also find the reasons why these policies don't apply.
For each listed policy, the reason represents the first condition that was not satisfied. A possible reason for a policy
that is not applied is a disabled policy because they are not further evaluated.
Next steps
If you want to know how to configure a conditional access policy, see get started with conditional access in
if you want to migrate classic policies, see Migrate classic policies in the Azure portal
Migrate a classic policy that requires multi-factor
authentication in the Azure portal
This article shows how to migrate a classic policy that requires multi-factor authentication for a cloud app.
Although it is not a prerequisite, we recommend that you read Migrate classic policies in the Azure portal before
you start migrating your classic policies.
Overview
The scenario in this article shows how to migrate a classic policy that requires multi-factor authentication for a
cloud app.
The migration process consist of the following steps:

1. Open the classic policy to get the the configuration settings.
2. Create a new Azure AD conditional access policy to replace your classic policy.
3. Disable the classic policy.
Open a classic policy

2. On the Azure Active Directory page, in the Manage section, click Conditional access.
3. In the Manage section, click Classic policies (preview).

4. In the list of classic policies, click the policy that requires multi-factor authentication for a cloud app.
Create a new conditional access policy

3. On the Conditional Access page, to open the New page, in the toolbar on the top, click Add.
4. On the New page, in the Name textbox, type a name for your policy.
5. In the Assignments section, click Users and groups.
a. If you have all users selected in your classic policy, click All users.
b. If you have groups selected in your classic policy, click Select users and groups, and then select the
required users and groups.
c. If you have the excluded groups, click the Exclude tab, and then select the required users and groups.
6. On the New page, to open the Cloud apps page, in the Assignment section, click Cloud apps.
7. On the Cloud apps page, perform the following steps:

a. Click Select apps.
b. Click Select.
c. On the Select page, select your cloud app, and then click Select.
d. On the Cloud apps page, click Done.
8. If you have Require multi-factor authentication selected:
a. In the Access controls section, click Grant.
b. On the Grant page, click Grant access, and then click Require multi-factor authentication.
c. Click Select.
9. Click On to enable your policy.
Disable the classic policy

To disable your classic policy, click Disable in the Details view.
Next steps
For more information about the classic policy migration, see Migrate classic policies in the Azure portal.
Configure Azure Active Directory device-based
conditional access policies
With Azure Active Directory (Azure AD) conditional access, you can fine-tune how authorized users can access
your resources. For example, you limit the access to certain resources to trusted devices. A conditional access
policy that requires a trusted device is also known as device-based conditional access policy.
This topic provides you with information on how to configure device-based conditional access policies for Azure
AD-connected applications.
Before you begin

Device-based conditional access ties Azure AD conditional access and Azure AD device management
together. If you are not familiar with one of these areas yet, you should read the following topics, first:
Conditional access in Azure Active Directory - This topic provides you with a conceptual overview of
conditional access and the related terminology.
Introduction to device management in Azure Active Directory - This topic gives you an overview of
the various options you have to connect devices with Azure AD.
Trusted devices
In a mobile-first, cloud-first world, Azure Active Directory enables single sign-on to devices, apps, and services
from anywhere. For certain resources in your environment, granting access to the right users might not be good
enough. In addition to the right users, you might also require a trusted device to be used to access a resource. In
your environment, you can define what a trusted device is based on the following components:
The device platforms on a device
Whether a device is compliant
Whether a device is domain-joined
The device platforms is characterized by the operating system that is running on your device. In your device-based
conditional access policy, you can limit access to certain resources to specific device platforms.
In a device-based conditional access policy, you can require trusted devices to be marked as compliant.
Devices can be marked as compliant in the directory by:

Intune
A third-party mobile device managed system that manages Windows 10 devices via Azure AD integration
Only devices that are connected to Azure AD can be marked as compliant. To connect a device to Azure Active
Directory, you have the following options:
Azure AD registered
Azure AD joined
Hybrid Azure AD joined
If you have an on-premises Active Directory (AD) footprint, you might consider devices that are not connected to
Azure AD but joined to your AD to be trusted.
Next steps
Before configuring a device-based conditional access policy in your environment, you should take a look at the
best practices for conditional access in Azure Active Directory.
Your employees use mobile devices for both personal and work tasks. While making sure your employees can be
productive, you also want to prevent data loss. With Azure Active Directory (Azure AD) app-based conditional
access, you can restrict access to your cloud apps to client apps that can protect your corporate data.
This topic explains how to configure Azure AD app-based conditional access.
Overview
With Azure AD conditional access, you can fine-tune how authorized users can access your resources. For
example, you can limit the access to your cloud apps to trusted devices.
You can use Intune app protection policies to help protect your company’s data. Intune app protection policies
don't require mobile-device management (MDM) solution, which enables you to protect your company’s data
with or without enrolling devices in a device management solution.
Azure Active Directory app-based conditional access enables you limit access to your cloud apps to client apps
that support Intune app protection policies. For example, you can restrict access to Exchange Online to the Outlook
app.
In the conditional access terminology, these client apps are known as approved client apps.
For a list of approved client apps, see approved client app requirement.
You can combine app-based conditional access policies with other policies such as device-based conditional
access policies to provide flexibility in how to protect data for both personal and corporate devices.
Before you begin

This topic assumes that you are familiar with:
The approved client app requirement technical reference.
The basic concepts of conditional access in Azure Active Directory.
How to configure a conditional access policy.
The migration of conditional access policies.
Prerequisites
To create an app-based conditional access policy, you must have an Enterprise Mobility + Security or an Azure
Active Directory premium subscription, and the users must be licensed for EMS or Azure AD.
Exchange Online policy

This scenario consists of an app-based conditional access policy for access to Exchange Online.
Scenario playbook
This scenario assumes that a user:
Configures email using a native mail application on iOS or Android to connect to Exchange
Receives an email that indicates that access is only available using Outlook app
Downloads the application with the link
Opens the Outlook application and signs in with the Azure AD credentials
Is prompted to install either Authenticator (iOS) or Company Portal (Android) to continue
Installs the application and can return to the Outlook app to continue
Is prompted to register a device
Is able to access email
Any Intune app protection policies are activated at the time the access corporate data and may prompt the user to
restart the application, use an additional PIN etc (if configured for the application and platform).
Configuration
Step 1 - Configure an Azure AD conditional access policy for Exchange Online
For the conditional access policy in this step, you need to configure the following components:
1. The Name of your conditional access policy.
2. Users and groups: Each conditional access policy must have at least one user or group selected.
3. Cloud apps: As cloud apps, you need to select Office 365 Exchange Online.
4. Conditions: As Conditions, you need to configure Device platforms and Client apps:
a. As Device platforms, select Android and iOS.
b. As Client apps, select Mobile apps and desktop apps.
5. As Access controls, you need to have Require approved client app (preview) selected.
Step 2 - Configure an Azure AD conditional access policy for Exchange Online with Active Sync (EAS)
4. Conditions: As Conditions, you need to configure Client apps.

a. As Client apps, select Exchange Active Sync.
b. As Access controls, you need to have Require approved client app (preview) selected.
Step 3 - Configure Intune app protection policy for iOS and Android client applications
See Protect apps and data with Microsoft Intune for more information.
Exchange Online and SharePoint Online policy

This scenario consists of a conditional access with mobile app management policy for access to Exchange Online
and SharePoint Online with approved apps.
Scenario playbook
Tries to use the SharePoint app to connect and also to view their corporate sites
Attempt to sign-in with the same credentials as the Outlook app credentials
Does not have to re-register and can get access to the resources
Configuration
Step 1 - Configure an Azure AD conditional access policy for Exchange Online and SharePoint Online

3. Cloud apps: As cloud apps, you need to select Office 365 Exchange Online and Office 365 SharePoint
Online.
4. Conditions: As Conditions, you need to configure Device platforms and Client apps:

3. Cloud apps: As cloud apps, you need to select Office 365 Exchange Online. Online
4. Conditions: As Conditions, you need to configure Client apps:
a. As Client apps, select Exchange Active Sync.
b. As Access controls, you need to have Require approved client app (preview) selected.
App-based or compliant device policy for Exchange Online and

SharePoint Online
This scenario consists of an app-based or compliant device conditional access policy for access to Exchange
Online.
Scenario playbook
This scenario assumes that:
Some user are already enrolled (with or without corporate devices)
Users who are not enrolled and registered with Azure AD using an app protected application need to
register a device to access resources
Enrolled users using the app protected application don't have to re-register the device
Configuration
Online.
4. Conditions: As Conditions, you need to configure Device platforms and Client apps.
5. As Access controls, you need to have the following selected:

Require device to be marked as compliant
Require approved client app (preview)
Require one of the selected controls

As Client apps*, select **Exchange Active Sync.
App-based and compliant device policy for Exchange Online and

SharePoint Online
This scenario consists of an app-based and compliant device conditional access policy for access to Exchange
Online.
Scenario playbook
Configures email using a native mail application on iOS or Android to connect to Exchange
Receives an email that indicates that access requires your device to be enrolled
Downloads the company portal and signs in to company portal
Checks mail and is asked to use the Outlook app
Downloads the Outlook app
Opens the Outlook app and enters the credentials used in the enrollment
User is able to access email
Any Intune app protection policies are activated at the time of access to the corporate data and may prompt the
user to restart the application, use an additional PIN etc. (if configured for the application and platform)
Configuration

Online.
4. Conditions: As Conditions, you need to configure Device platforms and Client apps.

Require all the selected controls


As Client apps, select Exchange Active Sync.

Require all the selected controls
Next steps
If you want to know how to configure a conditional access policy, see Get started with conditional access in Azure
Active Directory.
Azure Active Directory Terms of Use feature (Preview)
Azure AD Terms of Use provides a simple method organizations can use to present information to end users. This
ensures users see relevant disclaimers for legal or compliance requirements.
Azure AD Terms of Use uses the pdf format to present content. This pdf can be any content, such as existing
contract documents, allowing you to collect end user agreements during user sign-in. You can use the terms of use
for applications, groups of users, or if you have multiple terms of use for different purposes.
The remainder of this document describes how to get going with Azure AD Terms of Use.
Why use Azure AD Terms of Use

Finding it difficult to get employee’s or guests to agree to your terms of use before getting access? Need help
figuring out who has or hasn’t agreed to your company terms of use? Azure AD Terms of Use provides a simple
method organizations can use to present information to end users. This ensures that they see relevant disclaimers
for legal or compliance requirements.
Azure AD Terms of Use can be used in the following scenarios:
General terms of use for all users in your organization.
Specific terms of use based on a user attributes (ex. doctors vs nurses or domestic vs international employees,
done by dynamic groups).
Specific terms of use based on accessing high business impact apps, like Salesforce.
Prerequisites
Use the following steps to configure Azure AD Terms of Use:
1. Sign in to Azure AD using a global administrator, security administrator, or a conditional access administrator
for the directory you want to configure Azure AD Terms of Use.
2. Ensure that the directory has an Azure AD Premium P1, P2, EMS E3, or EMS E5 subscription. If you do not Get
Azure AD Premium or start a trial.
3. View the Azure AD Terms of User dashboard at https://aka.ms/catou.
IMPORTANT
Conditional access policy controls (including terms of use) do not support enforcement on service accounts. We recommend
excluding all service accounts from the conditional access policy.
Add Company Terms of Use

Once you have finalized your Terms of Use, use the following procedure to add it.
To add Terms of Use
1. Navigate to the dashboard at https://aka.ms/catou
2. Click Add.
3. Enter the Name for the Terms of Use
4. Enter Display Name. This header is what users see when they sign in.
5. Browse to your finalized terms of use pdf and select it. The recommended font size is 24.
6. Select a language for the terms of use. The language option allows you to upload multiple terms of use, each
with a different language. The version of the terms of use that an end user will see will be based on their
browser preferences.
7. Select either on or off for Require users to expand the terms of use. If this is set to on, end users will be
required to view the terms of use prior to accepting them.
8. Under the Conditional Access section you can Enforce the uploaded terms of use by using a template or a
custom conditional access policy. Custom conditional access policies enables granular terms of use, down to a
specific cloud application or group of users. For more information, see configuring conditional access policies
9. Click Create.
10. If you selected a custom conditional access template, then a new screen appears which allows you to customize
the CA policy.
11. You should now see your new Terms of Use.
Delete Terms of Use

You can remove or delete old terms of use using the following procedure:
To delete Terms of Use
2. Select the terms of use you want to remove.
3. Click Delete.
4. You should no longer see your new terms of use.
Audit Terms of Use
Azure AD Terms of Use provides easy to use auditing so that you can see who has accepted and when they
accepted your terms of use. To get started with auditing use the following procedure:
To audit Terms of Use
2. Click Audit Event.
3. On the Azure AD audit logs screen, you can filter the information using the provided drops downs to target
specific audit log information.
4. You can also download the information in a .csv file for use locally.
What users see

Users, who are in scope, will see the following once a terms of use is created and enforced. They will see these
screens during sign in.
Best practice is to have the font within the PDF at size 24.
This screen is how it appears on mobiles

Review terms of use
Users can review and see the terms of use that they have accepted. This can be done using the following procedure:
1. Navigate and sign-in to https://myapps.microsoft.com.
2. In upper right corner, click your name and select Profile from the drop-down.
3. On your Profile, click Review terms of use.
4. From there you can review the terms of use you have accepted.
The following information is something to be aware of and can assist with using terms of use.
Users in scope will need to sign-out and sign-in in order to satisfy a new policy if:
a conditional access policy is enabled on a terms of use
or a second terms of use is created
This is because conditional access policies take effect immediately. When this happens the admin will start to see
“sad clouds” or "Azure AD token issues". The admin must sign-out and sign-in again in order to satisfy the new
policy.
Frequently asked questions

Q: How do I see when/if a user has accepted a terms of use?
A: A user accepting the terms of use is written to the audit log. You can search the Azure AD audit log to see the
results.
Q: If you change the terms of use terms does it require users to accept again?
A: Yes, an admin can change the terms of use terms and it requires reaccepting the new terms.
Q: Can a terms of use support multi languages?
A: No, currently it is not possible to have multiple languages in a single terms of use. However, you can scope to a
group (for example, terms of use for France is different from terms of use for UK).
Q: When is the terms of use triggered?
A: The terms of use is triggered during the sign-in experience.
Q: What applications can I target a terms of use too?
A: You can create a conditional access policy on the enterprise applications using modern authentication. For more
information, see enterprise applications.
Q: Can I add multiple terms of use to a given user or app?
A: Yes, by creating multiple conditional access policies targeting those groups or apps. If a user falls in scope of
multiple terms of use they agree to one terms of use at a time.
Q: What happens if a user declines the terms of use?
A: The user is blocked from getting access to the application. The user would have to sign-in again and agree to the
terms in order to get access.
Azure Active Directory conditional access for VPN
connectivity (preview)
With Azure Active Directory (Azure AD) conditional access, you can fine-tune how authorized users access your
resources. With Azure AD conditional access for virtual private network (VPN) connectivity, you can help protect
your VPN connections.
To configure conditional access for VPN connectivity, you need to complete the following steps:
1. Configure your VPN server.
2. Configure your VPN client.
3. Configure your conditional access policy.
Before you begin

This topic assumes that you're familiar with the following topics:
VPN and conditional access
To gain insights on how Microsoft implements this feature, see Enhancing remote access in Windows 10 with an
automatic VPN profile.
Prerequisites
To configure Azure Active Directory conditional access for VPN connectivity, you need to have a VPN server
configured.
Step 1: Configure your VPN server

This step configures root certificates for VPN authentication with Azure AD. To configure conditional access for VPN
connectivity, you need to:
1. Create a VPN certificate in the Azure portal.
2. Download the VPN certificate.
3. Deploy the certificate to your VPN server.
Azure AD uses the VPN certificate to sign certificates issued to Windows 10 clients when authenticating to Azure AD
for VPN connectivity. The token that the Windows 10 client requests is a certificate that it then presents to the
application, which in this case is the VPN server.
In the Azure portal, you can create two certificates to manage the transition when one certificate is about to expire.
When you create a certificate, you can choose whether it is the primary certificate, which is used during the
authentication to sign the certificate for the connection.
To create a VPN certificate:
1. Sign in to your Azure portal as a global administrator.
2. On the left menu, click Azure Active Directory.
4. On the Conditional access page, in the Manage section, click VPN connectivity (preview).
5. On the VPN connectivity page, click New certificate.
6. On the New page, perform the following steps:
a. For Select duration, select 1 year.

b. For Primary, select Yes.
c. Click Create.
7. On the VPN connectivity page, click Download certificate.
You're now ready to deploy your newly created certificate to your VPN server. On your VPN server, add the
downloaded certificate as a trusted root CA for VPN authentication.
For Windows RRAS-based deployments, on your NPS server, add the root certificate into the Enterprise NTauth
store by running the following commands:
1. certutil -dspublish <CACERT> RootCA
2. certutil -dspublish <CACERT> NtAuthCA
Step 2: Configure your VPN client

In this step, you configure your VPN client connectivity profile as outlined in VPN and conditional access.
Step 3: Configure your conditional access policy

This section provides you with instructions for configuring your conditional access policy for VPN connectivity.
1. On the Conditional Access page, in the toolbar on the top, click Add.
2. On the New page, in the Name box, type a name for your policy. For example, type VPN policy.
3. In the Assignment section, click Users and groups.
4. On the Users and groups page, perform the following steps:
a. Click Select users and groups.

b. Click Select.
c. On the Select page, select your test user, and then click Select.
d. On the Users and groups page, click Done.
5. On the New page, perform the following steps:
a. In the Assignments section, click Cloud apps.
b. On the Cloud apps page, click Select apps, and then click Select.
c. On the Select page, in the Applications box, type vpn.
d. Select VPN Server.
e. Click Select.
6. On the New page, to open the Grant page, in the Controls section, click Grant.
7. On the Grant page, perform the following steps:
a. Select Require multi-factor authentication.

b. Click Select.
8. On the New page, under Enable policy, click On.
9. On the New page, click Create.
Next steps
To gain insights into how Microsoft implements this feature, see Enhancing remote access in Windows 10 with an
automatic VPN profile.
Set up SharePoint Online and Exchange Online for
Azure Active Directory conditional access
With Azure Active Directory (Azure AD) conditional access, you can control how users access your cloud apps. If you
want to use conditional access to control access to SharePoint and Exchange online, you need to:
Review whether your conditional access scenario is supported
Prevent client apps from bypassing the enforcement of your conditional access policies.
This article explains, how you can address both cases.
What you need to know

You can use Azure AD conditional access to protect cloud apps when an authentication attempt comes from:
A web browser
A client app that uses modern authentication
Exchange ActiveSync
Some cloud apps also support legacy authentication protocols. This applies, for example, to SharePoint Online and
Exchange Online. When a client app can use a legacy authentication protocol to access a cloud app, Azure AD
cannot enforce a conditional access policy on this access attempt. To prevent a client app from bypassing the
enforcement of policies, you should check whether it is possible to only enable modern authentication on the
affected cloud apps.
Examples for client apps conditional access does not apply to are:
Office 2010 and earlier
Office 2013 when modern authentication is not enabled
Control access to SharePoint Online

In addition to modern authentication, SharePoint Online also supports legacy authentication protocols. If the legacy
authentication protocols are enabled, your conditional access policies for SharePoint are not enforced for clients
that don't use modern authentication.
You can disable legacy authentication protocols for SharePoint access by using the Set-SPOTenant cmdlet:
Set-SPOTenant -LegacyAuthProtocolsEnabled $false
Control access to Exchange Online

When you set up conditional access policies for Exchange Online, you need to review the following:
Exchange ActiveSync
Legacy authentication protocols
Exchange ActiveSync
While Exchange Active Sync supports modern authentication, there are some limitations regarding the support for
conditional access scenarios:
You can only configure the device platforms condition
Setting the multi-factor authentication requirement is not supported
To effectively protect access to Exchange Online from Exchange ActiveSync, you can:
Configure a supported conditional access policy by following these steps:
a. Select just Office 365 Exchange Online as cloud app.
b. Select Exchange Active Sync as client app, and then select Apply policy only to supported
platforms.
Block Exchange ActiveSync by using Active Directory Federation Services (AD FS) rules.
@RuleName = "Block Exchange ActiveSync"

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application",
Value == "Microsoft.Exchange.ActiveSync"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "false");
Legacy authentication protocols

In addition to modern authentication, Exchange Online also supports legacy authentication protocols. If legacy
authentication protocols are enabled, your conditional access policies for Exchange Online are not enforced for
clients that don't use modern authentication.
You can disable legacy authentication protocols for Exchange Online by setting AD FS rules. This blocks access from:
Older Office clients, such as Office 2013 that don't have modern authentication enabled
Earlier versions of Office
Set up AD FS rules
You can use the following issuance authorization rules to enable or block traffic at the AD FS level.
Block legacy traffic from the extranet
By applying the following three rules:
You enable access for:
Exchange ActiveSync traffic
Browser traffic
Modern authentication traffic
You block access for:
Legacy client apps from the extranet
Rule 1:
@RuleName = "Allow all intranet traffic"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
Rule 2:
@RuleName = "Allow Exchange ActiveSync"

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value ==
"Microsoft.Exchange.ActiveSync"]
Rule 3:
@RuleName = "Allow extranet browser and browser dialog traffic"

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] &&
c2:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~
"(/adfs/ls)|(/adfs/oauth2)"]
Block legacy traffic from anywhere

By applying the following three rules:
You enable access for:
Exchange ActiveSync traffic
Browser traffic
Modern authentication traffic
You block access for:
Legacy apps from any location
Ru l e 1
@RuleName = "Allow all intranet traffic only for browser and modern authentication clients"
c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] &&
Ru l e 2
@RuleName = "Allow Exchange ActiveSync"

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value ==
"Microsoft.Exchange.ActiveSync"]
Ru l e 3
@RuleName = "Allow extranet browser and browser dialog traffic"

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] &&
Next steps
For more information, see Conditional access in Azure Active Directory
You can't get there from here on a Windows device
During an attempt to, for example, access your organization's SharePoint Online intranet you might run into a page
that states that you can't get there from here. You are seeing this page, because your administrator has configured
a conditional access policy that prevents access to your organization's resources under certain conditions. While it
might be necessary to contact helpdesk or your administrator to get this problem solved, there are a few things you
can try out yourself, first.
If you are using a Windows device, you should check the following:
Are you using a supported browser?
Are you running a supported version of Windows on your device?
Is your device compliant?
Supported browser
If your administrator has configured a conditional access policy, you can only access your organization's resources
by using a supported browser. On a Windows device, only Internet Explorer and Edge are supported.
You can easily identify whether you can't access a resource due to an unsupported browser by looking at the details
section of the error page:
The only remediation is to use a browser that the application supports for your device platform. For a complete list
of supported browsers, see supported browsers.
Supported versions of Windows

The following must be true about the Windows operating system on your device:
If you are running a Windows desktop operating system on your device, it needs to be Windows 7 or later.
If you are running a Windows server operating system on your device, it needs to be Windows Server 2008 R2
or later.
Compliant device
Your administrator might have configured a conditional access policy that allows access to your organization's
resources only from compliant devices. To be compliant, your device must be either joined to your on-premises
Active Directory or joined to your Azure Active Directory.
You can easily identify whether you can't access a resource due to a device that is not compliant by looking at the
details section of the error page:
Is your device joined to an on-premises Active Directory?

If your device is joined to an on-premises Active Directory in your organization:
1. Make sure that you sign in to Windows by using your work account (your Active Directory account).
2. Connect to your corporate network via a virtual private network (VPN) or DirectAccess.
3. After you are connected, press the Windows logo key + the L key to lock your Windows session.
4. Unlock your Windows session by entering your work account credentials.
5. Wait for a minute, and then try again to access the application or service.
6. If you see the same page, click the More details link, and then contact your administrator with the details.
Is your device not joined to an on-premises Active Directory?
If your device is not joined to an on-premises Active Directory and runs Windows 10, you have two options:
Run Azure AD Join
Add your work or school account to Windows
For information about how these options are different, see Using Windows 10 devices in your workplace.
If your device:
Belongs to your organization, you should run Azure AD Join.
Is a personal device or a Windows phone, you should add your work or school account to Windows
Azure AD Join on Windows 10
The steps to join your device to Azure AD are tied the version of Windows 10 you are running on it. To determine
the version of your Windows 10 operating system, run the winver command:
Windows 10 Anniversary Update (Version 1607):
1. Open the Settings app.
2. Click Accounts > Access work or school.
3. Click Connect.
4. Click Join this device to Azure AD.
5. Authenticate to your organization, provide multi-factor authentication if prompted, and then follow the steps
that are shown.
6. Sign out, and then sign in with your work account.
7. Try again to access the application.
Windows 10 November 2015 Update (Version 1511):
2. Click System > About.
3. Click Join Azure AD.
that are shown.
5. Sign out, and then sign in with your work account (your Azure AD account).
Workplace Join on Windows 8.1
If your device is not domain-joined and runs Windows 8.1, to do a Workplace Join and enroll in Microsoft Intune, do
the following steps:
1. Open PC Settings.
2. Click Network > Workplace.
3. Click Join.
that are shown.
5. Click Turn on.
Add your work or school account to Windows
Windows 10 Anniversary Update (Version 1607):
2. Click Accounts > Access work or school.
3. Click Connect.
that are shown.
Windows 10 November 2015 Update (Version 1511):
2. Click Accounts > Your accounts.
3. Click Add work or school account.
that are shown.
Next steps
Azure Active Directory conditional access
Azure Active Directory conditional access settings
reference
You can use Azure Active Directory (Azure AD) conditional access to control how authorized users can access your
resources.
This article provides you with support information for the following configuration options in a conditional access
policy:
Cloud applications assignments
Device platform condition
Client applications condition
Approved client application requirement
If this is not the information you are looking for, please leave a comment at the end of this article.
Cloud apps assignments

With conditional access policies, you control how your users access your cloud apps. When you configure a
conditional access policy, you need to select at least one cloud app.
Microsoft cloud applications

You can assign a conditional access policy to the following cloud apps from Microsoft:
Azure Information Protection - Learn more
Azure RemoteApp
Microsoft Dynamics 365
Microsoft Office 365 Yammer
Microsoft Office 365 Exchange Online
Microsoft Office 365 SharePoint Online (includes OneDrive for Business and Project Online)
Microsoft Power BI
Microsoft Visual Studio Team Services
Microsoft Teams
Other applications
In addition to the Microsoft cloud apps, you can assign a conditional access policy to the following types of cloud
apps:
Azure AD-connected applications
Pre-integrated federated software as a service (SaaS) application
Applications that use password single sign-on (SSO)
Line-of-business applications
Applications that use Azure AD Application Proxy
Device platform condition

In a conditional access policy, you can configure the device platform condition to tie the policy to the operating
system on a client. Azure AD conditional access supports the following device platforms:
Android
iOS
Windows Phone
Windows
macOS
Client apps condition

In your conditional access policy, you can configure the client apps condition to tie the policy to the client app that
has initiated an access attempt. Set the client apps condition to grant or block access when an access attempt is
made from the following types of client apps:
Browser
Mobile apps and desktop apps
Supported browsers
In your conditional access policy, you can select Browsers as client app.
This setting works with all browsers. However, to satisfy a device policy, like a compliant device requirement, the
following operating systems and browsers are supported:
OS BROWSERS SUPPORT
Windows 10 Internet Explorer, Edge, Chrome
Windows 8 / 8.1 Internet Explorer, Chrome
Windows 7 Internet Explorer, Chrome
iOS Safari, Intune Managed Browser
Android Chrome, Intune Managed Browser
Windows Phone Internet Explorer, Edge
Windows Server 2016 Internet Explorer, Edge
Windows Server 2016 Chrome Coming soon

OS BROWSERS SUPPORT
Windows Server 2012 R2 Internet Explorer, Chrome
Windows Server 2008 R2 Internet Explorer, Chrome
macOS Chrome, Safari
NOTE
For Chrome support, you must use Windows 10 Creators Update (version 1703) or later.
You can install this extension.
These browsers support device authentication, allowing the device to be identified and validated against a policy.
The device check fails if the browser is running in private mode.
Supported mobile applications and desktop clients
In your conditional access policy, you can select Mobile apps and desktop clients as client app.
This setting has an impact on access attempts made from the following mobile apps and desktop clients:
CLIENT APPS TARGET SERVICE PLATFORM
Azure Remote app Azure Remote App service Windows 10, Windows 8.1, Windows 7,
iOS, Android, and Mac OS X
Dynamics CRM app Dynamics CRM Windows 10, Windows 8.1, Windows 7,
iOS, and Android
Mail/Calendar/People app, Outlook Office 365 Exchange Online Windows 10

2016, Outlook 2013 (with modern
authentication)
MFA and location policy for apps. Any My Apps app service Android and iOS
Device based policies are not supported.
Microsoft Teams Services - this controls Microsoft Teams Windows 10, Windows 8.1, Windows 7,
all services that support Microsoft iOS, Android and macOS
Teams and all its Client Apps - Windows
Desktop, iOS, Android, WP, and web
client
CLIENT APPS TARGET SERVICE PLATFORM
Office 2016 apps, Office 2013 (with Office 365 SharePoint Online Windows 8.1, Windows 7
modern authentication), OneDrive sync
client (see notes)
Office 2016 apps, Universal Office apps, Office 365 SharePoint Online Windows 10
Office 2013 (with modern
authentication), OneDrive sync client
(see notes), Office Groups support is
planned for the future, SharePoint app
support is planned for the future
Office 2016 for macOS (Word, Excel, Office 365 SharePoint Online Mac OS X
PowerPoint, OneNote only). OneDrive
for Business support planned for the
future
Office mobile apps Office 365 SharePoint Online Android, iOS
Office Yammer app Office 365 Yammer Windows 10, iOS, Android
Outlook 2016 (Office for macOS) Office 365 Exchange Online Mac OS X
Outlook 2016, Outlook 2013 (with Office 365 Exchange Online Windows 8.1, Windows 7
modern authentication), Skype for
Business (with modern authentication)
Outlook mobile app Office 365 Exchange Online Android, iOS
PowerBI app. The Power BI app for PowerBI service Windows 10, Windows 8.1, Windows 7,
Android does not currently support and iOS
device-based conditional access.
Skype for Business Office 365 Exchange Online Android, IOS
Visual Studio Team Services app Visual Studio Team Services Windows 10, Windows 8.1, Windows 7,
iOS, and Android

In your conditional access policy, you can require that an access attempt to the selected cloud apps needs to be
made from an approved client app.
This setting applies to the following client apps:
Microsoft Azure Information Protection
Microsoft Excel
Microsoft OneDrive
Microsoft OneNote
Microsoft Outlook
Microsoft Planner
Microsoft PowerPoint
Microsoft SharePoint
Microsoft Skype for Business
Microsoft Teams
Microsoft Visio
Microsoft Word
Remarks
The approved client apps support the Intune mobile application management feature.
The Require approved client app requirement:
Only supports the iOS and Android for device platform condition.
Does not support the Browser option for the client apps condition.
Supersedes the Mobile apps and desktop clients option for the client apps condition when that
option is selected.
Next steps
For an overview of conditional access, see conditional access in Azure Active Directory.
If you are ready to configure conditional access policies in your environment, see the recommended practices for
Azure Active Directory conditional access FAQs
Which applications work with conditional access policies?

For information about applications that work with conditional access policies, see Applications and browsers that
use conditional access rules in Azure Active Directory.
Are conditional access policies enforced for B2B collaboration and

guest users?
Policies are enforced for business-to-business (B2B) collaboration users. However, in some cases, a user might not
be able to satisfy the policy requirements. For example, a guest user's organization might not support multi-factor
authentication.
Does a SharePoint Online policy also apply to OneDrive for Business?

Yes. A SharePoint Online policy also applies to OneDrive for Business.
Why can’t I set a policy on client apps, like Word or Outlook?

A conditional access policy sets requirements for accessing a service. It's enforced when authentication to that
service occurs. The policy is not set directly on a client application. Instead, it is applied when a client calls a service.
For example, a policy set on SharePoint applies to clients calling SharePoint. A policy set on Exchange applies to
Outlook.
Does a conditional access policy apply to service accounts?

Conditional access policies apply to all user accounts. This includes user accounts that are used as service accounts.
Often, a service account that runs unattended can't satisfy the requirements of a conditional access policy. For
example, multi-factor authentication might be required. Service accounts can be excluded from a policy by using
conditional access policy management settings.
Are Graph APIs available for configuring conditional access policies?

Currently, no.
What is the default exclusion policy for unsupported device platforms?

Currently, conditional access policies are selectively enforced on users of iOS and Android devices. Applications on
other device platforms are, by default, not affected by the conditional access policy for iOS and Android devices. A
tenant admin can choose to override the global policy to disallow access to users on platforms that are not
supported.
How do conditional access policies work for Microsoft Teams?

Microsoft Teams relies heavily on Exchange Online and SharePoint Online for core productivity scenarios, like
meetings, calendars, and file sharing. Conditional access policies that are set for these cloud apps apply to Microsoft
Teams when a user signs directly into Microsoft Teams.
Microsoft Teams also is supported separately as a cloud app in Azure Active Directory conditional access policies.
Conditional access policies that are set for a cloud app apply to Microsoft Teams when a user signs in. However,
without the correct policies on other apps like Exchange Online and SharePoint Online users may still be able to
access those resources directly.
Microsoft Teams desktop clients for Windows and Mac support modern authentication. Modern authentication
brings sign-in based on the Azure Active Directory Authentication Library (ADAL) to Microsoft Office client
applications across platforms.
Authenticating identities without passwords through
The current methods of authentication with passwords alone are not sufficient to keep users safe. Users reuse and
forget passwords. Passwords are breachable, phishable, prone to cracks, and guessable. They also get difficult to
remember and prone to attacks like “pass the hash”.
About Windows Hello for Business

Windows Hello for Business is a private/public key or certificate-based authentication approach for organizations
and consumers that goes beyond passwords. This form of authentication relies on key pair credentials that can
replace passwords and are resistant to breaches, thefts, and phishing.
Windows Hello for Business lets a user authenticate to a Microsoft account, a Windows Server Active Directory
account, a Microsoft Azure Active Directory (Azure AD) account, or a non-Microsoft service that supports Fast
IDentity Online (FIDO) authentication. After an initial two-step verification during Windows Hello for Business
enrollment, Windows Hello for Business is set up on the user's device, and the user sets a gesture, which can be
Windows Hello or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello
for Business to authenticate the user and help them to access protected resources and services.
The private key is made available solely through a “user gesture” like a PIN, biometrics, or a remote device like a
smart card that the user uses to sign in to the device. This information is linked to a certificate or an asymmetrical
key pair. The private key is hardware attested if the device has a Trusted Platform Module (TPM) chip. The private
key never leaves the device.
The public key is registered with Azure Active Directory and Windows Server Active Directory (for on-premises).
Identity Providers (IDPs) validate the user by mapping the public key of the user to the private key, and provide
sign-in information through One Time Password (OTP), PhoneFactor, or a different notification mechanism.
Why enterprises should adopt Windows Hello for Business

By enabling Windows Hello for Business, enterprises can make their resources even more secure by:
Setting up Windows Hello for Business with a hardware-preferred option. This means that keys will be
generated on TPM 1.2 or TPM 2.0 when available. When TPM is not available, software will generate the key.
Defining the complexity and length of the PIN, and whether Hello usage is enabled in your organization.
Configuring Windows Hello for Business to support smart card-like scenarios by using certificate-based trust.
How Windows Hello for Business works

1. Keys are generated on the hardware by TPM or software. Many devices have a built-in TPM chip that secures the
hardware by integrating cryptographic keys into devices. TPM 1.2 or TPM 2.0 generates keys or certificates that
are created from the generated keys.
2. The TPM attests these hardware-bound keys.
3. A single unlock gesture unlocks the device. This gesture allows access to multiple resources if the device is
domain-joined or Azure AD-joined.
How the Windows Hello for Business lifecycle works

The preceding diagram illustrates the private/public key pair and the validation by the identity provider. Each of
these steps is explained in detail here:
1. The user proves their identity through multiple built-in proofing methods (gestures, physical smart cards, multi-
factor authentication) and sends this information to an Identity Provider (IDP) like Azure Active Directory or on-
premises Active Directory.
2. The device then creates the key, attests the key, takes the public portion of this key, attaches it with station
statements, signs in, and sends it to the IDP to register the key.
3. As soon as the IDP registers the public portion of the key, the IDP challenges the device to sign with the private
portion of the key.
4. The IDP then validates and issues the authentication token that lets the user and the device access the protected
resources. IDPs can write cross-platform apps or use browser support (via JavaScript/Webcrypto APIs) to create
and use Windows Hello for Business credentials for their users.
The deployment requirements for Windows Hello for Business

At the enterprise level
The enterprise has an Azure subscription.
At the user level
The user's computer runs Windows 10 Professional or Enterprise.
For detailed deployment instructions, see Enable Windows Hello for Business in the organization.
Enable Microsoft Windows Hello for Business in your
organization
After connecting Windows 10 domain-joined devices with Azure Active Directory, do the following to enable
Microsoft Windows Hello for Business in your organization:
1. Deploy System Center Configuration Manager
2. Configure policy settings
3. Configure the certificate profile
Deploy System Center Configuration Manager

To deploy user certificates based on Windows Hello for Business keys, you need the following:
System Center Configuration Manager Current Branch - You need to install version 1606 or better. For
more information, see the Documentation for System Center Configuration Manager and System Center
Configuration Manager Team Blog.
Public key infrastructure (PKI) - To enable Microsoft Windows Hello for Business by using user certificates,
you must have a PKI in place. If you don’t have one, or you don’t want to use it for user certificates, you can
deploy a new domain controller that has Windows Server 2016 build 10551 (or better) installed. Follow the
steps to install a replica domain controller in an existing domain or to install a new Active Directory forest, if
you're creating a new environment. (The ISOs are available for download on Signiant Media Exchange.)
Configure policy settings

To configure the Microsoft Windows Hello for Business policy settings, you have two options:
Group Policy in Active Directory
The System Center Configuration Manager
Using Group Policy in Active Directory is the recommended method to configure Microsoft Windows Hello for
Business policy settings.
Using System Center Configuration Manager is the preferred method when you also use it to deploy certificates.
This scenario:
Ensures compatibility with the newer deployment scenarios
Requires on the client side Windows 10 Version 1607 or better.
Configure Microsoft Windows Hello for Business via group policy in Active Directory
Steps:
1. Open Server Manager, and navigate to Tools > Group Policy Management.
2. From Group Policy Management, navigate to the domain node that corresponds to the domain in which you
want to enable Azure AD Join.
3. Right-click Group Policy Objects, and select New. Give your Group Policy Object a name, for example, Enable
Windows Hello for Business. Click OK.
4. Right-click your new Group Policy Object, and then select Edit.
5. Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components >
Windows Hello for Business.
6. Right-click Enable Windows Hello for Business, and then select Edit.
7. Select the Enabled option button, and then click Apply. Click OK.
8. You can now link the Group Policy Object to a location of your choice. To enable this policy for all of the
domain-joined Windows 10 devices in your organization, link the Group Policy to the domain. For example:
A specific organizational unit (OU) in Active Directory where Windows 10 domain-joined computers will
be located
A specific security group that contains Windows 10 domain-joined computers that will be automatically
registered with Azure AD
Configure Windows Hello for Business using System Center Configuration Manager
Steps:
1. Open the System Center Configuration Manager, and then navigate to Assets & Compliance >
Compliance Settings > Company Resource Access > Windows Hello for Business Profiles.
2. In the toolbar on the top, click Create Windows Hello for business Profile.
3. On the General dialog, perform the following steps:

a. In the Name textbox, type a name for your profile, for example, My WHfB Profile.
b. Click Next.
4. On the Supported Platforms dialog, select the platforms that will be provisioned with this Windows Hello
for business profile, and then click Next.
5. On the Settings dialog, perform the following steps:
a. As Configure Windows Hello for Business, select Enabled.
b. As Use a Trusted Platform Module (TPM), select Required.
c. As Authentication method, select Certificate-based.
d. Click Next.
6. On the Summary dialog, click Next.
7. On the Completion dialog, click Close.
8. In the toolbar on the top, click Deploy.
Configure the certificate profile

If you are using certificate-based authentication for on-premises authentication, you need to configure and deploy
a certificate profile. This task requires you to set up an NDES server and Certificate Registration Point site role in
the System Center Configuration Manager. For more details, see the Prerequisites for Certificate Profiles in
Configuration Manager.
1. Open the System Center Configuration Manager, and then navigate to Assets & Compliance >
Compliance Settings > Company Resource Access > Certificate Profiles.
2. Select a template that has Smart Card sign-in extended key usage (EKU).
On the SCEP Enrollment page of the certificate profile, you need to choose Install to Passport for Work
otherwise fail as the Key Storage Provider.
Next steps
Authenticate without passwords
Azure Active Directory certificate-based
authentication on Android
Certificate-based authentication (CBA) enables you to be authenticated by Azure Active Directory with a client
certificate on a Windows, Android or iOS device when connecting your Exchange online account to:
Office mobile applications such as Microsoft Outlook and Microsoft Word
Exchange ActiveSync (EAS) clients
Configuring this feature eliminates the need to enter a username and password combination into certain mail and
Microsoft Office applications on your mobile device.
This topic provides you with the requirements and the supported scenarios for configuring CBA on an iOS(Android)
device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China, and Germany
plans.
This feature is available in preview in Office 365 US Government Defense and Federal plans.
Microsoft mobile applications support

APPS SUPPORT
Azure Information Protection app
Intune Company Portal
Microsoft Teams
OneNote
OneDrive
Outlook
Power BI
Skype for Business
Word / Excel / PowerPoint
Yammer
Implementation requirements
The device OS version must be Android 5.0 (Lollipop) and above.
A federation server must be configured.
For Azure Active Directory to revoke a client certificate, the ADFS token must have the following claims:
http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber>
(The serial number of the client certificate)
http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer>
(The string for the issuer of the client certificate)
Azure Active Directory adds these claims to the refresh token if they are available in the ADFS token (or any other
SAML token). When the refresh token needs to be validated, this information is used to check the revocation.
As a best practice, you should update the ADFS error pages with instructions on how to get a user certificate.
For more details, see Customizing the AD FS Sign-in Pages.
Some Office apps (with modern authentication enabled) send ‘prompt=login’ to Azure AD in their request. By
default, Azure AD translates this in the request to ADFS to ‘wauth=usernamepassworduri’ (asks ADFS to do U/P
auth) and ‘wfresh=0’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable
certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set the
‘PromptLoginBehavior’ in your federated domain settings to ‘Disabled‘. You can use the
MSOLDomainFederationSettings cmdlet to perform this task:
Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
Exchange ActiveSync clients support

Certain Exchange ActiveSync applications on Android 5.0 (Lollipop) or later are supported. To determine if your
email application does support this feature, please contact your application developer.
Next steps
If you want to configure certificate-based authentication in your environment, see Get started with certificate-based
authentication on Android for instructions.
Azure Active Directory certificate-based
authentication on iOS
Certificate-based authentication (CBA) enables you to be authenticated by Azure Active Directory with a client
certificate on a Windows, Android or iOS device when connecting your Exchange online account to:
Office mobile applications such as Microsoft Outlook and Microsoft Word
This topic provides you with the requirements and the supported scenarios for configuring CBA on an iOS(Android)
device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China, and Germany
plans.
This feature is available in preview in Office 365 US Government Defense and Federal plans.
Microsoft mobile applications support

APPS SUPPORT
Azure Information Protection app
Intune Company Portal
Microsoft Teams
OneNote
OneDrive
Outlook
Power BI
Skype for Business
Word / Excel / PowerPoint
Yammer
Requirements
The device OS version must be iOS 9 and above
A federation server must be configured.
Microsoft Authenticator is required for Office applications on iOS.
For Azure Active Directory to revoke a client certificate, the ADFS token must have the following claims:
http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber>
(The serial number of the client certificate)
http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer>
(The string for the issuer of the client certificate)
Azure Active Directory adds these claims to the refresh token if they are available in the ADFS token (or any other
SAML token). When the refresh token needs to be validated, this information is used to check the revocation.
As a best practice, you should update the ADFS error pages with the following:
The requirement for installing the Microsoft Authenticator on iOS
Instructions on how to get a user certificate.
For more details, see Customizing the AD FS Sign-in Pages.
Some Office apps (with modern authentication enabled) send ‘prompt=login’ to Azure AD in their request. By
default, Azure AD translates this in the request to ADFS to ‘wauth=usernamepassworduri’ (asks ADFS to do U/P
auth) and ‘wfresh=0’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable
certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set the
‘PromptLoginBehavior’ in your federated domain settings to ‘Disabled‘. You can use the
MSOLDomainFederationSettings cmdlet to perform this task:
Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled
Exchange ActiveSync clients support

On iOS 9 or later, the native iOS mail client is supported. For all other Exchange ActiveSync applications, to
determine if this feature is supported, contact your application developer.
Next steps
If you want to configure certificate-based authentication in your environment, see Get started with certificate-based
authentication on Android for instructions.
Get started with certificate-based authentication in
Certificate-based authentication enables you to be authenticated by Azure Active Directory with a client certificate
on a Windows, Android or iOS device when connecting your Exchange online account to:
Microsoft mobile applications such as Microsoft Outlook and Microsoft Word
This topic:
Provides you with the steps to configure and utilize certificate-based authentication for users of tenants in
Office 365 Enterprise, Business, Education, and US Government plans. This feature is available in preview in
Office 365 China, US Government Defense, and US Government Federal plans.
Assumes that you already have a public key infrastructure (PKI) and AD FS configured.
Requirements
To configure certificate-based authentication, the following must be true:
Certificate-based authentication (CBA) is only supported for Federated environments for browser
applications or native clients using modern authentication (ADAL). The one exception is Exchange Active
Sync (EAS) for EXO which can be used for both, federated and managed accounts.
The root certificate authority and any intermediate certificate authorities must be configured in Azure Active
Directory.
Each certificate authority must have a certificate revocation list (CRL) that can be referenced via an Internet
facing URL.
You must have at least one certificate authority configured in Azure Active Directory. You can find related
steps in the Configure the certificate authorities section.
For Exchange ActiveSync clients, the client certificate must have the user’s routable email address in
Exchange online in either the Principal Name or the RFC822 Name value of the Subject Alternative Name
field. Azure Active Directory maps the RFC822 value to the Proxy Address attribute in the directory.
Your client device must have access to at least one certificate authority that issues client certificates.
A client certificate for client authentication must have been issued to your client.
Step 1: Select your device platform

As a first step, for the device platform you care about, you need to review the following:
The Office mobile applications support
The specific implementation requirements
The related information exists for the following device platforms:
Android
iOS
Step 2: Configure the certificate authorities

To configure your certificate authorities in Azure Active Directory, for each certificate authority, upload the
following:
The public portion of the certificate, in .cer format
The Internet facing URLs where the Certificate Revocation Lists (CRLs) reside
The schema for a certificate authority looks as follows:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
For the configuration, you can use the Azure Active Directory PowerShell Version 2:
1. Start Windows PowerShell with administrator privileges.
2. Install the Azure AD module. You need to install Version 2.0.0.33 or higher.
Install-Module -Name AzureAD –RequiredVersion 2.0.0.33
As a first configuration step, you need to establish a connection with your tenant. As soon as a connection to your
tenant exists, you can review, add, delete and modify the trusted certificate authorities that are defined in your
directory.
Connect
To establish a connection with your tenant, use the Connect-AzureAD cmdlet:
Connect-AzureAD
Retrieve
To retrieve the trusted certificate authorities that are defined in your directory, use the Get-
AzureADTrustedCertificateAuthority cmdlet.
Get-AzureADTrustedCertificateAuthority
Add
To create a trusted certificate authority, use the New-AzureADTrustedCertificateAuthority cmdlet and set the
crlDistributionPoint attribute to a correct value:
$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]"

$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert
$new_ca.crlDistributionPoint=”<CRL Distribution URL>”
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
Remove
To remove a trusted certificate authority, use the Remove-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]
Modfiy
To modify a trusted certificate authority, use the Set-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
$c[0].AuthorityType=1
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
Step 3: Configure revocation

To revoke a client certificate, Azure Active Directory fetches the certificate revocation list (CRL) from the URLs
uploaded as part of certificate authority information and caches it. The last publish timestamp (Effective Date
property) in the CRL is used to ensure the CRL is still valid. The CRL is periodically referenced to revoke access to
certificates that are a part of the list.
If a more instant revocation is required (for example, if a user loses a device), the authorization token of the user
can be invalidated. To invalidate the authorization token, set the StsRefreshTokenValidFrom field for this
particular user using Windows PowerShell. You must update the StsRefreshTokenValidFrom field for each user
you want to revoke access for.
To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by
StsRefreshTokenValidFrom and ensure the certificate in question is in the CRL.
The following steps outline the process for updating and invalidating the authorization token by setting the
StsRefreshTokenValidFrom field.
To configure revocation:
1. Connect with admin credentials to the MSOL service:
$msolcred = get-credential
connect-msolservice -credential $msolcred
2. Retrieve the current StsRefreshTokensValidFrom value for a user:

$user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
$user.StsRefreshTokensValidFrom
3. Configure a new StsRefreshTokensValidFrom value for the user equal to the current timestamp:
Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2016")
The date you set must be in the future. If the date is not in the future, the StsRefreshTokensValidFrom property is
not set. If the date is in the future, StsRefreshTokensValidFrom is set to the current time (not the date indicated
by Set-MsolUser command).
Step 4: Test your configuration

Testing your certificate
As a first configuration test, you should try to sign in to Outlook Web Access or SharePoint Online using your on-
device browser.
If your sign-in is successful, then you know that:
The user certificate has been provisioned to your test device
AD FS is configured correctly
Testing Office mobile applications
To test certificate-based authentication on your mobile Office application:
1. On your test device, install an Office mobile application (e.g., OneDrive).
2. Launch the application.
3. Enter your user name, and then select the user certificate you want to use.
You should be successfully signed in.
Testing Exchange ActiveSync client applications
To access Exchange ActiveSync (EAS) via certificate-based authentication, an EAS profile containing the client
certificate must be available to the application.
The EAS profile must contain the following information:
The user certificate to be used for authentication
The EAS endpoint (for example, outlook.office365.com)
An EAS profile can be configured and placed on the device through the utilization of Mobile device management
(MDM) such as Intune or by manually placing the certificate in the EAS profile on the device.
Testing EAS client applications on Android
To test certificate authentication:
1. Configure an EAS profile in the application that satisfies the requirements above.
2. Open the application, and verify that mail is synchronizing.
Azure Active Directory Identity Protection
Azure Active Directory Identity Protection is a feature of the Azure AD Premium P2 edition that enables you to:
Detect potential vulnerabilities affecting your organization’s identities
Configure automated responses to detected suspicious actions that are related to your organization’s
identities
Investigate suspicious incidents and take appropriate action to resolve them
Getting started
Microsoft has secured cloud-based identities for more than a decade. With Azure Active Directory Identity
Protection, in your environment, you can use the same protection systems Microsoft uses to secure identities.
The vast majority of security breaches take place when attackers gain access to an environment by stealing a
user’s identity. Over the years, attackers have become increasingly effective in leveraging third party breaches
and using sophisticated phishing attacks. As soon as an attacker gains access to even low privileged user
accounts, it is relatively easy for them to gain access to important company resources through lateral
movement.
As a consequence of this, you need to:
Protect all identities regardless of their privilege level
Proactively prevent compromised identities from being abused
Discovering compromised identities is no easy task. Azure Active Directory uses adaptive machine learning
algorithms and heuristics to detect anomalies and suspicious incidents that indicate potentially compromised
identities. Using this data, Identity Protection generates reports and alerts that enable you to evaluate the
detected issues and take appropriate mitigation or remediation actions.
Azure Active Directory Identity Protection is more than a monitoring and reporting tool. To protect your
organization's identities, you can configure risk-based policies that automatically respond to detected issues
when a specified risk level has been reached. These policies, in addition to other conditional access controls
provided by Azure Active Directory and EMS, can either automatically block or initiate adaptive remediation
actions including password resets and multi-factor authentication enforcement.
Identity Protection capabilities
Detecting vulnerabilities and risky accounts:
Providing custom recommendations to improve overall security posture by highlighting vulnerabilities
Calculating sign-in risk levels
Calculating user risk levels
Investigating risk events:
Sending notifications for risk events
Investigating risk events using relevant and contextual information
Providing basic workflows to track investigations
Providing easy access to remediation actions such as password reset
Risk-based conditional access policies:
Policy to mitigate risky sign-ins by blocking sign-ins or requiring multi-factor authentication challenges
Policy to block or secure risky user accounts
Policy to require users to register for multi-factor authentication
Identity Protection roles

To load balance the management activities around your Identity Protection implementation, you can assign
several roles. Azure AD Identity Protection supports 3 directory roles:
ROLE CAN DO CANNOT DO
Global administrator Full access to Identity Protection,

Onboard Identity Protection
Security administrator Full access to Identity Protection Onboard Identity Protection, reset
passwords for a user
Security reader Read-only access to Identity Onboard Identity Protection, remidiate

Protection users, configure policies, reset
passwords
For more details, see Assigning administrator roles in Azure Active Directory
Detection
Vulnerabilities
Azure Active Directory Identity Protection analyses your configuration and detects vulnerabilities that can have
an impact on your user's identities. For more details, see Vulnerabilities detected by Azure Active Directory
Identity Protection.
Risk events
Azure Active Directory uses adaptive machine learning algorithms and heuristics to detect suspicious actions
that are related to your user's identities. The system creates a record for each detected suspicious action. These
records are also known as risk events.
For more details, see Azure Active Directory risk events.
Investigation
Your journey through Identity Protection typically starts with the Identity Protection dashboard.
The dashboard gives you access to:
Reports such as Users flagged for risk, Risk events and Vulnerabilities
Settings such as the configuration of your Security Policies, Notifications and multi-factor
authentication registration
It is typically your starting point for investigation, which is the process of reviewing the activities, logs, and
other relevant information related to a risk event to decide whether remediation or mitigation steps are
necessary, and how the identity was compromised, and understand how the compromised identity was used.
You can tie your investigation activities to the notifications Azure Active Directory Protection sends per email.
The following sections provide you with more details and the steps that are related to an investigation.
Risky sign-ins
Azure Active Directory detects risk event types in real-time and offline. Each risk event that has been detected
for a sign-in of a user contributes to a logical concept called risky sign-in. A risky sign-in is an indicator for a
sign-in attempt that might not have been performed by the legitimate owner of a user account.
Sign-in risk level
A sign-in risk level is an indication (High, Medium, or Low) of the likelihood that a sign-in attempt was not
performed by the legitimate owner of a user account.
Mitigating sign-in risk events
A mitigation is an action to limit the ability of an attacker to exploit a compromised identity or device without
restoring the identity or device to a safe state. A mitigation does not resolve previous sign-in risk events
associated with the identity or device.
To mitigate risky sign-ins automatically, you can configure sign-in risk security policies. Using these policies,
you consider the risk level of the user or the sign-in to block risky sign-ins or require the user to perform multi-
factor authentication. These actions may prevent an attacker from exploiting a stolen identity to cause damage,
and may give you some time to secure the identity.
Sign-in risk security policy
A sign-in risk policy is a conditional access policy that evaluates the risk to a specific sign-in and applies
mitigations based on predefined conditions and rules.
Azure AD Identity Protection helps you manage the mitigation of risky sign-ins by enabling you to:
Set the users and groups the policy applies to:
Set the sign-in risk level threshold (low, medium, or high) that triggers the policy:
Set the controls to be enforced when the policy triggers:

Switch the state of your policy:
Review and evaluate the impact of a change before activating it:
What you need to know

You can configure a sign-in risk security policy to require multi-factor authentication:
However, for security reasons, this setting only works for users that have already been registered for multi-
factor authentication. If the condition to require multi-factor authentication is satisfied for a user who is not yet
registered for multi-factor authentication, the user is blocked.
As a best practice, if you want to require multi-factor authentication for risky sign-ins, you should:
1. Enable the multi-factor authentication registration policy for the affected users.
2. Require the affected users to login in a non-risky session to perform a MFA registration
Completing these steps ensures that multi-factor authentication is required for a risky sign-in.
Best practices
Choosing a High threshold reduces the number of times a policy is triggered and minimizes the impact to
users.
However, it excludes Low and Medium sign-ins flagged for risk from the policy, which may not block an
attacker from exploiting a compromised identity.
When setting the policy,
Exclude users who do not/cannot have multi-factor authentication
Exclude users in locales where enabling the policy is not practical (for example no access to helpdesk)
Exclude users who are likely to generate a lot of false-positives (developers, security analysts)
Use a High threshold during initial policy roll out, or if you must minimize challenges seen by end users.
Use a Low threshold if your organization requires greater security. Selecting a Low threshold introduces
additional user sign-in challenges, but increased security.
The recommended default for most organizations is to configure a rule for a Medium threshold to strike a
balance between usability and security.
The sign-in risk policy is:
Applied to all browser traffic and sign-ins using modern authentication.
Not applied to applications using older security protocols by disabling the WS-Trust endpoint at the
federated IDP, such as ADFS.
The Risk Events page in the Identity Protection console lists all events:
This policy was applied to
You can review the activity and determine whether the action was appropriate or not
For an overview of the related user experience, see:
Risky sign-in recovery
Risky sign-in blocked
Sign-in experiences with Azure AD Identity Protection
To open the related configuration dialog:
On the Azure AD Identity Protection blade, in the Configure section, click Sign-in risk policy.
Users flagged for risk

All active risk events that were detected by Azure Active Directory for a user contribute to a logical concept
called user risk. A user flagged for risk is an indicator for a user account that might have been compromised.
User risk level
A user risk level is an indication (High, Medium, or Low) of the likelihood that the user’s identity has been
compromised. It is calculated based on the user risk events that are associated with a user's identity.
The status of a risk event is either Active or Closed. Only risk events that are Active contribute to the user risk
level calculation.
The user risk level is calculated using the following inputs:
Active risk events impacting the user
Risk level of these events
Whether any remediation actions have been taken
You can use the user risk levels to create conditional access policies that block risky users from signing in, or
force them to securely change their password.
Closing risk events manually
In most cases, you will take remediation actions such as a secure password reset to automatically close risk
events. However, this might not always be possible.
This is, for example, the case, when:
A user with Active risk events has been deleted
An investigation reveals that a reported risk event has been perform by the legitimate user
Because risk events that are Active contribute to the user risk calculation, you may have to manually lower a
risk level by closing risk events manually.
During the course of investigation, you can choose to take any of these actions to change the status of a risk
event:
Resolve - If after investigating a risk event, you took an appropriate remediation action outside Identity
Protection, and you believe that the risk event should be considered closed, mark the event as Resolved.
Resolved events will set the risk event’s status to Closed and the risk event will no longer contribute to user
risk.
Mark as false-positive - In some cases, you may investigate a risk event and discover that it was
incorrectly flagged as a risky. You can help reduce the number of such occurrences by marking the risk
event as False-positive. This will help the machine learning algorithms to improve the classification of
similar events in the future. The status of false-positive events is to Closed and they will no longer
contribute to user risk.
Ignore - If you have not taken any remediation action, but want the risk event to be removed from the
active list, you can mark a risk event Ignore and the event status will be Closed. Ignored events do not
contribute to user risk. This option should only be used under unusual circumstances.
Reactivate - Risk events that were manually closed (by choosing Resolve, False positive, or Ignore) can
be reactivated, setting the event status back to Active. Reactivated risk events contribute to the user risk
level calculation. Risk events closed through remediation (such as a secure password reset) cannot be
reactivated.
1. On the Azure AD Identity Protection blade, under Investigate, click Risk events.
2. In the Risk events list, click a risk.
3. On the risk blade, right-click a user.

Closing all risk events for a user manually
Instead of manually closing risk events for a user individually, Azure Active Directory Identity Protection also
provides you with a method to close all events for a user with one click.
When you click Dismiss all events, all events are closed and the affected user is no longer at risk.
Remediating user risk events
A remediation is an action to secure an identity or a device that was previously suspected or known to be
compromised. A remediation action restores the identity or device to a safe state, and resolves previous risk
events associated with the identity or device.
To remediate user risk events, you can:
Perform a secure password reset to remediate user risk events manually
Configure a user risk security policy to mitigate or remediate user risk events automatically
Re-image the infected device
Manual secure password reset
A secure password reset is an effective remediation for many risk events, and when performed, automatically
closes these risk events and recalculates the user risk level. You can use the Identity Protection dashboard to
initiate a password reset for a risky user.
The related dialog provides two different methods to reset a password:
Reset password - Select Require the user to reset their password to allow the user to self-recover if the
user has registered for multi-factor authentication. During the user's next sign-in, the user will be required to
solve a multi-factor authentication challenge successfully and then, forced to change the password. This option
isn't available if the user account is not already registered multi-factor authentication.
Temporary password - Select Generate a temporary password to immediately invalidate the existing
password, and create a new temporary password for the user. Send the new temporary password to an
alternate email address for the user or to the user's manager. Because the password is temporary, the user will
be prompted to change the password upon sign-in.

1. On the Azure AD Identity Protection blade, click Users flagged for risk.
2. From the list of users, select a user with at least one risk events.
3. On the user blade, click Reset password.

User risk security policy
A user risk security policy is a conditional access policy that evaluates the risk level to a specific user and applies
remediation and mitigation actions based on predefined conditions and rules.
Azure AD Identity Protection helps you manage the mitigation and remediation of users flagged for risk by
enabling you to:
Set the user risk level threshold (low, medium, or high) that triggers the policy:
Set the controls to be enforced when the policy triggers:
Review and evaluate the impact of a change before activating it:
Choosing a High threshold reduces the number of times a policy is triggered and minimizes the impact to
users. However, it excludes Low and Medium users flagged for risk from the policy, which may not secure
identities or devices that were previously suspected or known to be compromised.
When setting the policy,
Exclude users who are likely to generate a lot of false-positives (developers, security analysts)
Exclude users in locales where enabling the policy is not practical (for example no access to helpdesk)
Use a High threshold during initial policy roll out, or if you must minimize challenges seen by end users.
Use a Low threshold if your organization requires greater security. Selecting a Low threshold introduces
additional user sign-in challenges, but increased security.
The recommended default for most organizations is to configure a rule for a Medium threshold to strike a
balance between usability and security.
Compromised account recovery flow.
Compromised account blocked flow.
On the Azure AD Identity Protection blade, in the Configure section, click User risk policy.
Mitigating user risk events
Administrators can set a user risk security policy to block users upon sign-in depending on the risk level.
Blocking a sign-in:
Prevents the generation of new user risk events for the affected user
Enables administrators to manually remediate the risk events affecting the user's identity and restore it to a
secure state
Multi-factor authentication registration policy

Azure multi-factor authentication is a method of verifying who you are that requires the use of more than just a
username and password. It provides a second layer of security to user sign-ins and transactions.
We recommend that you require Azure multi-factor authentication for user sign-ins because it:
Delivers strong authentication with a range of easy verification options
Plays a key role in preparing your organization to protect and recover from account compromises
For more details, see What is Azure Multi-Factor Authentication?

Azure AD Identity Protection helps you manage the roll-out of multi-factor authentication registration by
configuring a policy that enables you to:
Set the controls to be enforced when the policy triggers::

View the current registration status:

Multi-factor authentication registration flow.
Sign-in experiences with Azure AD Identity Protection.
On the Azure AD Identity Protection blade, in the Configure section, click Multi-factor
authentication registration.
Next steps
Channel 9: Azure AD and Identity Show: Identity Protection Preview
Enabling Azure Active Directory Identity Protection
Vulnerabilities detected by Azure Active Directory Identity Protection
Azure Active Directory risk events
Azure Active Directory Identity Protection notifications
Azure Active Directory Identity Protection playbook
Azure Active Directory Identity Protection glossary
Sign-in experiences with Azure AD Identity Protection
Azure Active Directory Identity Protection - How to unblock users
Get started with Azure Active Directory Identity Protection and Microsoft Graph
Enabling Azure Active Directory Identity Protection
Azure Active Directory Identity Protection is a new capability that provides a consolidated view into suspicious sign-
in activities and potential vulnerabilities and with notifications, remediation recommendations and risk-based
policies helps you protect your business.
The service detects suspicious activities for end user and privileged (admin) identities based on signals like brute
force attacks, leaked credentials, sign ins from unfamiliar locations, infected devices, to protect against these
activities in real-time. More importantly, based on these suspicious activities, a user risk severity is computed and
risk-based policies can be configured and automatically protect the identities of your organization. For more details,
see Azure Active Directory Identity Protection.
This topics shows how to enable Azure Active Directory Identity Protection.
Steps to enable Azure Active Directory Identity Protection

1. Sign-on to your Azure portal as global administrator.
2. In the Azure portal, click Marketplace.
3. In the applications list, click Security + Identity.

4. Click Azure AD Identity Protection.
5. On the Azure AD Identity Protection blade, click Create.

Next Steps
Vulnerabilities detected by Azure Active Directory
Identity Protection
Vulnerabilities are weaknesses in your environment that can be exploited by an attacker. We recommend that you
address these vulnerabilities to improve the security posture of your organization, and prevent attackers from
exploiting them.
The following sections provide you with an overview of the vulnerabilities reported by Identity Protection.
Multi-factor authentication registration not configured

This vulnerability helps you control the deployment of Azure Multi-Factor Authentication in your organization.
Azure multi-factor authentication provides a second layer of security to user authentication. It helps safeguard
access to data and applications while meeting user demand for a simple sign-in process. It delivers strong
authentication via a range of easy verification options—phone call, text message, or mobile app notification or
verification code and 3rd party OATH tokens.
We recommend that you require Azure Multi-Factor Authentication for user sign-ins. Multi-factor authentication
plays a key role in risk-based conditional access policies available through Identity Protection.
For more details, see What is Azure Multi-Factor Authentication?
Unmanaged cloud apps

This vulnerability helps you identify unmanaged cloud apps in your organization.
In modern enterprises, IT departments are often unaware of all the cloud applications that users in their
organization are using to do their work. It is easy to see why administrators would have concerns about
unauthorized access to corporate data, possible data leakage and other security risks.
We recommend that your organization deploy Cloud App Discovery to discover unmanaged cloud applications,
and to manage these applications using Azure Active Directory.
For more details, see Finding unmanaged cloud applications with Cloud App Discovery.
Security Alerts from Privileged Identity Management
This vulnerability helps you discover and resolve alerts about privileged identities in your organization.
To enable users to carry out privileged operations, organizations need to grant users temporary or permanent
privileged access in Azure AD, Azure or Office 365 resources, or other SaaS apps. Each of these privileged users
increases the attack surface of your organization. This vulnerability helps you identify users with unnecessary
privileged access, and take appropriate action to reduce or eliminate the risk they pose.
We recommend that your organization uses Azure AD Privileged Identity Management to manage, control, and
monitor privileged identities and their access to resources in Azure AD as well as other Microsoft online services
like Office 365 or Microsoft Intune.
For more details, see Azure AD Privileged Identity Management.
See also
1 min to read •
Edit O nline
notifications
Azure AD Identity Protection sends two types of automated notification emails to help you manage user risk and
risk events:
Users at risk detected email
Weekly digest email
This article provides you with an overview of both notification emails.
Users at risk detected email

In response to a detected account at risk, Azure AD Identity Protection generates an email alert with Users at risk
detected as subject. The email includes a link to the Users flagged for risk report. As a best practice, you should
immediately investigate the users at risk.
Configuration
As an administrator, you can set:
The risk level that triggers the generation of this email - By default, the risk level is set to “High” risk.
The recipients of this email - By default, recipients include all Global Admins. Global Admins can also add
other Global Admins, Security Admins, Security Readers as recipients.
To open the related dialog, click Alerts in the Settings section of the Identity Protection page.
Weekly digest email
The weekly digest email contains a summary of new risk events.
It includes:
Users at risk
Suspicious activities
Detected vulnerabilities
Links to the related reports in Identity Protection
Configuration
As an administrator, you can switch sending a weekly digest email off.
To open the related dialog, click Weekly Digest in the Settings section of the Identity Protection page.
See also
Sign-in experiences with Azure AD Identity
Protection
With Azure Active Directory Identity Protection, you can:

require users to register for multi-factor authentication
handle risky sign-ins and compromised users
The response of the system to these issues has an impact on a user's sign-in experience because just directly
signing-in by providing a user name and a password won't be possible anymore. Additional steps are required to
get a user safely back into business.
This topic gives you an overview of a user's sign-in experience for all cases that can occur.
Multi-factor authentication registration
Sign-in at risk
Multi-factor authentication registration during a risky sign-in
User at risk
Compromised account recovery
Compromised account blocked
Multi-factor authentication registration

The best user experience for both, the compromised account recovery flow and the risky sign-in flow, is when the
user can self-recover. If users are registered for multi-factor authentication, they already have a phone number
associated with their account that can be used to pass security challenges. No help desk or administrator
involvement is needed to recover from account compromise. Thus, it’s highly recommended to get your users
registered for multi-factor authentication.
Administrators can:
set a policy that requires users to set up their accounts for additional security verification.
allow skipping multi-factor authentication registration for up to 30 days, in case they want to give users a grace
period before registering.
The multi-factor authentication registration has three steps:
1. In the first step, the user gets a notification about the requirement to set the account up for multi-factor
authentication.
2. To set multi-factor authentication up, you need to let the system know how you want to be contacted.
3. The system submits a challenge to you and you need to respond.

When an administrator has configured a policy for sign-in risks, the affected users are notified when they try to
sign-in.
The risky sign-in flow has two steps:
1. The user is informed that something unusual was detected about their sign-in, such as signing in from a
new location, device, or app.
2. The user is required to prove their identity by solving a security challenge. If the user is registered for multi-
factor authentication they need to round-trip a security code to their phone number. Since this is a just a
risky sign in and not a compromised account, the user won’t have to change the password in this flow.
Administrators can also choose to set a Sign-In Risk policy to block users upon sign-in depending on the risk level.
To get unblocked, end users must contact an administrator or help desk, or they can try signing in from a familiar
location or device. Self-recovering by solving multi-factor authentication is not an option in this case.
Compromised account recovery

When a user risk security policy has been configured, users who meet the user risk level specified in the policy
(and are therefore assumed compromised) must go through the user compromise recovery flow before they can
sign-in.
The user compromise recovery flow has three steps:
1. The user is informed that their account security is at risk because of suspicious activity or leaked credentials.
2. The user is required to prove their identity by solving a security challenge. If the user is registered for multi-
factor authentication they can self-recover from being compromised. They will need to round-trip a security
code to their phone number.
3. Finally, the user is forced to change their password since someone else may have had access to their
account. Screenshots of this experience are below.
Compromised account blocked
To get a user that was blocked by a user risk security policy unblocked, the user must contact an administrator or
help desk. Self-recovering by solving multi-factor authentication is not an option in this case.
Reset password
If compromised users are blocked from signing in, an administrator can generate a temporary password for them.
The users will have to change their password during a next sign-in.
See also
Azure Active Directory Identity Protection playbook
This playbook helps you to:

Populate data in the Identity Protection environment by simulating risk events and vulnerabilities
Set up risk-based conditional access policies and test the impact of these policies
Simulating Risk Events

This section provides you with steps for simulating the following risk event types:
Sign-ins from anonymous IP addresses (easy)
Sign-ins from unfamiliar locations (moderate)
Impossible travel to atypical locations (difficult)
Other risk events cannot be simulated in a secure manner.
This risk event type identifies users who have successfully signed in from an IP address that has been identified as
an anonymous proxy IP address. These proxies are used by people who want to hide their device’s IP address and
may be used for malicious intent.
To simulate a sign-in from an anonymous IP, perform the following steps:
1. Download the Tor Browser.
2. Using the Tor Browser, navigate to https://myapps.microsoft.com.
3. Enter the credentials of the account you want to appear in the Sign-ins from anonymous IP addresses report.
The sign-in will show up on the Identity Protection dashboard within 5 minutes.
Sign-ins from unfamiliar locations
The unfamiliar locations risk is a real-time sign-in evaluation mechanism that considers past sign-in locations (IP,
Latitude / Longitude and ASN) to determine new / unfamiliar locations. The system stores previous IPs, Latitude /
Longitude, and ASNs of a user and considers these to be familiar locations. A sign-in location is considered
unfamiliar if the sign-in location does not match any of the existing familiar locations.
Azure Active Directory Identity Protection:
has an initial learning period of 14 days during which it does not flag any new locations as unfamiliar locations.
ignores sign-ins from familiar devices and locations that are geographically close to an existing familiar location.
To simulate unfamiliar locations, you have to sign in from a location and device that the account has not signed in
from before.
To simulate a sign-in from an unfamiliar location, perform the following steps:
1. Choose an account that has at least a 14-day sign-in history.
2. Do either:
a. While using a VPN, navigate to https://myapps.microsoft.com and enter the credentials of the account you
want to simulate the risk event for.
b. Ask an associate in a different location to sign in using the account’s credentials (not recommended).
The sign-in will show up on the Identity Protection dashboard within 5 minutes.
Impossible travel to atypical location
Simulating the impossible travel condition is difficult because the algorithm uses machine learning to weed out
false-positives such as impossible travel from familiar devices, or sign-ins from VPNs that are used by other users
in the directory. Additionally, the algorithm requires a sign-in history of 3 to 14 days for the user before it begins
generating risk events.
To simulate an impossible travel to atypical location, perform the following steps:
1. Using your standard browser, navigate to https://myapps.microsoft.com.
2. Enter the credentials of the account you want to generate an impossible travel risk event for.
3. Change your user agent. You can change user agent in Internet Explorer from Developer Tools, or change your
user agent in Firefox or Chrome using a user-agent switcher add-on.
4. Change your IP address. You can change your IP address by using a VPN, a Tor add-on, or spinning up a new
machine in Azure in a different data center.
5. Sign-in to https://myapps.microsoft.com using the same credentials as before and within a few minutes after
the previous sign-in.
The sign-in will show up in the Identity Protection dashboard within 2-4 hours.
Because of the complex machine learning models involved, there is a chance it will not get picked up.
You might want to replicate these steps for multiple Azure AD accounts.
Simulating vulnerabilities
Vulnerabilities are weaknesses in an Azure AD environment that can be exploited by a bad actor. Currently 3 types
of vulnerabilities are surfaced in Azure AD Identity Protection that leverage other features of Azure AD. These
Vulnerabilities will be displayed on the Identity Protection dashboard automatically once these features are set up.
Azure AD Multi-Factor Authentication?
Azure AD Cloud App Discovery.
Azure AD Privileged Identity Management.
User compromise risk

To test User compromise risk, perform the following steps:
1. Sign-in to https://portal.azure.com with global administrator credentials for your tenant.
2. Navigate to Identity Protection.
3. On the main Azure AD Identity Protection blade, click Settings.
4. On the Portal Settings blade, under Security rules, click User compromise risk.
5. On the Sign in Risk blade, turn Enable rule off, and then click Save settings.
6. For a given user account, simulate an unfamiliar locations or anonymous IP risk event. This will elevate the user
risk level for that user to Medium.
7. Wait a few minutes, and then verify that user level for your user is Medium.
8. Go to the Portal Settings blade.
9. On the User Compromise Risk blade, under Enable rule, select On .
10. Select one of the following options:
a. To block, select Medium under Block sign in.
b. To enforce secure password change, select Medium under Require multi-factor authentication.
11. Click Save.
12. You can now test risk-based conditional access by signing in using a user with an elevated risk level. If the user
risk is Medium, depending on the configuration of your policy, your sign-in is be either blocked or you are
forced to change your password.
Sign-in risk
To test a sign in risk, perform the following steps:
1. Sign-in to https://portal.azure.com with global administrator credentials for your tenant.
2. Navigate to Identity Protection.
3. On the main Azure AD Identity Protection blade, click Settings.
4. On the Portal Settings blade, under Security rules, click Sign in risk.
5. On the Sign in Risk **blade, select **On under Enable rule.
6. Select one of the following options:
a. To block, select Medium under Block sign in
b. To enforce secure password change, select Medium under Require multi-factor authentication.
7. To block, select Medium under Block sign in.
8. To enforce multi-factor authentication, select Medium under Require multi-factor authentication.
9. Click on Save.
10. You can now test risk-based conditional access by simulating the unfamiliar locations or anonymous IP risk
events because they are both Medium risk events.
See also
Azure Active Directory Identity Protection - How to
unblock users
With Azure Active Directory Identity Protection, you can configure policies to block users if the configured
conditions are satisfied. Typically, a blocked user contacts help desk to become unblocked. This topics explains the
steps you can perform to unblock a blocked user.
Determine the reason for blocking

As a first step to unblock a user, you need to determine the type of policy that has blocked the user because your
next steps are depending on it. With Azure Active Directory Identity Protection, a user can be either blocked by a
sign-in risk policy or a user risk policy.
You can get the type of policy that has blocked a user from the heading in the dialog that was presented to the user
during a sign-in attempt:
POLICY USER DIALOG
Sign-in risk
User risk
A user that is blocked by:
A sign-in risk policy is also known as suspicious sign-in
A user risk policy is also known as an account at risk
Unblocking suspicious sign-ins

To unblock a suspicious sign-in, you have the following options:
1. Sign-in from a familiar location or device - A common reason for blocked suspicious sign-ins are sign-in
attempts from unfamiliar locations or devices. Your users can quickly determine whether this is the blocking
reason by trying to sign-in from a familiar location or device.
2. Exclude from policy - If you think that the current configuration of your sign-in policy is causing issues for
specific users, you can exclude the users from it. See Azure Active Directory Identity Protection for more details.
3. Disable policy - If you think that your policy configuration is causing issues for all your users, you can disable
the policy. See Azure Active Directory Identity Protection for more details.
Unblocking accounts at risk

To unblock an account at risk, you have the following options:
1. Reset password - You can reset the user's password. See manual secure password reset for more details.
2. Dismiss all risk events - The user risk policy blocks a user if the configured user risk level for blocking access
has been reached. You can reduce a user's risk level by manually closing reported risk events. For more details,
see closing risk events manually.
3. Exclude from policy - If you think that the current configuration of your sign-in policy is causing issues for
specific users, you can exclude the users from it. See Azure Active Directory Identity Protection for more details.
4. Disable policy - If you think that your policy configuration is causing issues for all your users, you can disable
the policy. See Azure Active Directory Identity Protection for more details.
Next steps
Do you want to know more about Azure AD Identity Protection? Check out Azure Active Directory Identity
Protection.
Azure Active Directory Identity Protection FAQ
This article includes answers to frequently asked questions about Azure Active Directory (Azure AD) Identity
Protection. For more information, see Azure Active Directory Identity Protection.
Why do some risk events have “Closed (system)” status?

A: These are events that Azure Active Directory Identity Protection detected and later closed because the events
were no longer considered risky. These events do not count towards the user’s risk level.
Do I need to be a global admin to use Identity Protection in the Azure

portal?
A: No. You can either be a Security Reader, a Security Admin or a Global Admin to use Identity Protection.
How do I get Identity Protection?

A: See Getting started with Azure Active Directory Premium for an answer to this question.
How can I sort users in "Users flagged for risk"?

A: Download the users flagged for risk report by clicking on the Download on the top of the Users flagged for
risk page. You can then sort the downloaded data based on available fields, including Last Updated (UTC).
Azure Active Directory Identity Protection Glossary
At risk (User)
A user with one or more active risk events.
Atypical sign-in location
A sign-in from a geographic location that is not typical for the specific user, similar users, or the tenant.
Azure AD Identity Protection
A security module of Azure Active Directory that provides a consolidated view into risk events and potential
vulnerabilities affecting an organization’s identities.
Conditional access
A policy for securing access to resources. Conditional access rules are stored in the Azure Active Directory and are
evaluated by Azure AD before granting access to the resource. Example rules include restricting access based on
user location, device health or user authentication method.
Credentials
Information that includes identification and proof of identification that is used to gain access to local and network
resources. Examples of credentials are user names and passwords, smart cards, and certificates.
Event
A record of an activity in Azure Active Directory.
False -positive (risk event)
A risk event status set manually by an Identity Protection user, indicating that the risk event was investigated and
was incorrectly flagged as a risk event.
Identity
A person or entity that must be verified by means of authentication, based on criteria such as password or a
certificate.
Identity risk event
AAD event that was flagged as anomalous by Identity Protection, and may indicate that an identity has been
compromised.
Ignored (risk event)
A risk event status set manually by an Identity Protection user, indicating that the risk event is closed without taking
a remediation action.
Impossible travel from atypical locations
A risk event triggered when two sign-ins for the same user are detected, where at least one of them is from an
atypical sign-in location, and where the time between the sign-ins is shorter than the minimum time it would take
to physically travel between these locations.
Investigation
The process of reviewing the activities, logs, and other relevant information related to a risk event to decide
whether remediation or mitigation steps are necessary, understand if and how the identity was compromised, and
understand how the compromised identity was used.
Leaked credentials
A risk event triggered when current user credentials (user name and password) are found posted publicly in the
Dark web by our researchers.
Mitigation
An action to limit or eliminate the ability of an attacker to exploit a compromised identity or device without
restoring the identity or device to a safe state. A mitigation does not resolve previous risk events associated with
the identity or device.
An authentication method that requires two or more authentication methods, which may include something the
user has, such a certificate; something the user knows, such as user names, passwords, or pass phrases; physical
attributes, such as a thumbprint; and personal attributes, such as a personal signature.
Offline detection
The detection of anomalies and evaluation of the risk of an event such as sign-in attempt after the fact, for an event
that has already happened.
Policy condition
A part of a security policy which defines the entities (groups, users, apps, device platforms, Device states, IP ranges,
client types) included in the policy or excluded from it.
Policy rule
The part of a security policy which describes the circumstances that would trigger the policy, and the actions taken
when the policy is triggered.
Prevention
An action to prevent damage to the organization through abuse of an identity or device suspected or know to be
compromised. A prevention action does not secure the device or identity, and does not resolve previous risk events.
Privileged (user)
A user that at the time of a risk event, had permanent or temporary admin permissions to one or more resource in
Azure Active Directory, such as a Global Administrator, Billing Administrator, Service Administrator, User
administrator, and Password Administrator.
Real-time
See Real-time detection.
Real-time detection
The detection of anomalies and evaluation of the risk of an event such as sign-in attempt before the event is
allowed to proceed.
Remediated (risk event)
A risk event status set automatically by Identity Protection, indicating that the risk event was remediated using the
standard remediation action for this type of risk event. For example, when the user password is reset, many risk
events that indicate that the previous password was compromised are automatically remediated.
Remediation
An action to secure an identity or a device that were previously suspected or known to be compromised. A
remediation action restores the identity or device to a safe state, and resolves previous risk events associated with
the identity or device.
Resolved (risk event)
A risk event status set manually by an Identity Protection user, indicating that the user took an appropriate
remediation action outside Identity Protection, and that the risk event should be considered closed.
Risk event status
A property of a risk event, indicating whether the event is active, and if closed, the reason for closing it.
Risk event type
A category for the risk event, indicating the type of anomaly that caused the event to be considered risky.
Risk level (risk event)
An indication (High, Medium, or Low) of the severity of the risk event to help Identity Protection users prioritize the
actions they take to reduce the risk to their organization.
Risk level (sign-in)
An indication (High, Medium, or Low) of the likelihood that for a specific sign-in, someone else is attempting to use
the user’s identity.
Risk level (user compromise )
An indication (High, Medium, or Low) of the likelihood that an identity has been compromised.
Risk level (vulnerability)
An indication (High, Medium, or Low) of the severity of the vulnerability to help Identity Protection users prioritize
the actions they take to reduce the risk to their organization.
Secure (identity)
Take remediation action such as a password change or machine reimaging to restore a potentially compromised
identity to an uncompromised state.
Security policy
A collection of policy rules and condition. A policy can be applied to entities such as users, groups, apps, devices,
device platforms, device states, IP ranges, and Auth2.0 client types. When a policy is enabled, it is evaluated
whenever an entity included in the policy is issued a token for a resource.
Sign in (v)
To authenticate to an identity in Azure Active Directory.
Sign-in (n)
The process or action of authenticating an identity in Azure Active Directory, and the event that captures this
operation.
Sign-in from anonymous IP address
A risk event triggered after a successful sign-in from IP address that has been identified as an anonymous proxy IP
address.
Sign-in from infected device
A risk event triggered when a sign-in originates from an IP address which is known to be used by one or more
compromised devices, which are actively attempting to communicate with a bot server.
Sign-in from IP address with suspicious activity
A risk event triggered after a successful sign-in from an IP address with a high number of failed login attempts
across multiple user accounts over a short period of time.
Sign-in from unfamiliar location
A risk event triggered when a user successfully signs in from a new location (IP, Latitude/Longitude and ASN).
Sign-in risk
See Risk level (sign-in)
Sign-in risk policy
A conditional access policy that evaluates the risk to a specific sign-in and applies mitigations based on predefined
conditions and rules.
User compromise risk
See Risk level (user compromise)
User risk
See Risk level (user compromise).
User risk policy
A conditional access policy that considers the sign-in and applies mitigations based on predefined conditions and
rules.
Users flagged for risk
Users that have risk events which are either active or remediated
Vulnerability
A configuration or condition in Azure Active Directory which makes the directory susceptible to exploits or threats.
See also
Get started with Azure Active Directory Identity
Protection and Microsoft Graph
Microsoft Graph is the Microsoft unified API endpoint and the home of Azure Active Directory Identity Protection
APIs. The first API, identityRiskEvents, allows you to query Microsoft Graph for a list of risk events and associated
information. This article gets you started querying this API. For an in-depth introduction, full documentation, and
access to the Graph Explorer, see the Microsoft Graph site.
There are four steps to accessing Identity Protection data through Microsoft Graph:
1. Retrieve your domain name.
2. Create a new app registration.
3. Use this secret and a few other pieces of information to authenticate to Microsoft Graph, where you receive an
authentication token.
4. Use this token to make requests to the API endpoint and get Identity Protection data back.
Before you get started, you’ll need:
Administrator privileges to create the application in Azure AD
The name of your tenant's domain (for example, contoso.onmicrosoft.com)
Retrieve your domain name

1. Sign in to your Azure portal as an administrator.
2. On the left navigation pane, click Active Directory.
3. In the Manage section, click Properties.
4. Copy your domain name.
Create a new app registration

1. On the Active Directory page, in the Manage section, click App registrations.
2. In the menu on the top, click New application registration.
3. On the Create page, perform the following steps:
a. In the Name textbox, type a name for your application (e.g.: AADIP Risk Event API Application).
b. As Type, select Web Application And / Or Web API.
c. In the Sign-on URL textbox, type http://localhost .
d. Click Create.
4. To open the Settings page, in the applications list, click your newly created app registration.
5. Copy the Application ID.
Grant your application permission to use the API

1. On the Settings page, click Required permissions.
2. On the Required permissions page, in the toolbar on the top, click Add.
3. On the Add API access page, click Select an API.
4. On the Select an API page, select Microsoft Graph, and then click Select.
5. On the Add API access page, click Select permissions.
6. On the Enable Access page, click Read all identity risk information, and then click Select.
7. On the Add API access page, click Done.
8. On the Required Permissions page, click Grant Permissions, and then click Yes.
Get an access key

1. On the Settings page, click Keys.
2. On the Keys page, perform the following steps:

a. In the Key description textbox, type a description (for example, AADIP Risk Event).
b. As Duration, select In 1 year.
c. Click Save.
d. Copy the key value, and then paste it into a safe location.
NOTE
If you lose this key, you will have to return to this section and create a new key. Keep this key a secret: anyone who
has it can access your data.
Authenticate to Microsoft Graph and query the Identity Risk Events

API
At this point, you should have:
The name of your tenant's domain
The client ID
The key
To authenticate, send a post request to https://login.microsoft.com with the following parameters in the body:
grant_type: “client_credentials”
resource: “https://graph.microsoft.com”
client_id: <your client ID>
client_secret: <your key>
If successful, this returns an authentication token.
To call the API, create a header with the following parameter:
`Authorization`=”<token_type> <access_token>"
When authenticating, you can find the token type and access token in the returned token.
Send this header as a request to the following API URL: https://graph.microsoft.com/beta/identityRiskEvents
The response, if successful, is a collection of identity risk events and associated data in the OData JSON format,
which can be parsed and handled as you see fit.
Here’s sample code for authenticating and calling the API using PowerShell.
Just add your client ID, the secret key, and the tenant domain.
$ClientID = "<your client ID here>" # Should be a ~36 hex character string; insert your info here
$ClientSecret = "<your client secret here>" # Should be a ~44 character string; insert your info here
$tenantdomain = "<your tenant domain here>" # For example, contoso.onmicrosoft.com
$loginURL = "https://login.microsoft.com"
$resource = "https://graph.microsoft.com"
$body =
$body
Write-Output $oauth

$url = "https://graph.microsoft.com/beta/identityRiskEvents"
Write-Output $url
foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

Write-Output $event
}
} else {
}
Next steps
Congratulations, you just made your first call to Microsoft Graph!
Now you can query identity risk events and use the data however you see fit.
To learn more about Microsoft Graph and how to build applications using the Graph API, check out the
documentation and much more on the Microsoft Graph site. Also, make sure to bookmark the Azure AD Identity
Protection API page that lists all of the Identity Protection APIs available in Graph. As we add new ways to work
with Identity Protection via API, you’ll see them on that page.
For related information, see:
Types of risk events detected by Azure Active Directory Identity Protection
Microsoft Graph
Overview of Microsoft Graph
Azure AD Identity Protection Service Root
Securing privileged access in Azure AD
Securing privileged access is a critical first step to help protect business assets in a modern organization. Privileged
accounts are accounts that administer and manage IT systems. Cyber-attackers target these accounts to gain access
to an organization’s data and systems. To secure privileged access, you should isolate the accounts and systems
from the risk of being exposed to a malicious user.
More users are starting to get privileged access through cloud services. This can include global administrators of
Office365, Azure subscription administrators, and users who have administrative access in VMs or on SaaS apps.
Microsoft recommends you follow this roadmap on Securing Privileged Access.
For customers using Azure Active Directory, Office 365, or other Microsoft services and applications, these
principles apply whether user accounts are managed and authenticated by Active Directory or in Azure Active
Directory. The following sections provide more information on Azure AD features to support securing privileged
access.

To increase the security of administrator authentication, you should require two-step verification before granting
privileges. Two-step verification is a method of verifying who you are that requires the use of more than just a
Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution, which helps safeguard access
to data and applications while meeting user demand for a simple sign-in process. It delivers strong authentication
via a range of easy verification options including:
phone calls
text messages
mobile app notifications
mobile app verification codes
third-party OATH tokens
For an overview of how Azure Multi-Factor Authentication works see the following video:
For more information, see MFA for Office 365 and MFA for Azure.
Time-bound privileges
Some organizations may find that they have too many users in highly privileged roles. A user might have been
added to the role for a particular activity, like to sign up for a service, but didn't use those privileges frequently
afterward.
To lower the exposure time of privileges and increase your visibility into their use, limit users to only taking on their
privileges "just in time" (JIT), or assign these roles for a shortened duration with confidence the privileges will be
revoked automatically. For Azure Active Directory, Azure Resources (Preview) and Microsoft Online Services, you
can use Azure AD Privileged Identity Management (PIM).
Attack detection
Azure Active Directory Identity Protection provides a consolidated view into risk events and potential vulnerabilities
affecting your organization’s identities. Based on risk events, Identity Protection calculates a user risk level for each
user, enabling you to configure risk-based policies to automatically protect the identities of your organization.
These policies, along with other conditional access controls provided by Azure Active Directory and EMS, can
automatically block the user or offer suggestions that include password resets and multi-factor authentication
enforcement.
Conditional access
With conditional access control, Azure Active Directory checks the specific conditions you choose when
authenticating a user, before allowing access to an application. Once those conditions are met, the user is
authenticated and allowed access to the application.
Related articles
Enable Azure Multi-Factor Authentication
Enable Azure AD Privileged Identity Management
Enable Azure AD Identity Protection
Enable conditional access controls
For more information on building a complete security roadmap, see the “Customer responsibilities and roadmap”
section of the Microsoft Cloud Security for Enterprise Architects document. For more information on engaging
Microsoft services to assist with any of these topics, contact your Microsoft representative or visit our Cybersecurity
solutions page.
Enabling LinkedIn integration in Azure Active
Directory
Enabling LinkedIn integration lets your users access both public LinkedIn data and, if they choose to, their personal
LinkedIn network from within Microsoft apps. Each user can independently choose to connect their work account to
their LinkedIn account.
LinkedIn integration from your end users’ perspective
When end users in your organization connect their LinkedIn accounts to their work accounts, they are able to better
identify the people they work with inside and outside the organization. Connecting the two accounts allows the
user’s LinkedIn connections and profile data to be used in your organization's Microsoft apps, but they can always
opt out by removing permission for LinkedIn to share that data. The integration also uses publicly available profile
information, and users can choose whether to share their public profile and network information with Microsoft
applications through LinkedIn privacy settings.
NOTE
Enabling LinkedIn integration in Azure AD enables apps and services to access some of your end users' information. Read the
Microsoft Privacy Statement to learn more about the privacy considerations when enabling LinkedIn integration in Azure AD.
Enable LinkedIn integration

LinkedIn integration for enterprises is enabled by default in Azure AD. So, when this feature is made available for
your tenant, all users in your organization can see LinkedIn features and profiles. Enabling LinkedIn integration
allows users in your organization to use LinkedIn features within Microsoft services, such as viewing profiles when
receiving an email in Outlook. Disabling this feature prevents access to LinkedIn features and stops user account
connections and data sharing between LinkedIn and your organization via Microsoft services.
IMPORTANT
This feature is not available for go-local, sovereign, and government tenants. In addition, Azure AD service updates, such as
LinkedIn integration capabilities, are not deployed to all Azure tenants at the same time. You cannot enable LinkedIn
integration with Azure AD until this capability has been rolled out to your Azure tenant.
3. On the Users and groups blade, select User settings.
4. Under LinkedIn Integration, select Yes or No to enable or disable LinkedIn integration.
Learn more
LinkedIn information and features in your Microsoft apps
LinkedIn help center
Next steps
You can use the following link to enable or disable LinkedIn integration with Azure AD from the Azure portal:
Configure LinkedIn integration
Windows Server Active Directory on Azure VMs
This navigation topic contains links to other topics about how to deploy Windows Server Active Directory Domain
Services (AD DS) or Active Directory Federation Services (AD FS) on an Azure virtual machine (VM).
Conceptual guidelines
Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines
Video
How to install a new Active Directory forest on an Azure virtual network
How to articles
Install a new Active Directory forest on an Azure virtual network
Install a Replica Active Directory Domain Controller in Azure Virtual Networks
Sign up for Azure as an organization
Azure Identity
Guidelines for deploying Windows Server Active
Directory on Azure virtual machines
This article explains the important differences between deploying Windows Server Active Directory Domain
Services (AD DS) and Active Directory Federation Services (AD FS) on-premises versus deploying them on
Microsoft Azure virtual machines.
Scope and audience

The article is intended for those already experienced with deploying Active Directory on-premises. It covers the
differences between deploying Active Directory on Microsoft Azure virtual machines/Azure virtual networks and
traditional on-premises Active Directory deployments. Azure virtual machines and Azure virtual networks are part
of an Infrastructure-as-a-Service (IaaS) offering for organizations to leverage computing resources in the cloud.
For those that are not familiar with AD deployment, see the AD DS Deployment Guide or Plan your AD FS
deployment as appropriate.
This article assumes that the reader is familiar with the following concepts:
Windows Server AD DS deployment and management
Deployment and configuration of DNS to support a Windows Server AD DS infrastructure
Windows Server AD FS deployment and management
Deploying, configuring, and managing relying party applications (websites and web services) that can consume
Windows Server AD FS tokens
General virtual machine concepts, such as how to configure a virtual machine, virtual disks, and virtual networks
This article highlights the requirements for a hybrid deployment scenario in which Windows Server AD DS or AD
FS are partly deployed on-premises and partly deployed on Azure virtual machines. The document first covers the
critical differences between running Windows Server AD DS and AD FS on Azure virtual machines versus on-
premises, and important decision points that affect design and deployment. The rest of the paper explains
guidelines for each of the decision points in more detail, and how to apply the guidelines to various deployment
scenarios.
This article does not discuss the configuration of Azure Active Directory, which is a REST-based service that
provides identity management and access control capabilities for cloud applications. Azure Active Directory (Azure
AD) and Windows Server AD DS are, however, designed to work together to provide an identity and access
management solution for today’s hybrid IT environments and modern applications. To help understand the
differences and relationships between Windows Server AD DS and Azure AD, consider the following:
1. You might run Windows Server AD DS in the cloud on Azure virtual machines when you are using Azure to
extend your on-premises datacenter into the cloud.
2. You might use Azure AD to give your users single sign-on to Software-as-a-Service (SaaS) applications.
Microsoft Office 365 uses this technology, for example, and applications running on Azure or other cloud
platforms can also use it.
3. You might use Azure AD (its Access Control Service) to let users sign in using identities from Facebook, Google,
Microsoft, and other identity providers to applications that are hosted in the cloud or on-premises.
For more information about these differences, see Azure Identity.
Related resources
You may download and run the Azure Virtual Machine Readiness Assessment. The assessment will automatically
inspect your on-premises environment and generate a customized report based on the guidance found in this topic
to help you migrate the environment to Azure.
We recommend that you also first review the tutorials, guides, and videos that cover the following topics:
Configure a Cloud-Only Virtual Network in the Azure Portal
Configure a Site-to-Site VPN in the Azure Portal
Install a replica Active Directory domain controller on Azure
Microsoft Azure IT Pro IaaS: (01) Virtual Machine Fundamentals
Microsoft Azure IT Pro IaaS: (05) Creating Virtual Networks and Cross-Premises Connectivity
Introduction
The fundamental requirements for deploying Windows Server Active Directory on Azure virtual machines differ
very little from deploying it in on-premises virtual machines (and, to some extent, physical machines). For example,
in the case of Windows Server AD DS, if the domain controllers (DCs) that you deploy on Azure virtual machines
are replicas in an existing on-premises corporate domain/forest, then the Azure deployment can largely be treated
in the same way as you might treat any other additional Windows Server Active Directory site. That is, subnets must
be defined in Windows Server AD DS, a site created, the subnets linked to that site, and connected to other sites
using appropriate site-links. There are, however, some differences that are common to all Azure deployments and
some that vary according to the specific deployment scenario. Two fundamental differences are outlined below:
Azure virtual machines may need connectivity to the on-premises corporate network.
Connecting Azure virtual machines back to an on-premises corporate network requires Azure virtual network,
which includes a site-to-site or site-to-point virtual private network (VPN) component able to seamlessly connect
Azure virtual machines and on-premises machines. This VPN component could also enable on-premises domain
member computers to access a Windows Server Active Directory domain whose domain controllers are hosted
exclusively on Azure virtual machines. It is important to note, though, that if the VPN fails, authentication and other
operations that depend on Windows Server Active Directory will also fail. While users may be able to sign in using
existing cached credentials, all peer-to-peer or client-to-server authentication attempts for which tickets have yet to
be issued or have become stale will fail.
See Virtual Network for a demonstration video and a list of step-by-step tutorials, including Configure a Site-to-Site
VPN in the Azure portal.
NOTE
You can also deploy Windows Server Active Directory on an Azure virtual network that does not have connectivity with an
on-premises network. The guidelines in this topic, however, assume that an Azure virtual network is used because it provides
IP addressing capabilities that are essential to Windows Server.
Static IP addresses must be configured with Azure PowerShell.

Dynamic addresses are allocated by default, but use the Set-AzureStaticVNetIP cmdlet to assign a static IP address
instead. That sets a static IP address that will persist through service healing and VM shutdown/restart. For more
information, see Static internal IP address for virtual machines.
Terms and definitions

The following is a non-exhaustive list of terms for various Azure technologies which will be referenced in this
article.
Azure virtual machines: The IaaS offering in Azure that allows customers to deploy VMs running nearly any
traditionally on-premises server workload.
Azure virtual network: The networking service in Azure that lets customers create and manage virtual
networks in Azure and securely link them to their own on-premises networking infrastructure by using a virtual
private network (VPN).
Virtual IP address: An internet-facing IP address that is not bound to a specific computer or network interface
card. Cloud services are assigned a virtual IP address for receiving network traffic which is redirected to an
Azure VM. A virtual IP address is a property of a cloud-service which can contain one or more Azure virtual
machines. Also note that an Azure virtual network can contain one or more cloud-services. Virtual IP addresses
provide native load-balancing capabilities.
Dynamic IP address: This is the IP address that is internal only. It should be configured as a static IP address
(by using the Set-AzureStaticVNetIP cmdlet) for VMs that host the DC/DNS server roles.
Service healing: The process in which Azure automatically returns a service to a running state again after it
detects that the service has failed. Service healing is one of the aspects of Azure that supports availability and
resiliency. While unlikely, the result following a service healing incident for a DC running on a VM is similar
to an unplanned reboot, but has a few side-effects:
The virtual network adapter in the VM will change
The MAC address of the virtual network adapter will change
The Processor/CPU ID of the VM will change
The IP configuration of the virtual network adapter will not change as long as the VM is attached to a
virtual network and the VM’s IP address is static.
None of these behaviors affect Windows Server Active Directory because it has no dependency on the MAC
address or Processor/CPU ID, and all Windows Server Active Directory deployments on Azure are
recommended to be run on an Azure virtual network as outlined above.
Is it safe to virtualize Windows Server Active Directory domain

controllers?
Deploying Windows Server Active Directory DCs on Azure virtual machines is subject to the same guidelines as
running DCs on-premises in a virtual machine. Running virtualized DCs is a safe practice as long as guidelines for
backing up and restoring DCs are followed. For more information about constraints and guidelines for running
virtualized DCs, see Running Domain Controllers in Hyper-V.
Hypervisors provide or trivialize technologies that can cause problems for many distributed systems, including
Windows Server Active Directory. For example, on a physical server, you can clone a disk or use unsupported
methods to roll back the state of a server, including using SANs and so on, but doing that on a physical server is
much harder than restoring a virtual machine snapshot in a hypervisor. Azure offers functionality that can result in
the same undesirable condition. For example, you should not copy VHD files of DCs instead of performing regular
backups because restoring them can result in a similar situation to using snapshot restore features.
Such rollbacks introduce USN bubbles that can lead to permanently divergent states between DCs. That can cause
issues such as:
Lingering objects
Inconsistent passwords
Inconsistent attribute values
Schema mismatches if the schema master is rolled back
For more information about how DCs are impacted, see USN and USN Rollback.
Beginning with Windows Server 2012, additional safeguards are built in to AD DS. These safeguards help protect
virtualized domain controllers against the aforementioned problems, as long as the underlying hypervisor platform
supports VM-GenerationID. Azure supports VM-GenerationID, which means that domain controllers that run
Windows Server 2012 or later on Azure virtual machines have the additional safeguards.
NOTE
You should shut down and restart a VM that runs the domain controller role in Azure within the guest operating system
instead of using the Shut Down option in the Azure porta. Today, using the portal to shut down a VM causes the VM to be
deallocated. A deallocated VM has the advantage of not incurring charges, but it also resets the VM-GenerationID, which is
undesirable for a DC. When the VM-GenerationID is reset, the invocationID of the AD DS database is also reset, the RID pool
is discarded, and SYSVOL is marked as non-authoritative. For more information, see Introduction to Active Directory Domain
Services (AD DS) Virtualization and Safely Virtualizing DFSR.
Why deploy Windows Server AD DS on Azure Virtual Machines?

Many Windows Server AD DS deployment scenarios are well-suited for deployment as VMs on Azure. For example,
suppose you have a company in Europe that needs to authenticate users in a remote location in Asia. The company
has not previously deployed Windows Server Active Directory DCs in Asia due to the cost to deploy them and
limited expertise to manage the servers post-deployment. As a result, authentication requests from Asia are
serviced by DCs in Europe with suboptimal results. In this case, you can deploy a DC on a VM that you have
specified must be run within the Azure datacenter in Asia. Attaching that DC to an Azure virtual network that is
connected directly to the remote location will improve authentication performance.
Azure is also well-suited as a substitute to otherwise costly disaster recovery (DR) sites. The relatively low-cost of
hosting a small number of domain controllers and a single virtual network on Azure represents an attractive
alternative.
Finally, you may want to deploy a network application on Azure, such as SharePoint, that requires Windows Server
Active Directory but has no dependency on the on-premises network or the corporate Windows Server Active
Directory. In this case, deploying an isolated forest on Azure to meet the SharePoint server’s requirements is
optimal. Again, deploying network applications that do require connectivity to the on-premises network and the
corporate Active Directory is also supported.
NOTE
Since it provides a layer-3 connection, the VPN component that provides connectivity between an Azure virtual network and
an on-premises network can also enable member servers that run on-premises to leverage DCs that run as Azure virtual
machines on Azure virtual network. But if the VPN is unavailable, communication between on-premises computers and
Azure-based domain controllers will not function, resulting in authentication and various other errors.
Contrasts between deploying Windows Server Active Directory domain

controllers on Azure Virtual Machines versus on-premises
For any Windows Server Active Directory deployment scenario that includes more than a single VM, it is
necessary to use an Azure virtual network for IP address consistency. Note that this guide assumes that DCs are
running on an Azure virtual network.
As with on-premises DCs, static IP addresses are recommended. A static IP address can only be configured by
using Azure PowerShell. See Static internal IP address for VMs for more details. If you have monitoring systems
or other solutions that check for static IP address configuration within the guest operating system, you can
assign the same static IP address to the network adapter properties of the VM. But be aware that the network
adapter will be discarded if the VM undergoes service healing or is shut down in the portal and has its address
deallocated. In that case, the static IP address within the guest will need to be reset.
Deploying VMs on a virtual network does not imply (or require) connectivity back to an on-premises network;
the virtual network merely enables that possibility. You must create a virtual network for private communication
between Azure and your on-premises network. You need to deploy a VPN endpoint on the on-premises
network. The VPN is opened from Azure to the on-premises network. For more information, see Virtual Network
Overview and Configure a Site-to-Site VPN in the Azure Portal.
NOTE
An option to create a point-to-site VPN is available to connect individual Windows-based computers directly to an Azure
virtual network.
Regardless of whether you create a virtual network or not, Azure charges for egress traffic but not ingress.
Various Windows Server Active Directory design choices can affect how much egress traffic is generated by a
deployment. For example, deploying a read-only domain controller (RODC) limits egress traffic because it does
not replicate outbound. But the decision to deploy an RODC needs to be weighed against the need to perform
write operations against the DC and the compatibility that applications and services in the site have with RODCs.
For more information about traffic charges, see Azure pricing at-a-glance.
While you have complete control over what server resources to use for VMs on-premises, such as RAM, disk
size, and so on, on Azure you must select from a list of preconfigured server sizes. For a DC, a data disk is
needed in addition to the operating system disk in order to store the Windows Server Active Directory database.
Can you deploy Windows Server AD FS on Azure virtual machines?

Yes, you can deploy Windows Server AD FS on Azure virtual machines, and the best practices for AD FS
deployment on-premises apply equally to AD FS deployment on Azure. But some of the best practices such as load
balancing and high availability require technologies beyond what AD FS offers itself. They must be provided by the
underlying infrastructure. Let’s review some of those best practices and see how they can be achieved by using
Azure VMs and an Azure virtual network.
1. Never expose security token service (STS) servers directly to the Internet.
This is important because the STS issues security tokens. As a result, STS servers such as AD FS servers
should be treated with the same level of protection as a domain controller. If an STS is compromised,
malicious users have the ability to issue access tokens potentially containing claims of their choosing to
relying party applications and other STS servers in trusting organizations.
2. Deploy Active Directory domain controllers for all user domains in the same network as the AD FS
servers.
AD FS servers use Active Directory Domain Services to authenticate users. It is recommended to deploy
domain controllers on the same network as the AD FS servers. This provides business continuity in case the
link between the Azure network and your on-premises network is broken, and enables lower latency and
increased performance for logins.
3. Deploy multiple AD FS nodes for high availability and balancing the load.
In most cases, the failure of an application that AD FS enables is unacceptable because the applications that
require security tokens are often mission critical. As a result, and because AD FS now resides in the critical
path to accessing mission critical applications, the AD FS service must be highly available through multiple
AD FS proxies and AD FS servers. To achieve distribution of requests, load balancers are typically deployed in
front of both the AD FS Proxies and the AD FS servers.
4. Deploy one or more Web Application Proxy nodes for internet access.
When users need to access applications protected by the AD FS service, the AD FS service needs to be
available from the internet. This is achieved by deploying the Web Application Proxy service. It is strongly
recommended to deploy more than one node for the purposes of high availability and load balancing.
5. Restrict access from the Web Application Proxy nodes to internal network resources.
To allow external users to access AD FS from the internet, you need to deploy Web Application Proxy nodes
(or AD FS Proxy in earlier versions of Windows Server). The Web Application proxy nodes are directly
exposed to the Internet. They are not required to be domain-joined and they only need access to the AD FS
servers over TCP ports 443 and 80. It is strongly recommended that communication to all other computers
(especially domain controllers) is blocked.
This is typically achieved on-premises by means of a DMZ. Firewalls use a whitelist mode of operation to
restrict traffic from the DMZ to the on-premises network (that is, only traffic from the specified IP addresses
and over specified ports is allowed, and all other traffic is blocked).
The following diagram shows a traditional on-premises AD FS deployment.
However, because Azure does not provide native, full-featured firewall capability, other options need to be used to
restrict traffic. The following table shows each option and its advantages and disadvantages.
OPTION ADVANTAGE DISADVANTAGE

OPTION ADVANTAGE DISADVANTAGE
Azure network ACLs Less costly and simpler initial Additional network ACL configuration
configuration required if any new VMs are added to
the deployment
Barracuda NG firewall Whitelist mode of operation and it Increased cost and complexity for initial
requires no network ACL configuration setup
The high-level steps to deploy AD FS in this case are as follows:

1. Create a virtual network with cross-premises connectivity, using either a VPN or ExpressRoute.
2. Deploy domain controllers on the virtual network. This step is optional but recommended.
3. Deploy domain-joined AD FS servers on the virtual network.
4. Create an internal load balanced set that includes the AD FS servers and uses a new private IP address within
the virtual network (a dynamic IP address).
a. Update DNS to create the FQDN to point to the private (dynamic) IP address of the internal load balanced
set.
5. Create a cloud service (or a separate virtual network) for the Web Application Proxy nodes.
6. Deploy the Web Application Proxy nodes in the cloud service or virtual network
a. Create an external load balanced set that includes the Web Application Proxy nodes.
b. Update the external DNS name (FQDN) to point to the cloud service public IP address (the virtual IP
address).
c. Configure AD FS proxies to use the FQDN that corresponds to the internal load balanced set for the AD
FS servers.
d. Update claims-based web sites to use the external FQDN for their claims provider.
7. Restrict access between Web Application Proxy to any machine in the AD FS virtual network.
To restrict traffic, the load-balanced set for the Azure internal load balancer needs to be configured for only traffic
to TCP ports 80 and 443, and all other traffic to the internal dynamic IP address of the load balanced set is dropped.
Traffic to the AD FS servers would be permitted only by the following sources:

The Azure internal load balancer.
The IP address of an administrator on the on-premises network.
WARNING
The design must prevent Web Application Proxy nodes from reaching any other VMs in the Azure virtual network or any
locations on the on-premises network. That can be done by configuring firewall rules in the on-premises appliance for Express
Route connections or the VPN device for site-to-site VPN connections.
A disadvantage to this option is the need to configure the network ACLs for multiple devices, including internal load
balancer, the AD FS servers, and any other servers that get added to the virtual network. If any device is added to
the deployment without configuring network ACLs to restrict traffic to it, the entire deployment can be at risk. If the
IP addresses of the Web Application Proxy nodes ever change, the network ACLs must be reset (which means the
proxies should be configured to use static dynamic IP addresses).
Another option is to use the Barracuda NG Firewall appliance to control traffic between AD FS proxy servers and
the AD FS servers. This option complies with best practices for security and high availability, and requires less
administration after the initial setup because the Barracuda NG Firewall appliance provides a whitelist mode of
firewall administration and it can be installed directly on an Azure virtual network. That eliminates the need to
configure network ACLs any time a new server is added to the deployment. But this option adds initial deployment
complexity and cost.
In this case, two virtual networks are deployed instead of one. We'll call them VNet1 and VNet2. VNet1 contains the
proxies and VNet2 contains the STSs and the network connection back to the corporate network. VNet1 is therefore
physically (albeit virtually) isolated from VNet2 and, in turn, from the corporate network. VNet1 is then connected
to VNet2 using a special tunneling technology known as Transport Independent Network Architecture (TINA). The
TINA tunnel is attached to each of the virtual networks using a Barracuda NG firewall—one Barracuda on each of
the virtual networks. For high-availability, it is recommended that you deploy two Barracudas on each virtual
network; one active, the other passive. They offer extremely rich firewalling capabilities which allow us to mimic the
operation of a traditional on-premises DMZ in Azure.
For more information, see AD FS: Extend a claims-aware on-premises front-end application to the Internet.
An alternative to AD FS deployment if the goal is Office 365 SSO alone
There is another alternative to deploying AD FS altogether if your goal is only to enable sign-in for Office 365. In
that case, you can simply deploy DirSync with password sync on-premises and achieve the same end-result with
minimal deployment complexity because this approach does not require AD FS or Azure.
The following table compares how the sign-in processes work with and without deploying AD FS.
OFFICE 365 SINGLE SIGN-ON USING AD FS AND DIRSYNC OFFICE 365 SAME SIGN-ON USING DIRSYNC + PASSWORD SYNC
1. The user logs on to a corporate network, and is 1. The user logs on to a corporate network, and is
authenticated to Windows Server Active Directory. authenticated to Windows Server Active Directory.
2. The user tries to access Office 365 (I am @contoso.com). 2. The user tries to access Office 365 (I am @contoso.com).
3. Office 365 redirects the user to Azure AD. 3. Office 365 redirects the user to Azure AD.
4. Since Azure AD can’t authenticate the user and understands 4. Azure AD can’t accept Kerberos tickets directly and no trust
there is a trust with AD FS on-premises, it redirects the user to relationship exists so it requests that the user enter
AD FS. credentials.
5. The user sends a Kerberos ticket to the AD FS STS. 5. The user enters the same on-premises password, and Azure
AD validates them against the user name and password that
was synchronized by DirSync.
6. AD FS transforms the Kerberos ticket to the required token 6. Azure AD redirects the user to Office 365.
format/claims and redirects the user to Azure AD.
7. The user authenticates to Azure AD (another transformation 7. The user can sign in to Office 365 and OWA using the
occurs). Azure AD token.
8. Azure AD redirects the user to Office 365.
9. The user is silently signed on to Office 365.
In the Office 365 with DirSync with password sync scenario (no AD FS), single sign-on is replaced by “same sign-
on” where “same” simply means that users must re-enter their same on-premises credentials when accessing
Office 365. Note that this data can be remembered by the user’s browser to help reduce subsequent prompts.
Additional food for thought
If you deploy an AD FS proxy on an Azure virtual machine, connectivity to the AD FS servers is needed. If they
are on-premises, it is recommended that you leverage the site-to-site VPN connectivity provided by the virtual
network to allow the Web Application Proxy nodes to communicate with their AD FS servers.
If you deploy an AD FS server on an Azure virtual machine, connectivity to Windows Server Active Directory
domain controllers, Attribute Stores, and Configuration databases is necessary and may also require an
ExpressRoute or a site-to-site VPN connection between the Azure virtual network and the on-premises network.
Charges are applied to all traffic from Azure virtual machines (egress traffic). If cost is the driving factor, it is
advisable to deploy the Web Application Proxy nodes on Azure, leaving the AD FS servers on-premises. If the AD
FS servers are deployed on Azure virtual machines as well, additional costs will be incurred to authenticate on-
premises users. Egress traffic incurs a cost regardless of whether or not it is traversing the ExpressRoute or the
VPN site-to-site connection.
If you decide to use Azure’s native server load balancing capabilities for high availability of AD FS servers, note
that load balancing provides probes that are used to determine the health of the virtual machines within the
cloud service. In the case of Azure virtual machines (as opposed to web or worker roles), a custom probe must
be used since the agent that responds to the default probes is not present on Azure virtual machines. For
simplicity, you might use a custom TCP probe — this requires only that a TCP connection (a TCP SYN segment
sent and responded to with a TCP SYN ACK segment) be successfully established to determine virtual machine
health. You can configure the custom probe to use any TCP port to which your virtual machines are actively
listening.
NOTE
Machines that need to expose the same set of ports directly to the Internet (such as port 80 and 443) cannot share the same
cloud service. It is, therefore, recommended that you create a dedicated cloud service for your Windows Server AD FS servers
in order to avoid potential overlaps between port requirements for an application and Windows Server AD FS.
Deployment scenarios
The following section outlines commonplace deployment scenarios to draw attention to important considerations
that must be taken into account. Each scenario has links to more details about the decisions and factors to consider.
1. AD DS: Deploy an AD DS-aware application with no requirement for corporate network connectivity
For example, an Internet-facing SharePoint service is deployed on an Azure virtual machine. The application
has no dependencies on corporate-network resources. The application does require Windows Server AD DS
but does NOT require the corporate Windows Server AD DS.
2. AD FS: Extend a claims-aware on-premises front-end application to the Internet
For example, a claims-aware application that has been successfully deployed on-premises and used by
corporate users needs to become accessible from the Internet. The application needs to be accessed directly
over the Internet both by business partners using their own corporate identities and by existing corporate
users.
3. AD DS: Deploy a Windows Server AD DS-aware application that requires connectivity to the corporate
network
For example, an LDAP-aware application that supports Windows-integrated authentication and uses
Windows Server AD DS as a repository for configuration and user-profile data is deployed on an Azure
virtual machine. It is desirable for the application to leverage the existing corporate Windows Server AD DS
and provide single sign-on. The application is not claims-aware.
1. AD DS: Deploy an AD DS -aware application with no requirement for corporate network connectivity
Figure 1
Description
SharePoint is deployed on an Azure virtual machine and the application has no dependencies on corporate-
network resources. The application does require Windows Server AD DS but does not require the corporate
Windows Server AD DS. No Kerberos or federated trusts are required because users are self-provisioned through
the application into the Windows Server AD DS domain that is also hosted in the cloud on Azure virtual machines.
Scenario considerations and how technology areas apply to the scenario
Network topology: Create an Azure virtual network without cross-premises connectivity (also known as site-to-
site connectivity).
DC deployment configuration: Deploy a new domain controller into a new, single-domain, Windows Server
Active Directory forest. This should be deployed along with the Windows DNS server.
Windows Server Active Directory site topology: Use the default Windows Server Active Directory site (all
computers will be in Default-First-Site-Name).
IP addressing and DNS:
Set a static IP address for the DC by using the Set-AzureStaticVNetIP Azure PowerShell cmdlet.
Install and configure Windows Server DNS on the domain controller(s) on Azure.
Configure the virtual network properties with the name and IP address of the VM that hosts the DC and
DNS server roles.
Global Catalog: The first DC in the forest must be a global catalog server. Additional DCs should also be
configured as GCs because in a single domain forest, the global catalog does not require any additional work
from the DC.
Placement of the Windows Server AD DS database and SYSVOL: Add a data disk to DCs running as Azure VMs
in order to store the Windows Server Active Directory database, logs, and SYSVOL.
Backup and Restore: Determine where you want to store system state backups. If necessary, add another data
disk to the DC VM to store backups.
2 AD FS: Extend a claims-aware on-premises front-end application to the Internet
Figure 2
Description
A claims-aware application that has been successfully deployed on-premises and used by corporate users needs to
become accessible directly from the Internet. The application serves as a web frontend to a SQL database in which it
stores data. The SQL servers used by the application are also located on the corporate network. Two Windows
Server AD FS STSs and a load-balancer have been deployed on-premises to provide access to the corporate users.
The application now needs to be additionally accessed directly over the Internet both by business partners using
their own corporate identities and by existing corporate users.
In an effort to simplify and meet the deployment and configuration needs of this new requirement, it is decided that
two additional web frontends and two Windows Server AD FS proxy servers be installed on Azure virtual machines.
All four VMs will be exposed directly to the Internet and will be provided connectivity to the on-premises network
using Azure Virtual Network’s site-to-site VPN capability.
Network topology: Create an Azure virtual network and configure cross-premises connectivity.
NOTE
For each of the Windows Server AD FS certificates, ensure that the URL defined within the certificate template and the
resulting certificates can be reached by the Windows Server AD FS instances running on Azure. This may require
cross-premises connectivity to parts of your PKI infrastructure. For example if the CRL's endpoint is LDAP-based and
hosted exclusively on-premises, then cross-premises connectivity will be required. If this is not desirable, it may be
necessary to use certificates issued by a CA whose CRL is accessible over the Internet.
Cloud services configuration: Ensure you have two cloud services in order provide two load-balanced virtual IP
addresses. The first cloud service’s virtual IP address will be directed to the two Windows Server AD FS proxy
VMs on ports 80 and 443. The Windows Server AD FS proxy VMs will be configured to point to the IP address of
the on-premises load-balancer that fronts the Windows Server AD FS STSs. The second cloud service’s virtual IP
address will be directed to the two VMs running the web frontend again on ports 80 and 443. Configure a
custom probe to ensure the load-balancer only directs traffic to functioning Windows Server AD FS proxy and
web frontend VMs.
Federation server configuration: Configure Windows Server AD FS as a federation server (STS) to generate
security tokens for the Windows Server Active Directory forest created in the cloud. Set federation claims
provider trust relationships with the different partners you wish to accept identities from, and configure
relying party trust relationships with the different applications you want to generate tokens to.
In most scenarios, Windows Server AD FS proxy servers are deployed in an Internet-facing capacity for
security purposes while their Windows Server AD FS federation counterparts remain isolated from direct
Internet connectivity. Regardless of your deployment scenario, you must configure your cloud service with a
virtual IP address that will provide a publicly exposed IP address and port that is able to load-balance across
either your two Windows Server AD FS STS instances or proxy instances.
Windows Server AD FS high availability configuration: It is advisable to deploy a Windows Server AD FS farm
with at least two servers for failover and load balancing. You might want to consider using the Windows Internal
Database (WID) for Windows Server AD FS configuration data, and use the internal load balancing capability of
Azure to distribute incoming requests across the servers in the farm.
For more information, see the AD DS Deployment Guide.
3. AD DS: Deploy a Windows Server AD DS -aware application that requires connectivity to the corporate
network
Figure 3
Description
An LDAP-aware application is deployed on an Azure virtual machine. It supports Windows-integrated
authentication and uses Windows Server AD DS as a repository for configuration and user profile data. The goal is
for the application to leverage the existing corporate Windows Server AD DS and provide single sign-on. The
application is not claims-aware. Users also need to access the application directly from the Internet. To optimize for
performance and cost, it is decided that two additional domain controllers that are part of the corporate domain be
deployed alongside the application on Azure.
Network topology: Create an Azure virtual network with cross-premises connectivity.
Installation method: Deploy replica DCs from the corporate Windows Server Active Directory domain. For a
replica DC, you can install Windows Server AD DS on the VM, and optionally use the Install From Media (IFM)
feature to reduce the amount of data that needs to be replicated to the new DC during installation. For a tutorial,
see Install a replica Active Directory domain controller on Azure. Even if you use IFM, it may be more efficient to
build the virtual DC on-premises and move the entire Virtual Hard Disk (VHD) to the cloud instead of replicating
Windows Server AD DS during installation. For safety, it is recommended that you delete the VHD from the on-
premises network once it has been copied to Azure.
Windows Server Active Directory site topology: Create a new Azure site in Active Directory Sites and Services.
Create a Windows Server Active Directory subnet object to represent the Azure virtual network and add the
subnet to the site. Create a new site link that includes the new Azure site and the site in which the Azure virtual
network VPN endpoint is located in order to control and optimize Windows Server Active Directory traffic to and
from Azure.
IP addressing and DNS:
Set a static IP address for the DC by using the Set-AzureStaticVNetIP Azure PowerShell cmdlet.
Install and configure Windows Server DNS on the domain controller(s) on Azure.
Configure the virtual network properties with the name and IP address of the VM that hosts the DC and
DNS server roles.
Geo-distributed DCs: Configure additional virtual networks as needed. If your Active Directory site topology
requires DCs in geographies that correspond to different Azure regions, than you want to create Active Directory
sites accordingly.
Read-only DCs: You might deploy an RODC in the Azure site, depending on your requirements for performing
write operations against the DC and the compatibility of applications and services in the site with RODCs. For
more information about application compatibility, see the Read-Only domain controllers application
compatibility guide.
Global Catalog: GCs are needed to service logon requests in multidomain forests. If you do not deploy a GC
in the Azure site, you will incur egress traffic costs as authentication requests cause queries GCs in other
sites. To minimize that traffic, you can enable universal group membership caching for the Azure site in
Active Directory Sites and Services.
If you deploy a GC, configure site links and site links costs so that the GC in the Azure site is not preferred as
a source DC by other GCs that need to replicate the same partial domain partitions.
Placement of the Windows Server AD DS database and SYSVOL: Add a data disk to DCs running on Azure VMs
in order to store the Windows Server Active Directory database, logs, and SYSVOL.
Backup and Restore: Determine where you want to store system state backups. If necessary, add another data
disk to the DC VM to store backups.
Deployment decisions and factors

This table summarizes the Windows Server Active Directory technology areas that are impacted in the preceding
scenarios and the corresponding decisions to consider, with links to more detail below. Some technology areas
might not be applicable to every deployment scenario, and some technology areas might be more critical to a
deployment scenario than other technology areas.
For example, if you deploy a replica DC on a virtual network and your forest has only a single domain, then
choosing to deploy a global catalog server in that case will not be critical to the deployment scenario because it will
not create any additional replication requirements. On the other hand, if the forest has several domains, then the
decision to deploy a global catalog on a virtual network could affect available bandwidth, performance,
authentication, directory lookups, and so on.
WINDOWS SERVER ACTIVE DIRECTORY
TECHNOLOGY AREA DECISIONS FACTORS
Network topology Do you create a virtual network? Requirements to access Corp

resources
Authentication
Account management
DC deployment configuration Deploy a separate forest without any Security

trusts? Compliance
Deploy a new forest with federation? Cost
Deploy a new forest with Windows Resiliency and fault-tolerance
Server Active Directory forest trust or Application compatibility
Kerberos?
Extend Corp forest by deploying a
replica DC?
Extend Corp forest by deploying a
new child domain or domain tree?
Windows Server Active Directory site How do you configure subnets, sites, Subnet and site definitions
topology and site links with Azure Virtual Site link properties and change
Network to optimize traffic and notification
minimize cost? Replication compression
IP addressing and DNS How to configure IP addresses and Use the Use the Set-
name resolution? AzureStaticVNetIP cmdlet to assign a
static IP address
Install Windows Server DNS server
and configure the virtual network
properties with the name and IP
address of the VM that hosts the DC
and DNS server roles
Geo-distributed DCs How to replicate to DCs on separate If your Active Directory site topology
virtual networks? requires DCs in geographies that
corresponds to different Azure regions,
than you want to create Active
Directory sites accordingly. Configure
virtual network to virtual network
Connectivity to replicate between
domain controllers on separate virtual
networks.
Read-only DCs Use read-only or writeable DCs? Filter HBI/PII attributes

Filter secrets
Limit outbound traffic
Global catalog Install global catalog? For single-domain forest, make all
DCs GCs
For multidomain forest, GCs are
required for authentication
Installation method How to install DC in Azure? Either:

Install AD DS using Windows
PowerShell or Dcpromo
Move VHD of an on-premises virtual
DC
WINDOWS SERVER ACTIVE DIRECTORY
TECHNOLOGY AREA DECISIONS FACTORS
Placement of the Windows Server AD Where to store Windows Server AD DS Change Dcpromo.exe default values.
DS database and SYSVOL database, logs, and SYSVOL? These critical Active Directory files must
be placed on Azure Data Disks instead
of Operating System disks that
implement write caching.
Backup and Restore How to safeguard and recover data? Create system state backups
Federation server configuration Deploy a new forest with federation Security

in the cloud? Compliance
Deploy AD FS on-premises and Cost
expose a proxy in the cloud? Access to applications by business
partners
Cloud services configuration A cloud service is implicitly deployed the Does a VM or VMs require direct
first time you create a virtual machine. exposure to the Internet?
Do you need to deploy additional cloud Does the service require load-
services? balancing?
Federation server requirements for Does the Windows Server AD FS Create one cloud-service for each virtual
public and private IP addressing instance need to be reached directly IP address that is required by your
(dynamic IP vs. virtual IP) from the Internet? deployment
Does the application being deployed
in the cloud require its own Internet-
facing IP address and port?
Windows Server AD FS high availability How many nodes in my Windows Resiliency and fault tolerance
configuration Server AD FS server farm?
How many nodes to deploy in my
Windows Server AD FS proxy farm?
Network topology
In order to meet the IP address consistency and DNS requirements of Windows Server AD DS, it is necessary to first
create an Azure virtual network and attach your virtual machines to it. During its creation, you must decide whether
to optionally extend connectivity to your on-premises corporate network, which transparently connects Azure
virtual machines to on-premises machines — this is achieved using traditional VPN technologies and requires that
a VPN endpoint be exposed on the edge of the corporate network. That is, the VPN is initiated from Azure to the
corporate network, not vice-versa.
Note that additional charges apply when extending a virtual network to your on-premises network beyond the
standard charges that apply to each VM. Specifically, there are charges for CPU time of the Azure Virtual Network
gateway and for the egress traffic generated by each VM that communicates with on-premises machines across the
VPN. For more information about network traffic charges, see Azure pricing at-a-glance.
DC deployment configuration
The way you configure the DC depends on the requirements for the service you want to run on Azure. For example,
you might deploy a new forest, isolated from your own corporate forest, for testing a proof-of-concept, a new
application, or some other short term project that requires directory services but not specific access to internal
corporate resources.
As a benefit, an isolated forest DC does not replicate with on-premises DCs, resulting in less outbound network
traffic generated by the system itself, directly reducing costs. For more information about network traffic charges,
see Azure pricing at-a-glance.
As another example, suppose you have privacy requirements for a service, but the service depends on access to
your internal Windows Server Active Directory. If you are allowed to host data for the service in the cloud, you
might deploy a new child domain for your internal forest on Azure. In this case, you can deploy a DC for the new
child domain (without the global catalog in order to help address privacy concerns). This scenario, along with a
replica DC deployment, requires a virtual network for connectivity with your on-premises DCs.
If you create a new forest, choose whether to use Active Directory trusts or Federation trusts. Balance the
requirements dictated by compatibility, security, compliance, cost, and resiliency. For example, to take advantage of
selective authentication you might choose to deploy a new forest on Azure and create a Windows Server Active
Directory trust between the on-premises forest and the cloud forest. If the application is claims-aware, however,
you might deploy federation trusts instead of Active Directory forest trusts. Another factor will be the cost to either
replicate more data by extending your on-premises Windows Server Active Directory to the cloud or generate more
outbound traffic as a result of authentication and query load.
Requirements for availability and fault tolerance also affect your choice. For example, if the link is interrupted,
applications leveraging either a Kerberos trust or a federation trust are all likely entirely broken unless you have
deployed sufficient infrastructure on Azure. Alternative deployment configurations such as replica DCs (writeable or
RODCs) increase the likelihood of being able to tolerate link outages.
Windows Server Active Directory site topology
You need to correctly define sites and site links in order to optimize traffic and minimize cost. Sites, site-links, and
subnets affect the replication topology between DCs and the flow of authentication traffic. Consider the following
traffic charges and then deploy and configure DCs according to the requirements of your deployment scenario:
There is a nominal fee per hour for the gateway itself:
It can be started and stopped as you see fit
If stopped, Azure VMs are isolated from the corporate network
Inbound traffic is free
Outbound traffic is charged, according to Azure pricing at-a-glance. You can optimize site link properties
between on-premises sites and the cloud sites as follows:
If you are using multiple virtual networks, configure the site-links and their costs appropriately to prevent
Windows Server AD DS from prioritizing the Azure site over one that can provide the same levels of
service at no charge. You might also consider disabling the Bridge all site link (BASL) option (which is
enabled by default). This ensures that only directly-connected sites replicate with one another. DCs in
transitively connected sites are no longer able to replicate directly with each other, but must replicate
through a common site or sites. If the intermediary sites become unavailable for some reason, replication
between DCs in transitively connected sites will not occur even if connectivity between the sites is
available. Finally, where sections of transitive replication behavior remain desirable, create site link
bridges that contain the appropriate site-links and sites, such as on-premises, corporate network sites.
Configure site link costs appropriately to avoid unintended traffic. For example, if Try Next Closest Site
setting is enabled, make sure the virtual network sites are not the next closest by increasing the cost
associated of the site-link object that connects the Azure site back to the corporate network.
Configure site link intervals and schedules according to consistency requirements and rate of object
changes. Align replication schedule with latency tolerance. DCs replicate only the last state of a value, so
decreasing the replication interval can save costs if there is a sufficient object change rate.
If minimizing costs is a priority, ensure replication is scheduled and change notification is not enabled. This is the
default configuration when replicating between sites. This is not important if you are deploying an RODC on a
virtual network because the RODC will not replicate any changes outbound. But if you deploy a writable DC, you
should make sure the site link is not configured to replicate updates with unnecessary frequency. If you deploy a
global catalog server (GC), make sure that every other site that contains a GC replicates domain partitions from
a source DC in a site that is connected with a site-link or site-links that have a lower cost than the GC in the
Azure site.
It is possible to further still reduce network traffic generated by replication between sites by changing the
replication compression algorithm. The compression algorithm is controlled by the REG_DWORD registry entry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator compression
algorithm. The default value is 3, which correlates to the Xpress Compress algorithm. You can change the value
to 2, which changes the algorithm to MSZip. In most cases, this will increase the compression, but it does so at
the expense of CPU utilization. For more information, see How Active Directory replication topology works.
IP addressing and DNS
Azure virtual machines are allocated “DHCP-leased addresses” by default. Because Azure virtual network dynamic
addresses persist with a virtual machine for the lifetime of the virtual machine, the requirements of Windows
Server AD DS are met.
As a result, when you use a dynamic address on Azure, you are in effect using a static IP address because it is
routable for the period of the lease, and the period of the lease is equal to the lifetime of the cloud service.
However, the dynamic address is deallocated if the VM is shutdown. To prevent the IP address from being
deallocated, you can use Set-AzureStaticVNetIP to assign a static IP address.
For name resolution, deploy your own (or leverage your existing) DNS server infrastructure; Azure-provided DNS
does not meet the advanced name resolution needs of Windows Server AD DS. For example, it does not support
dynamic SRV records, and so on. Name resolution is a critical configuration item for DCs and domain-joined clients.
DCs must be capable of registering resource records and resolving other DC’s resource records. For fault tolerance
and performance reasons, it is optimal to install the Windows Server DNS service on the DCs running on Azure.
Then configure the Azure virtual network properties with the name and IP address of the DNS server. When other
VMs on the virtual network start, their DNS client resolver settings will be configured with DNS server as part of the
dynamic IP address allocation.
NOTE
You cannot join on-premises computers to a Windows Server AD DS Active Directory domain that is hosted on Azure directly
over the Internet. The port requirements for Active Directory and the domain-join operation render it impractical to directly
expose the necessary ports and in effect, an entire DC to the Internet.
VMs register their DNS name automatically on startup or when there is a name change.
For more information about this example and another example that shows how to provision the first VM and install
AD DS on it, see Install a new Active Directory forest on Microsoft Azure. For more information about using
Windows PowerShell, see Install Azure PowerShell and Azure Management Cmdlets.
Geo -distributed DCs
Azure offers advantages when hosting multiple DCs on different virtual networks:
Multi-site fault-tolerance
Physical proximity to branch offices (lower latency)
For information about configuring direct communication between virtual networks, see Configure virtual network
to virtual network connectivity.
Read-only DCs
You need to choose whether to deploy read-only or writeable DCs. You might be inclined to deploy RODCs because
you will not have physical control over them, but RODCs are designed to be deployed in locations where their
physical security is at risk, such as branch offices.
Azure does not present the physical security risk of a branch office, but RODCs might still prove to be more cost
effective because the features they provide are well-suited to these environments albeit for very different reasons.
For example, RODCs have no outbound replication and are able to selectively populate secrets (passwords). On the
downside, the lack of these secrets might require on-demand outbound traffic to validate them as a user or
computer authenticates. But secrets can be selectively prepopulated and cached.
RODCs provide an additional advantage in and around HBI and PII concerns because you can add attributes that
contain sensitive data to the RODC filtered attribute set (FAS). The FAS is a customizable set of attributes that are
not replicated to RODCs. You can use the FAS as a safeguard in case you are not permitted or do not want to store
PII or HBI on Azure. For more information, see [RODC filtered attribute
set[(https://technet.microsoft.com/library/cc753459)].
Make sure that applications will be compatible with RODCs you plan to use. Many Windows Server Active
Directory-enabled applications work well with RODCs, but some applications can perform inefficiently or fail if they
do not have access to a writable DC. For more information, see Read-Only DCs application compatibility guide.
Global catalog
You need to choose whether to install a global catalog (GC). In a single domain forest, you should configure all DCs
as global catalog servers. It will not increase costs because there will be no additional replication traffic.
In a multidomain forest, GCs are necessary to expand Universal Group memberships during the authentication
process. If you do not deploy a GC, workloads on the virtual network that authenticate against a DC on Azure will
indirectly generate outbound authentication traffic to query GCs on-premises during each authentication attempt.
The costs associated with GCs are less-predictable because they host every domain (in-part). If the workload hosts
an Internet-facing service and authenticates users against Windows Server AD DS, the costs could be completely
unpredictable. To help reduce GC queries outside of the cloud site during authentication, you can enable Universal
Group Membership Caching.
Installation method
You need to choose how to install the DCs on the virtual network:
Promote new DCs. For more information, see Install a new Active Directory forest on an Azure virtual network.
Move the VHD of an on-premises virtual DC to the cloud. In this case, you must ensure that the on-premises
virtual DC is “moved,” not “copied” or “cloned.”
Use only Azure virtual machines for DCs (as opposed to Azure “web” or “worker” role VMs). They are durable and
durability of state for a DC is required. Azure virtual machines are designed for workloads such as DCs.
Do not use SYSPREP to deploy or clone DCs. The ability to clone DCs is only available beginning in Windows Server
2012. The cloning feature requires support for VMGenerationID in the underlying hypervisor. Hyper-V in Windows
Server 2012 and Azure virtual networks both support VMGenerationID, as do third-party virtualization software
vendors.
Placement of the Windows Server AD DS database and SYSVOL
Select where to locate the Windows Server AD DS database, logs, and SYSVOL. They must be deployed on Azure
Data disks.
NOTE
Azure Data disks are constrained to 1 TB.
Data disk drives do not cache writes by default. Data disk drives that are attached to a VM use write-through
caching. Write-through caching makes sure the write is committed to durable Azure storage before the transaction
is complete from the perspective of the VM’s operating system. It provides durability, at the expense of slightly
slower writes.
This is important for Windows Server AD DS because write-behind disk-caching invalidates assumptions made by
the DC. Windows Server AD DS attempts to disable write caching but it is up to the disk IO system to honor it.
Failure to disable write caching may, under certain circumstances, introduce USN rollback resulting in lingering
objects and other problems.
As a best practice for virtual DCs, do the following:
Set the Host Cache Preference setting on the Azure data disk for NONE. This prevents issues with write caching
for AD DS operations.
Store the database, logs, and SYSVOL on the either same data disk or separate data disks. Typically, this is a
separate disk from the disk used for the operating system itself. The key takeaway is that the Windows Server
AD DS database and SYSVOL must not be stored on an Azure Operating System disk type. By default, the AD DS
installation process installs these components in %systemroot% folder, which is NOT recommended for Azure.
Backup and restore
Be aware of what is and is not supported for backup and restore of a DC in general, and more specifically, those
running in a VM. See Backup and Restore Considerations for Virtualized DCs.
Create system state backups by using only backup software that is specifically aware of backup requirements for
Windows Server AD DS, such as Windows Server Backup.
Do not copy or clone VHD files of DCs instead of performing regular backups. Should a restore ever be required,
doing so using cloned or copied VHDs without Windows Server 2012 and a supported hypervisor will introduce
USN bubbles.
Federation server configuration
The configuration of Windows Server AD FS federation servers (STSs) depends in part on whether the applications
that you want to deploy on Azure need to access resources on your on-premises network.
If the applications meet the following criteria, you could deploy the applications in isolation from your on-premises
network.
They accept SAML security tokens
They are exposable to the Internet
They do not access on-premises resources
In this case, configure Windows Server AD FS STSs as follows:
1. Configure an isolated single-domain forest on Azure.
2. Provide federated access to the forest by configuring a Windows Server AD FS federation server farm.
3. Configure Windows Server AD FS (federation server farm and federation server proxy farm) in the on-premises
forest.
4. Establish a federation trust relationship between the on-premises and Azure instances of Windows Server AD
FS.
On the other hand, if the applications require access to on-premises resources, you could configure Windows
Server AD FS with the application on Azure as follows:
1. Configure connectivity between on-premises networks and Azure.
2. Configure a Windows Server AD FS federation server farm in the on-premises forest.
3. Configure a Windows Server AD FS federation server proxy farm on Azure.
This configuration has the advantage of reducing the exposure of on-premises resources, similar to configuring
Windows Server AD FS with applications in a perimeter network.
Note that in either scenario, you can establish trusts relationships with more identity providers, if business-to-
business collaboration is needed.
Cloud services configuration
Cloud services are necessary if you want to expose a VM directly to the Internet or to expose an Internet-facing
load-balanced application. This is possible because each cloud service offers a single configurable virtual IP address.
Federation server requirements for public and private IP addressing (dynamic IP vs. virtual IP)
Each Azure virtual machine receives a dynamic IP address. A dynamic IP address is a private address accessible only
within Azure. In most cases, however, it will be necessary to configure a virtual IP address for your Windows Server
AD FS deployments. The virtual IP is necessary to expose Windows Server AD FS endpoints to the Internet, and will
be used by federated partners and clients for authentication and ongoing management. A virtual IP address is a
property of a cloud service which contains one or more Azure virtual machines. If the claims-aware application
deployed on Azure and Windows Server AD FS are both Internet-facing and share common ports, each will require
a virtual IP address of its own and it will therefore be necessary to create one cloud service for the application and a
second for Windows Server AD FS.
For definitions of the terms virtual IP address and dynamic IP address, see Terms and definitions.
Windows Server AD FS high availability configuration
While it is possible to deploy standalone Windows Server AD FS federation services, it is recommended to deploy a
farm with at least two nodes for both AD FS STS and proxies for production environments.
See AD FS 2.0 deployment topology considerations in the AD FS 2.0 Design Guide to decide which deployment
configuration options best suit your particular needs.
NOTE
In order to get load balancing for Windows Server AD FS endpoints on Azure, configure all members of the Windows Server
AD FS farm in the same cloud service, and use the load balancing capability of Azure for HTTP (default 80) and HTTPS ports
(default 443). For more information, see Azure load-balancer probe. Windows Server Network Load Balancing (NLB) is not
supported on Azure.
Install a replica Active Directory domain controller in
an Azure virtual network
This article discusses how to install additional domain controllers (DCs) to be used as replica DCs for an on-
premises Active Directory domain on Azure virtual machines (VMs) in an Azure virtual network. You can also
install a Windows Server Active Directory forest on an Azure virtual network. For how to install Active Directory
Domain Services (AD DS) on an Azure virtual network, see Guidelines for Deploying Windows Server Active
Directory on Azure Virtual Machines.
Scenario diagram
In this scenario, external users need to access applications that run on domain-joined servers. The VMs that run
the application servers and the replica DCs are installed in an Azure virtual network. The virtual network can be
connected to the on-premises network by ExpressRoute, or you can use a site-to-site VPN connection, as shown:
The application servers and the DCs are deployed within separate cloud services to distribute compute processing
and within availability sets for improved fault tolerance. The DCs replicate with each other and with on-premises
DCs by using Active Directory replication. No synchronization tools are needed.
Create an on-premises Active Directory site for the Azure virtual

network
You can create a site in Active Directory that represents the network region corresponding to the virtual network.
This site can help optimize authentication, replication, and other DC location operations. The following steps
explain how to create a site, and for more background, see Adding a New Site.
1. Open Active Directory Sites and Services: Server Manager > Tools > Active Directory Sites and Services.
2. Create a site to represent the region where you created an Azure virtual network: click Sites > Action > New
site > type the name of the new site, such as Azure US West > select a site link > OK.
3. Create a subnet and associate with the new site: double-click Sites > right-click Subnets > New subnet >
type the IP address range of the virtual network (such as 10.1.0.0/16 in the scenario diagram) > select the new
Azure site > OK.
Create an Azure virtual network

To create an Azure virtual network and set up site-to-site VPN, follow the steps included in the article Create a
Site-to-Site connection.
You can also configure the virtual network gateway to create a secure site-to-site VPN connection. Create the site-
to-site VPN connection between the new virtual network and an on-premises VPN device. For instructions, see
Configure a Virtual Network Gateway.
Create Azure VMs for the DC roles

To create VMs to host the DC role, repeat the steps in Create a Windows virtual machine with the Azure portal as
needed. Deploy at least two virtual DCs to provide fault tolerance and redundancy. If the Azure virtual network has
at least two DCs that are similarly configured, you can place the VMs that run those DCs in an availability set for
improved fault tolerance.
To create the VMs by using Windows PowerShell instead of the Azure portal, see Use Azure PowerShell to create
and preconfigure Windows-based Virtual Machines.
Reserve a static IP address for VMs that will run the DC role. To reserve a static IP address, download the Microsoft
Web Platform Installer and install Azure PowerShell and run the Set-AzureStaticVNetIP cmdlet. For example:
Get-AzureVM -ServiceName AzureDC1 -Name AzureDC1 | Set-AzureStaticVNetIP -IPAddress 10.0.0.4 | Update-AzureVM
For more information about setting a static IP address, see Configure a static internal IP address for a VM.
Install AD DS on Azure VMs

Sign in to a VM and verify that you have connectivity across the site-to-site VPN or ExpressRoute connection to
resources on your on-premises network. Then install AD DS on the Azure VMs. You can use same process that you
use to install an additional DC on your on-premises network (UI, Windows PowerShell, or an answer file). As you
install AD DS, make sure you specify the new volume for the location of the AD database, logs and SYSVOL. If you
need a refresher on AD DS installation, see Install Active Directory Domain Services (Level 100) or Install a Replica
Windows Server 2012 Domain Controller in an Existing Domain (Level 200).
Reconfigure DNS server for the virtual network

1. To get a list of virtual network names, in the Azure portal, search for Virtual networks, then select Virtual
networks to view the list.
2. Open the virtual network you want to manage, and then reconfigure the DNS server IP addresses for your
virtual network to use the static IP addresses assigned to the replica DCs instead of the IP addresses for on-
premises DNS servers.
3. To ensure that all the replica DC VMs on the virtual network are configured with to use DNS servers on the
virtual network:
a. Select Virtual Machines.
b. Select the VMs, and then Select Restart.
c. Wait until the VM is Running again, and then sign into it.
Create VMs for application servers

To create VMs to host the application server role, repeat the steps in Create a Windows virtual machine with the
Azure portal as needed. To create the VMs by using Microsoft PowerShell instead of the Azure portal, see Use
Azure PowerShell to create and configure Windows-based Virtual Machines. The following table contains
suggested settings.
SETTING VALUES
Choose an Image Windows Server 2012 R2 Datacenter
Virtual Machine Configuration Virtual Machine Name: Type a single label name (such as
AppServer1).
New User Name: Type the name of a user. This user will
be a member of the local Administrators group on the
VM. You will need this name to sign in to the VM for the
first time. The built-in account named Administrator will
not work.
New Password/Confirm: Type a password
Virtual Machine Configuration Cloud Service: Choose Create a new cloud service for
the first VM and select that same cloud service name
when you create more VMs that will host the application.
Cloud Service DNS Name: Specify a globally unique name
Region/Affinity Group/Virtual Network: Specify the virtual
network name (such as WestUSVNet).
Storage Account: Choose Use an automatically
generated storage account for the first VM and then
select that same storage account name when you create
more VMs that will host the application.
Availability Set: Choose Create an availability set.
Availability set name: Type a name for the availability set
when you create the first VM and then select that same
name when you create more VMs.
Virtual Machine Configuration Select Install the VM Agent and any other extensions
you need.
After each VM is provisioned, sign in and join it to the domain.

1. In Server Manager > Local Server > WORKGROUP > Change…, select Domain.
2. Enter the name of your on-premises domain.
3. Provide credentials of a domain user.
4. Restart the VM.
Additional resources
For more information about using Windows PowerShell, see Get Started with Azure Cmdlets and Azure Cmdlet
Reference.
How to upload existing on-premises Hyper-V domain controllers to Azure by using Azure PowerShell
Azure Virtual Network
Azure PowerShell
Azure Management Cmdlets
Install a new Active Directory forest on an Azure
virtual network
This article shows how to create a new Windows Server Active Directory environment on a virtual machine (VM)
on an Azure virtual network. In this case, the Azure virtual network is not connected to an on-premises network.
You might also be interested in these related articles:
For a video that shows these steps, see How to install a new Active Directory forest on an Azure virtual
network
You can optionally configure a site-to-site VPN and then either install a new forest or extend an on-premises
forest to an Azure virtual network. For those steps, see Install a Replica Active Directory Domain Controller in
an Azure Virtual Network.
For conceptual guidance about installing Active Directory Domain Services (AD DS) on an Azure virtual
network, see Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines.
Scenario Diagram
In this scenario, external users need to access applications that run on domain-joined servers. The VMs that run
the application servers and the VMs that run domain controllers are installed installed in their own cloud service
in an Azure virtual network. They are also included within an availability set for improved fault tolerance.
How does this differ from on-premises?

There is not much difference between installing a domain controller on Azure versus on-premises. The main
differences are listed in the following table.
TO CONFIGURE... ON-PREMISES AZURE VIRTUAL NETWORK
IP address for the domain Assign static IP address on the network Run the Set-AzureStaticVNetIP cmdlet
controller adapter properties to assign a static IP address
DNS client resolver Set Preferred and Alternate DNS server Set DNS server address on the the
address on the network adapter virtual network properties
properties of domain members
Active Directory database storage Optionally change the default storage You need to change default storage
location from C:\ location from C:\
Create an Azure virtual network

2. Create a virtual network. Click Networks > Create a virtual network. Use the values in the following
table to complete the wizard.
ON THIS WIZARD PAGE… SPECIFY THESE VALUES
Virtual Network Details Name: Enter a name for your virtual network
Region: Choose the closest region
DNS and VPN Leave DNS server blank

Don't select either VPN option
Virtual network address spaces Subnet name: Enter a name for your subnet
Starting IP: 10.0.0.0
CIDR: /24 (256)
Create VMs to run the domain controller and DNS server roles
Repeat the following steps to create VMs to host the DC role as needed. You should deploy at least two virtual
DCs to provide fault tolerance and redundancy. If the Azure virtual network includes at least two DCs that are
similarly configured (that is, they are both GCs, run DNS server, and neither holds any FSMO role, and so on) then
place the VMs that run those DCs in an availability set for improved fault tolerance.
To create the VMs by using Windows PowerShell instead of the UI, see Use Azure PowerShell to create and
preconfigure Windows-based Virtual Machines.
1. In the Azure portal, select New > Compute, and then select a virtual machine. Use the following values to
complete the wizard. Accept the default value for a setting unless another value is suggested or required.

Virtual Machine Configuration Virtual Machine Name: Type a single label name (such
as AzureDC1).
New User Name: Type the name of a user. This user
will be a member of the local Administrators group
on the VM. You will need this name to sign in to the
VM for the first time. The built-in account named
Administrator will not work.
Virtual Machine Configuration Cloud Service: Choose Create a new cloud service
for the first VM and select that same cloud service
name when you create more VMs that will host the
DC role.
Cloud Service DNS Name: Specify a globally unique
name
Region/Affinity Group/Virtual Network: Specify the
virtual network name (such as WestUSVNet).
generated storage account for the first VM and
then select that same storage account name when
you create more VMs that will host the DC role.
Availability set name: Type a name for the availability
set when you create the first VM and then select that
same name when you create more VMs.
Virtual Machine Configuration Select Install the VM Agent and any other
extensions you need.
2. Attach a disk to each VM that will run the DC server role. The additional disk is needed to store the AD
database, logs, and SYSVOL. Specify a size for the disk (such as 10 GB) and leave the Host Cache Preference
set to None. For the steps, see How to Attach a Data Disk to a Windows Virtual Machine.
3. After you first sign in to the VM, open Server Manager > File and Storage Services to create a volume on
this disk using NTFS.
4. Reserve a static IP address for VMs that will run the DC role. To reserve a static IP address, download the
Microsoft Web Platform Installer and install Azure PowerShell and run the Set-AzureStaticVNetIP cmdlet.
For example:
Get-AzureVM -ServiceName AzureDC1 -Name AzureDC1 | Set-AzureStaticVNetIP -IPAddress 10.0.0.4 | Update-
AzureVM
For more information about setting a static IP address, see Configure a Static Internal IP Address for a VM.
Install Windows Server Active Directory

Use the same routine to install AD DS that you use on-premises (that is, you can use the UI, an answer file, or
Windows PowerShell). You need to provide Administrator credentials to install a new forest. To specify the
location for the Active Directory database, logs, and SYSVOL, change the default storage location from the
operating system drive to the additional data disk that you attached to the VM.
After the DC installation finishes, connect to the VM again and log on to the DC. Remember to specify domain
credentials.
Reset the DNS server for the Azure virtual network

1. Reset the DNS forwarder setting on the new DC/DNS server.
a. In Server Manager, click Tools > DNS.
b. In DNS Manager, right-click the name of the DNS server and click Properties.
c. On the Forwarders tab, click the IP address of the forwarder and click Edit. Select the IP address and
click Delete.
d. Click OK to close the editor and Ok again to close the DNS server properties.
2. Update the DNS server setting for the virtual network.
a. Click Virtual Networks > double-click the virtual network you created > Configure > DNS servers,
type the name and the IP of one of the VMs that runs the DC/DNS server role and click Save.
b. Select the VM and click Restart to trigger the VM to configure DNS resolver settings with the IP address
of the new DNS server.
Create VMs for domain members

1. Repeat the following steps to create VMs to run as application servers. Accept the default value for a
setting unless another value is suggested or required.
Virtual Machine Configuration Virtual Machine Name: Type a single label name (such
as AppServer1).
New User Name: Type the name of a user. This user
will be a member of the local Administrators group
on the VM. You will need this name to sign in to the
VM for the first time. The built-in account named
Administrator will not work.
Virtual Machine Configuration Cloud Service: Choose Create a new cloud service
for the first VM and select that same cloud service
name when you create more VMs that will host the
application.
Cloud Service DNS Name: Specify a globally unique
name
Region/Affinity Group/Virtual Network: Specify the
virtual network name (such as WestUSVNet).
generated storage account for the first VM and
then select that same storage account name when
you create more VMs that will host the application.
Availability set name: Type a name for the availability
set when you create the first VM and then select that
same name when you create more VMs.
Virtual Machine Configuration Select Install the VM Agent and any other
extensions you need.
2. After each VM is provisioned, sign in and join it to the domain. In Server Manager, click Local Server >
WORKGROUP > Change… and then select Domain and type the name of your on-premises domain. Provide
credentials of a domain user, and then restart the VM to complete the domain join.
To create the VMs by using Windows PowerShell instead of the UI, see Use Azure PowerShell to create and
preconfigure Windows-based Virtual Machines.
For more information about using Windows PowerShell, see Get Started with Azure Cmdlets and Azure Cmdlet
Reference.
See Also
How to install a new Active Directory forest on an Azure virtual network
Configure a Site-to-Site VPN
Install a Replica Active Directory Domain Controller in an Azure virtual network
Virtual Network Overview
Azure PowerShell
Set Azure VM Static IP Address
How to assign Static IP to Azure VM
Install a New Active Directory Forest
Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)
1 min to read •
Edit O nline
High availability cross-geographic AD FS deployment
in Azure with Azure Traffic Manager
AD FS deployment in Azure provides step-by-step guideline as to how you can deploy a simple AD FS
infrastructure for your organization in Azure. This article provides the next steps to create a cross-geographic
deployment of AD FS in Azure using Azure Traffic Manager. Azure Traffic Manager helps create a geographically
spread high availability and high-performance AD FS infrastructure for your organization by making use of range
of routing methods available to suit different needs from the infrastructure.
A highly available cross-geographic AD FS infrastructure enables:
Elimination of single point of failure: With failover capabilities of Azure Traffic Manager, you can achieve a
highly available AD FS infrastructure even when one of the data centers in a part of the globe goes down
Improved performance: You can use the suggested deployment in this article to provide a high-performance
AD FS infrastructure that can help users authenticate faster.
Design principles
The basic design principles will be same as listed in Design principles in the article AD FS deployment in Azure. The
diagram above shows a simple extension of the basic deployment to another geographical region. Below are some
points to consider when extending your deployment to new geographical region
Virtual network: You should create a new virtual network in the geographical region you want to deploy
additional AD FS infrastructure. In the diagram above you see Geo1 VNET and Geo2 VNET as the two virtual
networks in each geographical region.
Domain controllers and AD FS servers in new geographical VNET: It is recommended to deploy domain
controllers in the new geographical region so that the AD FS servers in the new region do not have to contact a
domain controller in another far away network to complete an authentication and thereby improving the
performance.
Storage accounts: Storage accounts are associated with a region. Since you will be deploying machines in a
new geographic region, you will have to create new storage accounts to be used in the region.
Network Security Groups: As storage accounts, Network Security Groups created in a region cannot be used
in another geographical region. Therefore, you will need to create new network security groups similar to those
in the first geographical region for INT and DMZ subnet in the new geographical region.
DNS Labels for public IP addresses: Azure Traffic Manager can refer to endpoints ONLY via DNS labels.
Therefore, you are required to create DNS labels for the External Load Balancers’ public IP addresses.
Azure Traffic Manager: Microsoft Azure Traffic Manager allows you to control the distribution of user traffic to
your service endpoints running in different datacenters around the world. Azure Traffic Manager works at the
DNS level. It uses DNS responses to direct end-user traffic to globally-distributed endpoints. Clients then
connect to those endpoints directly. With different routing options of Performance, Weighted and Priority, you
can easily choose the routing option best suited for your organization’s needs.
V-net to V-net connectivity between two regions: You do not need to have connectivity between the virtual
networks itself. Since each virtual network has access to domain controllers and has AD FS and WAP server in
itself, they can work without any connectivity between the virtual networks in different regions.
Steps to integrate Azure Traffic Manager

Deploy AD FS in the new geographical region
Follow the steps and guidelines in AD FS deployment in Azure to deploy the same topology in the new
geographical region.
DNS labels for public IP addresses of the Internet Facing (public) Load Balancers
As mentioned above, the Azure Traffic Manager can only refer to DNS labels as endpoints and therefore it is
important to create DNS labels for the External Load Balancers’ public IP addresses. Below screenshot shows how
you can configure your DNS label for the public IP address.
Deploying Azure Traffic Manager

Follow the steps below to create a traffic manager profile. For more information, you can also refer to Manage an
Azure Traffic Manager profile.
1. Create a Traffic Manager profile: Give your traffic manager profile a unique name. This name of the
profile is part of the DNS name and acts as a prefix for the Traffic Manager domain name label. The name /
prefix is added to .trafficmanager.net to create a DNS label for your traffic manager. The screenshot below
shows the traffic manager DNS prefix being set as mysts and resulting DNS label will be
mysts.trafficmanager.net.
2. Traffic routing method: There are three routing options available in traffic manager:
Priority
Performance
Weighted
Performance is the recommended option to achieve highly responsive AD FS infrastructure.
However, you can choose any routing method best suited for your deployment needs. The AD FS
functionality is not impacted by the routing option selected. See Traffic Manager traffic routing
methods for more information. In the sample screenshot above you can see the Performance
method selected.
3. Configure endpoints: In the traffic manager page, click on endpoints and select Add. This will open an Add
endpoint page similar to the screenshot below
For the different inputs, follow the guideline below:

Type: Select Azure endpoint as we will be pointing to an Azure public IP address.
Name: Create a name that you want to associate with the endpoint. This is not the DNS name and has no
bearing on DNS records.
Target resource type: Select Public IP address as the value to this property.
Target resource: This will give you an option to choose from the different DNS labels you have available
under your subscription. Choose the DNS label corresponding to the endpoint you are configuring.
Add endpoint for each geographical region you want the Azure Traffic Manager to route traffic to. For more
information and detailed steps on how to add / configure endpoints in traffic manager, refer to Add, disable,
enable or delete endpoints
4. Configure probe: In the traffic manager page, click on Configuration. In the configuration page, you need to
change the monitor settings to probe at HTTP port 80 and relative path /adfs/probe
NOTE
Ensure that the status of the endpoints is ONLINE once the configuration is complete. If all endpoints are in
‘degraded’ state, Azure Traffic Manager will do a best attempt to route the traffic assuming that the diagnostics is
incorrect and all endpoints are reachable.
5. Modifying DNS records for Azure Traffic Manager: Your federation service should be a CNAME to the
Azure Traffic Manager DNS name. Create a CNAME in the public DNS records so that whoever is trying to
reach the federation service actually reaches the Azure Traffic Manager.
For example, to point the federation service fs.fabidentity.com to the Traffic Manager, you would need to
update your DNS resource record to be the following:
fs.fabidentity.com IN CNAME mysts.trafficmanager.net
Test the routing and AD FS sign-in
Routing test
A very basic test for the routing would be to try ping the federation service DNS name from a machine in each
geographic region. Depending on the routing method chosen, the endpoint it actually pings will be reflected in the
ping display. For example, if you selected the performance routing, then the endpoint nearest to the region of the
client will be reached. Below is the snapshot of two pings from two different region client machines, one in EastAsia
region and one in West US.
AD FS sign-in test
The easiest way to test AD FS is by using the IdpInitiatedSignon.aspx page. In order to be able to do that, it is
required to enable the IdpInitiatedSignOn on the AD FS properties. Follow the steps below to verify your AD FS
setup
1. Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled. Set-AdfsProperties -
EnableIdPInitiatedSignonPage $true
2. From any external machine access https:///adfs/ls/IdpInitiatedSignon.aspx
3. You should see the AD FS page like below:
and on successful sign-in, it will provide you with a success message as shown below:
Related links
Basic AD FS deployment in Azure
Microsoft Azure Traffic Manager
Traffic Manager traffic routing methods
Next steps
Manage an Azure Traffic Manager profile
Add, disable, enable or delete endpoints
Change signature hash algorithm for Office 365
relying party trust
Overview
Active Directory Federation Services (AD FS) signs its tokens to Microsoft Azure Active Directory to ensure that they
cannot be tampered with. This signature can be based on SHA1 or SHA256. Azure Active Directory now supports
tokens signed with an SHA256 algorithm, and we recommend setting the token-signing algorithm to SHA256 for
the highest level of security. This article describes the steps needed to set the token-signing algorithm to the more
secure SHA256 level.
NOTE
Microsoft recommends usage of SHA256 as the algorithm for signing tokens as it is more secure than SHA1 but SHA1 still
remains a supported option.
Change the token-signing algorithm

After you have set the signature algorithm with one of the two processes below, AD FS signs the tokens for Office
365 relying party trust with SHA256. You don't need to make any extra configuration changes, and this change has
no impact on your ability to access Office 365 or other Azure AD applications.
AD FS management console
1. Open the AD FS management console on the primary AD FS server.
2. Expand the AD FS node and click Relying Party Trusts.
3. Right-click your Office 365/Azure relying party trust and select Properties.
4. Select the Advanced tab and select the secure hash algorithm SHA256.
5. Click OK.
AD FS PowerShell cmdlets
1. On any AD FS server, open PowerShell under administrator privileges.
2. Set the secure hash algorithm by using the Set-AdfsRelyingPartyTrust cmdlet.
Set-AdfsRelyingPartyTrust -TargetName 'Microsoft Office 365 Identity Platform' -SignatureAlgorithm
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
Also read
Repair Office 365 trust with Azure AD Connect
How to get support for Azure Active Directory
Microsoft provides global technical, pre-sales, billing, and subscription support for Azure Active Directory (Azure
AD). Support is available both online and by phone for Microsoft Azure paid and trial subscriptions. Phone support
and online billing support are available in additional languages.
Find help without opening a support ticket

Before creating a support ticket, check out the following resources for answers and information.
For content such as how-to information or code samples for IT professionals and developers, see the
technical documentation at docs.microsoft.com.
The Microsoft Tech Community is the place for our IT pro partners and customers to collaborate, share, and
learn. The Microsoft Tech Community Info Center is used for announcements, blog posts, ask-me-anything
(AMA) interactions with experts, and more. You can also join the community to submit your ideas.
Open a support ticket

If you are unable to find answers by using self-help resources, you can open an online support ticket. You should
open each support ticket for only a single problem, so that we can connect you to the support engineers who are
subject matter experts for your problem. Also, Azure Active Directory engineering teams prioritize their work
based on incidents that are generated, so you're often contributing to service improvements.
How to open a support ticket for Azure AD in the Azure portal
NOTE
For billing or subscription issues, you must use the Office 365 admin center.
1. Sign in to the Azure portal and open Azure Active Directory.

2. Scroll down to Troubleshooting + Support and select New support request.
3. On the Basics blade, for Issue type, select Technical.
4. For Service, select Azure Active Directory, and then select Next.
5. On the Problem blade, select a Severity).
6. Select a Problem type, and then select a Category for that type. At this point, you are also offered self-
help information for your problem category.
7. Add the rest of your problem information and click Next.
8. Provide your contact information and select Create.
How to open a support ticket for Azure AD in the Office 365 portal
NOTE
Support for Azure AD in the Office 365 admin center is offered for administrators only.
1. Sign in to the Office 365 admin center with an account that has an Enterprise Mobility + Security (EMS)
license.
2. On the Support tile, select New service request:
3. On the Support Overview page, select Identity management or User and domain management:
4. For Feature, select the Azure AD feature for which you want support.
5. For Symptom, select an appropriate symptom, summarize your issue and provide relevant details, and
then select Next.
6. Select one of the offered self-help resources, or select Yes, continue or No, cancel request.
7. If you continue, you are asked for more details. You can attach any files you have that represent the
problem, and then select Next.
8. Provide your contact information and select Submit request.
Get phone support

See the Contact Microsoft for support page to obtain support phone numbers.
Next steps
Microsoft Tech Community
Technical documentation at docs.microsoft.com
Troubleshooting: 'Active Directory' item is missing or
not available
Many of the instructions for using Azure Active Directory features and services begin with "Go to the Azure
Management Portal and click Active Directory." But what do you do if the Active Directory extension or menu item
does not appear or if it is marked Not Available? This topic is designed to help. It describes the conditions under
which Active Directory does not appear or is unavailable and explains how to proceed.
Active Directory is missing

Typically, an Active Directory item appears in the left navigation menu. The instructions in Azure Active Directory
procedures assume that this item is in your view.
The Active Directory item appears in the left navigation menu when any of the following conditions is true.
Otherwise, the item does not appear.
The current user signed on with a Microsoft account (formerly known as a Windows Live ID).
OR
The Azure tenant has a directory and the current account is a directory administrator.
OR
The Azure tenant has at least one Azure AD Access Control (ACS) namespace. For more information, see
Access Control Namespace.
OR
The Azure tenant has at least one Azure Multi-Factor Authentication provider. For more information, see
Administering Azure Multi-Factor Authentication Providers.
To create an Access Control namespace or a Multi-Factor Authentication provider, click +New > App Services >
Active Directory.
To get administrative rights to a directory, have an administrator assign an administrator role to your account. For
details, see Assigning administrator roles.
Active Directory is not available

When you click +New > App Services, an Active Directory item appears. Specifically, the Active Directory item
appears when any of the Active Directory features, such as Directory, Access Control, or Multi-Factor Auth Provider,
are available to the current user.
However, while the page is loading, the item is dimmed and is marked Not Available. This is a temporary state. If
you wait a few seconds, the item becomes available. If the delay is prolonged, refreshing the web page often
resolves the problem.
Azure Active Directory Proof of Concept Playbook:
Introduction
This article provides guidelines to explore different Azure AD capabilities in a Proof of Concept (PoC). The intended
audience of this document is Identity Architects, IT Professionals, and System Integrators
How to use this Playbook

1. Use the Theme section and pick the area(s) of interest based on your needs.
2. Scope the PoC by choosing the scenarios that align with your business goals. The shorter the better. We
recommend doing it as short and concise as possible to convey the value to the stakeholders while minimizing
the complexity to realize it.
3. Use the Implementation section to understand the scenarios, and what would they mean for your environment.
In each scenario, we describe how to set it up (what we call Building Blocks), and how to navigate the scenarios.
4. Each building block explains the pre-requisites needed, as well as an approximate time to complete. This can
help you during the planning process.
5. Based on 1-3 Above, define the Environment in which to execute. We encourage to strive for a production
environment to get a good feel of the experience for your users.
6. When having conflicting requirements, use this helpful tradeoff matrix
Theme-centric showing of value
Smoothness to prepare, to set up, and to execute the scenarios
Minimal time to execute the target scenarios
As close to production as feasible within your constraints
NOTE
Throughout this article, you will see some specific third party applications and products mentioned as examples for
convenience. Azure AD supports thousands of applications in our application gallery that you can use based on your needs
and environment.
Playbook Steps
1. Introduction
2. Ingredients
Theme
Environment
Target Users
3. Implementation
Foundation - Syncing AD to Azure AD
Extending your on-premises identity to the cloud
Assigning Azure AD licenses using Groups
Theme - Lots of apps, one identity
Integrate SaaS Applications - Federated SSO
SSO and Identity Lifecycle Events
Integrate SaaS Applications - Password SSO
Secure Access to Shared Accounts
Secure Remote Access to On-Prem Applications
Synchronize LDAP identities to Azure AD
Theme - Increase your security
Secure administrator account access
Secure access to applications
Enable Just in time (JIT) administration
Protect Identities based on risk
Authenticate without passwords using certificate based authentication
Theme - Scale with Self Service
Self Service Password Reset
Self Service Access to Applications
4. Building Blocks
Catalog of Actors
Common Prerequisites for all building blocks
Directory Synchronization - Password Hash Sync (PHS) - New Installation
Branding
Group based licensing
SaaS Federated SSO Configuration
SaaS Password SSO Configuration
SaaS Shared Accounts Configuration
App Proxy Configuration
Generic LDAP Connector configuration
Groups - Delegated Ownership
SaaS and Identity Lifecycle
Self Service Access to Application Management
Azure Multi-Factor Authentication with Phone Calls
MFA Conditional Access for SaaS applications
Privileged Identity Management (PIM)
Discovering Risk Events
Deploying Sign-in risk policies
Configuring certificate based authentication
Azure Active Directory Proof of Concept Playbook
Ingredients
Theme
Azure AD provides identity and access solutions across multiple areas in the enterprise. We classify the scenarios
in the following areas:
Lots of apps, one identity
Increase your security
Scale with Self Service
Defining a theme to frame the PoC helps to focus the efforts that resonates with business goals, which oftentimes
are the triggers of the interest in a proof of concept in the first place.
Environment
It is important to determine the details of the environment where you will deliver the PoC. Ideally you can build
upon it after the PoC is completed. The target environment is crucial and you should find the right balance
between making it as real as possible and the overhead of constraints or extra considerations. The typical
environments for PoCs are:
Production: The scenarios will be implemented in your live environment and already deployed Microsoft
Cloud services (production AD, Office 365, Azure AD tenant/SSO solution).
User Acceptance Test (UAT)/Dev environment: You have test infrastructure (parallel AD and potentially
Azure AD tenant/SSO solution) with test data that resembles production. Typically, the test environment is
shared across multiple projects in the enterprise.
Most scenarios in this guide are additive in nature. As a result, they can be deployed in the production tenant
without affecting users outside the PoC. Throughout this document, we will be calling out which scenarios would
have tenant-wide effect. In those cases, you might want to consider a non-production environment.
Target Users
It is important to determine the target set of users that will exercise the scenarios, especially when the
environment is production or test. The categories of target users for PoC are:
Pilot Users: Real users in the environment that will be using the solution with the account they use for their
day to day job functions
Test Users: Test accounts created in the environment
Most scenarios in this guide can be exercised by pilot users. Throughout this document, we will be calling out
target user considerations if needed.
Playbook Steps
1. Introduction
2. Ingredients
Theme
Environment
Target Users
3. Implementation
4. Building Blocks
Catalog of Actors
Branding
Azure Active Directory Proof of Concept Playbook:
Implementation

A hybrid identity is the foundation for most of the enterprise customers who already have an on-premises
directory. The goal here is to intentionally spend as less time here as possible to show the value of the actual
identity and access scenarios.
SCENARIO BUILDING BLOCKS
Extending your on-premises identity to the cloud Directory Synchronization - Password Hash Sync
Note: If you already have DirSync/ADSync or earlier versions
of Azure AD Connect, this step is optional. Some scenarios in
this guide might require newer version of Azure AD Connect.
Branding
Assigning Azure AD licenses using groups Group based licensing

1. Bob is the Active Directory administrator at Contoso. He gets the requirement to enable identity as a service for
a set of users. After execution of Azure AD Connect wizard, the identity of the target users available in the cloud.
2. Bob asks Susie, one of the target users, to access the Azure Active Directory access panel and confirm that she
can authenticate. Susie sees a branded login page and an empty access panel which is ready for enabling future
application access.
1. Bob is the Azure AD Global Admin and wants to allocate Azure AD licenses to a specific set of users as part of
the initial rollout of Azure AD.
2. Bob creates a group for the pilot users.
3. Bob assigns the licenses to the group
4. Susie, one of the information workers, is added to the security group as part of her job functions
5. After some time, Susie has access to the Azure AD premium license. This will enable more of the POC scenarios
later on.

Integrate SaaS Applications - Federated SSO SaaS Federated SSO Configuration

Integrate SaaS Applications - Password SSO SaaS Password SSO Configuration
SSO and Identity Lifecycle Events SaaS and Identity Lifecycle
Secure Access to Shared Accounts SaaS Shared Accounts Configuration

Secure Remote Access to On-Premises Applications App Proxy Configuration
Synchronize LDAP identities to Azure AD Generic LDAP Connector configuration

1. Bob is the Azure AD Global Admin and receives a request from the Marketing department to enable access to
their ServiceNow Instance. Bob finds the step-by-step tutorial in Azure AD documentation and follows it, and
delegates the assignment of users to the app to Kevin, the head of Marketing team.
2. Kevin logs in as the owner of ServiceNow entitlements and assigns Susie to the app. Kevin also notices that
Susie's profile was created in ServiceNow automatically
3. Susie is an information worker in the Marketing department. She logs in to azure AD and finds all SaaS
applications she is assigned to in myapps portal. From there, she seamlessly gets access to ServiceNow.
4. The Marketing department wants to audit who accessed ServiceNow. Bob downloads an activity report and
shares it with Kevin over email.
1. Susie takes a leave of absence, and by corporate policy the on-premises AD account is temporary disabled.
Susie now can't log in to Azure AD and therefore can't access ServiceNow.
2. Susie makes a lateral move from Marketing to Sales. Kevin removes her access from ServiceNow. Susie logs in
the azure ad myapps and she no longer sees the ServiceNow Tile. After 10 minutes, Kevin confirms that Susie
account was disabled from ServiceNow Management console.
1. Bob configures access to Atlassian HipChat. HipChat has Password SSO integration and grant access to Susie
2. Susie logs in to the myapps portal and sees a link to download the Azure AD IE browser extension, which she
downloads
3. Upon clicking, she gets prompted for her HipChat username and password credentials. This is a one-time
operation, and after completing it she has access to HipChat
4. A few days later, Susie opens myapps portal and clicks HipChat again. This time around, she gets seamless
access
5. Kevin, the HipChat app owner, wants to audit who accessed the application. Bob downloads an audit report and
shares it with Kevin over email.
1. Bob is tasked to secure the shared Twitter handle for members of the Sales team. He adds Twitter as an SSO
application, and assigns it to the security group of the Sales Team. He was given the credentials to the shared
account and he supplies it in the system.
2. Sharing Twitter credentials is no longer trusted due to multiple people knowing it. Bob enables automatic
rollover of the Twitter password.
3. Susie, a member of the Sales team, logs in to the myapps portal and sees a link to download the Azure AD IE
browser extension. She installs it.
4. Upon clicking she get access directly to Twitter. She does not know the password.
5. Arnold is also part of the sales team. He has the same experience as Susie in steps 3-4
6. The Sales department wants to audit who accessed Twitter. Bob downloads an activity report and shares it with
Kevin over email.
Secure Remote Access to On-Premises Applications
1. Bob, the Azure AD Global Admin, has gotten numerous requests to enable employees to access several useful
on-premises resources, such as the expenses application, while working remotely. He follows the Application
Proxy documentation to install a connector and publish Expenses as an Application Proxy application.
2. Bob share the external Expenses application URL with Susie, one of the employees who needs remote access.
She accesses the link, and after authenticating against AAD, she is able to access the Expenses app and continue
to be productive while remote.
3. Bob then continues to publish additional on-premises applications using the same process and giving access to
users as needed. He adds conditional access and multi-factor authentication for the more sensitive applications
that he publishes, to ensure additional security.
1. Bob's company has complex identity infrastructure. Most of the users are maintained inside Windows Server
Active Directory Domain Services (ADDS). Some of them, are managed by HR system inside Active Directory
Lightweight Directory Services (ADLDS).
2. Bob is tasked with enabling access to SaaS apps for all users (also these not present in ADDS).
3. Bob configures Generic LDAP Connector to pull data from ADLDS in Azure AD Connect.
4. Bob creates synchronization rules so LDAP users are populated into Metaverse and to Azure AD
5. Susie being LDAP user accesses her SaaS app using synchronized identity
IMPORTANT
This is an advanced configuration requiring some familiarity with FIM/MIM. If used in production, we advise questions about
this configuration go through Premier Support.

Secure administrator account access Azure MFA with Phone Calls
Secure access for applications Conditional Access for SaaS applications
Enable Just In Time administration Privileged Identity Management
Protect identities based on risk Discovering risk events

Authenticate without passwords using certificate based Configuring certificate based authentication
authentication

1. Bob is the Azure AD Global Administrator. He has identified Stuart as a co-administrator of the service.
2. Bob configures Stuart's account to always require MFA to improve the security posture
3. Stuart logs in to the Azure portal, and notices that he needs to register his phone number to continue the login
4. Subsequent logins from Stuart are now protected with Multi-Factor Authentication, and he now gets a phone
call to verify his identity.
1. Kevin is the business owner of ServiceNow. The company now wants those users to login with MFA when
accessing outside the corporate network.
2. Bob, our Azure AD Global admin, adds a conditional access policy to the ServiceNow application to enable MFA
for outside access
3. Susie, our information worker, logs in my apps portal and clicks the ServiceNow tile. She is now challenged
with MFA.
Enable Just in time (JIT ) administration
1. Bob and Stuart are Azure AD Global Admins. They want to enable JIT access to the management roles and also
to keep records on the usage of the privileged roles.
2. Bob enables PIM in the Azure AD tenant and becomes the security administrator. He changes both himself and
Stuart's global admin role membership from permanent to eligible.
3. Bob and Stuart now require activating their role through the Azure portal before doing any changes to Azure
AD Configuration.
1. Susie, an information worker attempts logging in from a tor browser.
2. Bob checks the Azure AD identity protection dashboard, and sees Susie's login from an anonymous IP address.
The security team wants to challenge such accesses users with MFA
3. Bob enables Azure AD Identity Protection Policy to challenge MFA for medium or higher risk events
4. Time goes by, and Susie logs in from Tor browser again. This time, she will see the MFA challenge
1. Bob is Global Administrator for financial institution, that forbids use of passwords as an authentication factor
for their applications.
2. Bob enables and enforces certificate authentication on ADFS and Azure AD
3. Susie while accessing application is prompted to authenticate using certificate

Self Service Password Reset Self Service Password Reset
Self Service Access to Applications Self Service Access to Applications

1. Bob is the Azure AD Global admin and enables Self Service Password Management to a subset of users,
including Susie.
2. Susie logs in to myapps portal and see a message to register her security information for future password reset
events.
3. Fast forward a few days, Susie forgets her password, and resets it through Azure AD portal
1. Kevin is the business owner of ServiceNow. He wants users to "sign up" for it on demand, instead of adding
them all at once
2. Bob, our Azure AD Global admin, modifies the ServiceNow application to enable self service requests
3. Susie, our information worker, logs in my apps portal and clicks the "Add more applications" button and see
ServiceNow as one of the recommended applications. Then she navigates back to my apps portal and see the
ServiceNow application.
Playbook Steps
1. Introduction
2. Ingredients
Theme
Environment
Target Users
3. Implementation
4. Building Blocks
Catalog of Actors
Branding
Azure Active Directory proof of concept playbook:
Building blocks
Catalog of roles
PROOF OF CONCEPT (POC)
ROLE DESCRIPTION RESPONSIBILITY
Identity Architecture / development This team is usually the one that They provide the environments and are
team designs the solution, implements the ones evaluating the different
prototypes, drives approvals, and scenarios from the manageability
finally hands off to operations perspective
On-Premises Identity Operations Manages the different identity sources Provide access to on-premises
team on-premises: Active Directory Forests, resources needed for the PoC
LDAP directories, HR systems, and scenarios.
Federation Identity Providers. They should be involved as little as
possible
Application Technical Owners Technical owners of the different cloud Provide details on SaaS applications
apps and services that will integrate (potentially instances for testing)
with Azure AD
Azure AD Global Admin Manages the Azure AD configuration Provide credentials to configure the
synchronization service. Usually the
same team as Identity Architecture
during PoC but separate during the
operations phase
Database team Owners of the Database infrastructure Provide access to SQL environment
(ADFS or Azure AD Connect) for
specific scenario preparations.
They should be involved as little as
possible
Network team Owners of the Network infrastructure Provide required access at the network
level for the synchronization servers to
properly access the data sources and
cloud services (firewall rules, ports
opened, IPSec rules etc.)
Security team Defines the security strategy, analyzes Provide target security evaluation
security reports from various sources, scenarios
and follows through on findings.

Following are some pre-requisites needed for any POC with Azure AD Premium.
PRE-REQUISITE RESOURCES
Azure AD tenant defined with a valid Azure subscription How to get an Azure Active Directory tenant
Note: If you already have an environment with Azure AD
Premium licenses, you can get a zero cap subscription by
navigating to https://aka.ms/accessaad
Learn more at:
https://blogs.technet.microsoft.com/enterprisemobility/2016/
02/26/azure-ad-mailbag-azure-subscriptions-and-azure-ad-
2/ and https://technet.microsoft.com/library/dn832618.aspx
Domains defined and verified Add a custom domain name to Azure Active Directory
Note: Some workloads such as Power BI could have
provisioned an azure AD tenant under the covers. To check if
a given domain is associated to a tenant, navigate to
https://login.microsoftonline.com/{domain}/v2.0/.well-
known/openid-configuration. If you get a successful
response, then the domain is already assigned to a tenant
and take over might be needed. If so, contact Microsoft for
further guidance. Learn more about the takeover options at:
What is Self-Service Signup for Azure?
Azure AD Premium or EMS trial Enabled Azure Active Directory Premium free for one month
You have assigned Azure AD Premium or EMS licenses to License yourself and your users in Azure Active Directory
PoC users
Azure AD Global Admin credentials Assigning administrator roles in Azure Active Directory
Optional but strongly recommended: Parallel lab Prerequisites for Azure AD Connect
environment as a fallback
Directory Synchronization - Password Hash Sync (PHS) - New

Installation
Approximate time to Complete: one hour for less than 1,000 PoC users
Pre -requisites
Server to Run Azure AD Connect Prerequisites for Azure AD Connect
Target POC users, in the same domain and part of a security Custom installation of Azure AD Connect
group, and OU
Azure AD Connect Features needed for the POC are Connect Active Directory with Azure Active Directory -
identified Configure sync features
You have needed credentials for on-premises and cloud Azure AD Connect: Accounts and permissions
environments
Steps
STEP RESOURCES
Download the latest version of Azure AD Connect Download Microsoft Azure Active Directory Connect
Install Azure AD Connect with the simplest path: Express Azure AD Connect: Custom installation: Domain and OU
1. Filter to the target OU to minimize the Sync Cycle time filtering
2. Choose target set of users in the on-premises group. Azure AD Connect: Custom installation: Group based filtering
3. Deploy the features needed by the other POC Themes Azure AD Connect: Integrating your on-premises identities
with Azure Active Directory: Configure Sync Features
Open the Azure AD Connect UI and see the running profiles Azure AD Connect sync: Scheduler
completed (Import, sync, and export)
Open the Azure AD management portal, go to the "All Azure AD management portal
Users" blade, add "Source of authority" column and see that
the users appear, marked properly as coming from "Windows
Server AD"
Considerations
1. Look at the security considerations of password hash sync here. If password hash sync for pilot production
users is definitively not an option, then consider the following alternatives:
Create test users in the production domain. Make sure you don't synchronize any other account
Move to an UAT environment
2. If you want to pursue federation, it is worthwhile to understand the costs associated a federated solution with
on-premises Identity Provider beyond the POC and measure that against the benefits you are looking for:
It is in the critical path so you have to design for high availability
It is an on-premises service you need to capacity plan
It is an on-premises service you need to monitor/maintain/patch
Learn more: Understanding Office 365 identity and Azure Active Directory - Federated Identity
Branding
Approximate time to Complete: 15 minutes
Pre -requisites
Assets (Images, Logos, etc.); For best visualization make sure Add company branding to your sign-in page in the Azure
the assets have the recommended sizes. Active Directory
Optional: If the environment has an ADFS server, access to AD FS user sign-in customization
the server to customize web theme
Client computer to perform end-user login experience
Optional: Mobile devices to validate experience
Steps
STEP RESOURCES
Go to Azure AD Management Portal Azure AD Management Portal - Company Branding

STEP RESOURCES
Upload the assets for the login page (hero logo, small logo, Add company branding to your sign-in and Access Panel
labels, etc.). Optionally if you have AD FS, align the same pages: Customizable Elements
assets with ADFS login pages
Wait a couple of minutes for the change to fully take effect
Log in with the POC user credential to

https://myapps.microsoft.com
Confirm the look and feel in browser Add company branding to your sign-in and Access Panel
pages
Optionally, confirm the look and feel in other devices
Considerations
If the old look and feel remains after the customization then flush the browser client cache, and retry the
operation.

Pre -requisites
All POC users are part of a security group (either cloud or Create a group and add members in Azure Active Directory
on-premises)
Steps
STEP RESOURCES
Go to licenses blade in Azure AD Management Portal Azure AD Management Portal: Licensing
Assign the licenses to the security group with POC users. Assign licenses to a group of users in Azure Active Directory
Considerations
In case of any issues, go to Scenarios, limitations, and known issues with using groups to manage licensing in

Pre -requisites
Test environment of the SaaS application available. In this Go to https://developer.servicenow.com/app.do#!/home to

guide, we use ServiceNow as an example. start the process of getting a test instance
We strongly recommend to use a test instance to minimize
friction on navigating existing data quality and mappings.
Admin access to the ServiceNow management console Tutorial: Azure Active Directory integration with ServiceNow
Target set of users to assign the application to. A security Assign a user or group to an enterprise app in Azure Active
group containing the PoC users is recommended. Directory
If creating the group is not feasible, then assign the users to
directly to the application for the PoC
Steps
STEP RESOURCES
Share the tutorial to all actors from Microsoft Documentation Tutorial: Azure Active Directory integration with ServiceNow
Set a working meeting and follow the tutorial steps with each Tutorial: Azure Active Directory integration with ServiceNow
actor.
Assign the app to the group identified in the Prerequisites. If Assign a user or group to an enterprise app in Azure Active
the POC has conditional access in the scope, you can revisit Directory
that later and add MFA, and similar. Create a group and add members in Azure Active Directory
Note this will kick in the provisioning process (if configured)
Use Azure AD management Portal to add ServiceNow Azure AD management Portal: Enterprise Applications
Application from Gallery What's new in Enterprise Application management in Azure
Active Directory
In "Single sign-on" blade of ServiceNow App enable "SAML-

based Sign-on"
Fill out "Sign on URL" and "Identifier" fields with your

ServiceNow URL
Check the box to "Make new certificate active"
and Save settings
Open "Configure ServiceNow" blade on the bottom of the

panel to view customized instructions for you to configure
ServiceNow
Follow instructions to configure ServiceNow
In "Provisioning" blade of ServiceNow App enable Managing user account provisioning for enterprise apps in
"Automatic" provisioning the new Azure portal
Wait for a few minutes while provisioning completes. In the

meantime, you can check on the provisioning reports
Log in to https://myapps.microsoft.com/ as a test user that What is the Access Panel?

has access
Click on the tile for the application that was just created.
Confirm access
Optionally, you can check the application usage reports. Note Sign-in activity reports in the Azure Active Directory portal:
there is some latency, so you need to wait some time to see Usage of managed applications
the traffic in the reports. Azure Active Directory report retention policies
Considerations
1. Above Tutorial refers to old Azure AD management experience. But PoC is based on Quick start experience.
2. If the target application is not present in the gallery, then you can use "Bring your own app". Learn more:
What's new in Enterprise Application management in Azure Active Directory: Add custom applications from
one place

Pre -requisites
Test environment for SaaS applications. An example of Twitter on Microsoft Azure Marketplace
Password SSO is HipChat and Twitter. For any other HipChat on Microsoft Azure Marketplace
application, you need the exact URL of the page with html
sign-in form.
Test accounts for the applications. Sign up for Twitter

Sign Up for Free: HipChat
Target set of users to assign the application to. A security Assign a user or group to an enterprise app in Azure Active
group contained the users is recommended. Directory
Local administrator access to a computer to deploy the Access Panel Extension for IE
Access Panel Extension for Internet Explorer, Chrome or Access Panel Extension for Chrome
Firefox Access Panel Extension for Firefox
Steps
STEP RESOURCES
Install the browser extension Access Panel Extension for IE

Access Panel Extension for Chrome
Access Panel Extension for Firefox
Configure Application from Gallery What's new in Enterprise Application management in Azure
Active Directory: The new and improved application gallery
Configure Password SSO Managing single sign-on for enterprise apps in the new
Azure portal: Password-based sign on
Assign the app to the group identified in the Prerequisites Assign a user or group to an enterprise app in Azure Active
Directory
Log in to https://myapps.microsoft.com/ as a test user that

has access
Click on the tile for the application that was just created. What is the Access Panel?: Password-based SSO without
identity provisioning
Supply the application credential What is the Access Panel?: Password-based SSO without
identity provisioning
STEP RESOURCES
Close the browser and repeat the login. This time around the
user should see seamless access to the application.
Considerations
If the target application is not present in the gallery, then you can use "Bring your own app". Learn more: What's
new in Enterprise Application management in Azure Active Directory: Add custom applications from one place
Keep in mind the following requirements:
Application should have a known login URL
The sign-in page should contain an HTML form with one more text fields that the browser extensions can
auto-populate. At the minimum, it should contain username and password.

Pre -requisites
The list of target applications and the exact sign-in URLS Twitter on Microsoft Azure Marketplace
ahead of time. As an example, you can use Twitter. Sign up for Twitter
Shared credential for this SaaS application. Sharing accounts using Azure AD
Azure AD automated password roll-over for Facebook,
Twitter and LinkedIn now in preview! - Enterprise Mobility
and Security Blog
Credentials for at least two team members who will access Assign a user or group to an enterprise app in Azure Active
the same account. They must be part of a security group. Directory
Local administrator access to a computer to deploy the Access Panel Extension for IE
Access Panel Extension for Internet Explorer, Chrome or Access Panel Extension for Chrome
Firefox Access Panel Extension for Firefox
Steps
STEP RESOURCES
Install the browser extension Access Panel Extension for IE

Access Panel Extension for Chrome
Access Panel Extension for Firefox
Configure Application from Gallery What's new in Enterprise Application management in Azure
Active Directory: The new and improved application gallery
Configure Password SSO Managing single sign-on for enterprise apps in the new
Azure portal: Password-based sign on
STEP RESOURCES
Assign the app to the group identified in the Prerequisites Assign a user or group to an enterprise app in Azure Active
while assigning them credentials Directory
Log in as different users that access app as the same shared

account.
Considerations
If the target application is not present in the gallery, then you can use "Bring your own app". Learn more: What's
new in Enterprise Application management in Azure Active Directory: Add custom applications from one place
Keep in mind the following requirements:
Application should have a known login URL
The sign-in page should contain an HTML form with one more text fields that the browser extensions can
auto-populate. At the minimum, it should contain username and password.

Pre -requisites
A Microsoft Azure AD basic or premium subscription and an Azure Active Directory editions
Azure AD directory for which you are a global administrator
A web application hosted on-prem that you would like to

configure for remote access
A server running Windows Server 2012 R2, or Windows 8.1 Understand Azure AD Application Proxy connectors
or higher, on which you can install the Application Proxy
Connector
If there is a firewall in the path, make sure that it's open so Enable Application Proxy in the Azure portal: Application
that the Connector can make HTTPS (TCP) requests to the Proxy prerequisites
Application Proxy
If your organization uses proxy servers to connect to the Work with existing on-premises proxy servers
internet, take a look at the blog post Working with existing
on-premises proxy servers for details on how to configure
them
Steps
STEP RESOURCES
Install a connector on the server Enable Application Proxy in the Azure portal: Install and
register the Connector
STEP RESOURCES
Publish the on-prem application in Azure AD as an Publish applications using Azure AD Application Proxy
Application Proxy application
Assign test users Publish applications using Azure AD Application Proxy: Add a
test user
Optionally, configure a single sign-on experience for your Provide single sign-on with Azure AD Application Proxy
users
Test app by signing in to MyApps portal as assigned user https://myapps.microsoft.com
Considerations
1. While we suggest putting the connector in your corporate network, there are cases when you will see better
performance placing it in the cloud. Learn more: Network topology considerations when using Azure Active
Directory Application Proxy
2. For further security details and how this provides a particularly secure remote access solution by only
maintaining outbound connections see: Security considerations for accessing apps remotely by using Azure
AD Application Proxy

IMPORTANT
This is an advanced configuration requiring some familiarity with FIM/MIM. If used in production, we advise questions
about this configuration go through Premier Support.
Pre -requisites
Azure AD Connect installed and configured Building block: Directory Synchronization - Password Hash
Sync
ADLDS instance meeting requirements Generic LDAP Connector technical reference: Overview of the
Generic LDAP Connector
List of workloads, that users are using and attributes Azure AD Connect sync: Attributes synchronized to Azure
associated with these workloads Active Directory
Steps
STEP RESOURCES
Add Generic LDAP Connector Generic LDAP Connector technical reference: Create a new
Connector
Create run profiles for created connector (full import, delta Create a Management Agent Run Profile
import, full synchronization, delta synchronization, export) Using connectors with the Azure AD Connect Sync Service
Manager
STEP RESOURCES
Run full import profile and verify, that there are objects in Search for a Connector Space Object
connector space Using connectors with the Azure AD Connect Sync Service
Manager: Search Connector Space
Create synchronization rules, so that objects in Metaverse Azure AD Connect sync: Best practices for changing the
have necessary attributes for workloads default configuration: Changes to Synchronization Rules
Azure AD Connect sync: Understanding Declarative
Provisioning
Azure AD Connect sync: Understanding Declarative
Start full synchronization cycle Azure AD Connect sync: Scheduler: Start the scheduler
In case of issues do troubleshooting Troubleshoot an object that is not synchronizing to Azure AD
Verify, that LDAP user can sign-in and access the application https://myapps.microsoft.com
Considerations
IMPORTANT
This is an advanced configuration requiring some familiarity with FIM/MIM. If used in production, we advise questions
about this configuration go through Premier Support.

Pre -requisites
SaaS application (Federated SSO or Password SSO) has been Building block: SaaS Federated SSO Configuration
already configured
Cloud Group that is assigned access to the application in #1 Building block: SaaS Federated SSO Configuration
is identified Create a group and add members in Azure Active Directory
Credentials for the group owner are available Manage access to resources with Azure Active Directory
groups
Credentials for the information worker accessing the apps What is the Access Panel?
has been identified
Steps
STEP RESOURCES
Identify the group that has been granted access to the Manage the settings for a group in Azure Active Directory
application, and configure the owner of given group
Log in as the group owner, see the group membership in Azure Active Directory Groups Management page
groups tab of access panel
STEP RESOURCES
Add the information worker you want to test
Log in as the information worker, confirm the tile is available What is the Access Panel?
Considerations
If the application has provisioning enabled, you might need to wait a few minutes for the provisioning to
complete before accessing the application as the information worker.

Pre -requisites
SaaS application (Federated SSO or Password SSO) has been Building block: SaaS Federated SSO Configuration
already configured
Cloud Group that is assigned access to the application in #1 Building block: SaaS Federated SSO Configuration
is identified Create a group and add members in Azure Active Directory
Credentials for the information worker accessing the apps What is the Access Panel?
has been identified
Steps
STEP RESOURCES
Remove the user from the group the app is assigned to Manage group membership for users in your Azure Active
Directory tenant
Wait for a few minutes for de-provisioning Automated SaaS App User Provisioning in Azure AD: How
does automated provisioning work?
On a separate browser session, log in as the information http://myapps.microsoft.com

worker to my apps portal and confirm that tile is missing
Considerations
Extrapolate the PoC scenario to leavers and/or leave of absence scenarios. If the user gets disabled in on-
premises AD or removed, there is no longer a way to log in to the SaaS application.

Pre -requisites
Identify POC users that will request access to the Building block: SaaS Federated SSO Configuration
applications, as part of the security group
Target Application deployed Building block: SaaS Federated SSO Configuration

Steps
STEP RESOURCES
Go to Enterprise Applications blade in Azure AD Azure AD Management Portal: Enterprise Applications

Management Portal
Configure Application from Pre-requisites with self service What's new in Enterprise Application management in Azure
Active Directory: Configure self-service application access
Log in as the information worker to my apps portal http://myapps.microsoft.com
Notice "+Add app" button on op of the page. Use it to get

access to the app
Considerations
The applications chosen might have provisioning requirements, so going immediately to the app might cause
some errors. If the application chosen supports provisioning with azure ad and it is configured, you might use
this as an opportunity to show the whole flow working end to end. See the building block for SaaS Federated
SSO Configuration for further recommendations

Pre -requisites
Enable self-service password management in your tenant. Azure Active Directory password reset for IT administrators
Enable password write-back to manage passwords from on- Password Writeback prerequisites
premises. Note this requires specific Azure AD Connect
versions
Identify the PoC users that will use this functionality, and Customize: Azure AD Password Management: Restrict Access
make sure they are members of a security group. The users to password reset
must be non-admins to fully showcase the capability
Steps
STEP RESOURCES
Navigate to Azure AD Management Portal: Password Reset Azure AD Management Portal: Password Reset
Determine the password reset policy. For POC purposes, you

can use phone call and Q & A. It is recommended to enable
registration to be required on log in to access panel
Log out and log in as an information worker
Supply the Self-Service Password Reset data as configured http://aka.ms/ssprsetup

per step 2
Close the browser

STEP RESOURCES
Start over the login process as the information worker you

used in step 4
Reset the password Update your own password: Reset my password
Try logging in with your new password to Azure AD as well

as to on-premises resources
Considerations
1. If upgrading the Azure AD Connect is going to cause friction, then consider using it against cloud accounts or
make it a demo against a separate environment
2. The administrators have a different policy and using the admin account to reset the password might taint the
PoC and cause confusion. Make sure you use a regular user account to test the reset operations

Pre -requisites
Identify POC users that will use MFA
Phone with good reception for MFA challenge What is Azure Multi-Factor Authentication?
Steps
STEP RESOURCES
Navigate to "Users and groups" blade in Azure AD Azure AD Management Portal: Users and groups
Management Portal
Choose "All users" blade
In the top bar choose "Multi-Factor Authentication" button Direct URL for Azure MFA portal: https://aka.ms/mfaportal
In the "User" settings select the PoC users and enable them User States in Azure Multi-Factor Authentication
for MFA
Login as the PoC user, and walk through the proof-up

process
Considerations
1. The PoC steps in this building block explicitly setting MFA for a user on all logins. There are other tools such as
Conditional Access, and Identity Protection that engage MFA on more targeted scenarios. This will be
something to consider when moving from POC to production.
2. The PoC steps in this building block are explicitly using Phone Calls as the MFA method for expedience. As you
transition from POC to production, we recommend using applications such as the Microsoft Authenticator as
your second factor whenever possible. Learn more: DRAFT NIST Special Publication 800-63B
Pre -requisites
Identify PoC users to target the policy. These users should be SaaS Federated SSO Configuration
in a security group to scope the conditional access policy
SaaS application has been already configured
PoC users are already assigned to the application
Credentials to the POC user are available
POC user is registered for MFA. Using a phone with Good http://aka.ms/ssprsetup
reception
Device in the internal network. IP Address configured in the Find your ip address: https://www.bing.com/search?
internal address range q=what%27s+my+ip
Device in the external network (can be a phone using the

carrier's mobile network)
Steps
STEP RESOURCES
Go to Azure AD Management Portal: Conditional Access Azure AD Management Portal: Conditional Access
blade
Create Conditional Access policy: Get started with conditional access in Azure Active Directory:
- Target PoC Users under "Users and groups" Policy configuration steps
- Target PoC Application under "Cloud apps"
- Target all locations except trusted ones under "Conditions"
-> "Locations" Note: trusted IPs are configured in MFA
Portal
- Require multi-factor authentication under "Grant"
Access application from inside corporate network Get started with conditional access in Azure Active Directory:
Testing the policy
Access application from public network Get started with conditional access in Azure Active Directory:
Testing the policy
Considerations
If you are using federation, you can use the on-premises Identity Provider (IdP) to communicate the
inside/outside corporate network state with claims. You can use this technique without having to manage the list
of IP addresses which might be complex to assess and manage in large organizations. In that setup, you need
account for the "network roaming" scenario (a user logging from the internal network, and while logged in
switches locations such as a coffee shop) and make sure you understand the implications. Learn more: Securing
cloud resources with Azure Multi-Factor Authentication and AD FS: Trusted IPs for federated users

Pre -requisites
Identify the global admin that will be part of the POC for PIM Start using Azure AD Privileged Identity Management
Identify the global admin that will become the Security Start using Azure AD Privileged Identity Management
Administrator Different administrative roles in Azure Active Directory PIM
Optional: Confirm if the global admins have email access to What is Azure AD Privileged Identity Management?:
exercise email notifications in PIM Configure the role activation settings
Steps
STEP RESOURCES
Login to https://portal.azure.com as a global admin (GA) and Using the security wizard in Azure AD Privileged Identity
bootstrap the PIM blade. The Global Admin that performs Management
this step is seeded as the security administrator. Let's call this
actor GA1
Identify the global admin and move them from permanent to Azure AD Privileged Identity Management: How to add or
eligible. This should be a separate admin from the one used remove a user role
in step 1 for clarity. Let's call this actor GA2 What is Azure AD Privileged Identity Management?:
Configure the role activation settings
Now, log in as GA2 to https://portal.azure.com and try

changing "User Settings". Notice, some options are grayed
out.
In a new tab and in the same session as step 3, navigate now How to activate or deactivate roles in Azure AD Privileged
to https://portal.azure.com and add the PIM blade to the Identity Management: Add the Privileged Identity
dashboard. Management application
Request activation to the Global Administrator role How to activate or deactivate roles in Azure AD Privileged
Identity Management: Activate a role
Note, that if GA2 never signed up for MFA, registration for

Azure MFA will be necessary
Go back to the original tab in step 3, and click the refresh

button in the browser. Note that you now have access to
change "User settings"
Optionally, if your global administrators have email enabled,

you can check GA1 and GA2's inbox and see the notification
of the role being activated
8 Check the audit history and observe the report to confirm What is Azure AD Privileged Identity Management?: Review
the elevation of GA2 is shown. role activity
Considerations
This capability is part of Azure AD Premium P2 and/or EMS E5

Pre -requisites
Device with Tor browser downloaded and installed Download Tor Browser
Access to POC user to do the login Azure Active Directory Identity Protection playbook
Steps
STEP RESOURCES
Open tor browser Download Tor Browser
Log in to https://myapps.microsoft.com with the POC user Azure Active Directory Identity Protection playbook:
account Simulating Risk Events
Wait 5-7 minutes
Log in as a global admin to https://portal.azure.com and https://aka.ms/aadipgetstarted

open up the Identity Protection blade
Open the risk events blade. You should see an entry under Azure Active Directory Identity Protection playbook:
"Sign-ins from anonymous IP addresses" Simulating Risk Events
Considerations
This capability is part of Azure AD Premium P2 and/or EMS E5

Pre -requisites
Device with Tor browser downloaded and installed Download Tor Browser
Access as a POC user to do the log in testing
POC user is registered with MFA. Make sure to use a phone Building Block: Azure Multi-Factor Authentication with Phone
with good reception Calls
Steps
STEP RESOURCES
Log in as a global admin to https://portal.azure.com and https://aka.ms/aadipgetstarted

open the Identity Protection blade
STEP RESOURCES
Enable a sign-in risk policy as follows: Azure Active Directory Identity Protection playbook: Sign-in
- Assigned to: POC user risk
- Conditions: Sign-in risk medium or higher (sign-in from
anonymous location is deemed as a medium risk level)
- Controls: Require MFA
Open tor browser Download Tor Browser
Log in to https://myapps.microsoft.com with the PoC user

account
Notice the MFA challenge Sign-in experiences with Azure AD Identity Protection: Risky
sign-in recovery
Considerations
This capability is part of Azure AD Premium P2 and/or EMS E5. To learn more about risk events visit: Azure Active
Directory risk events

Approximate time to complete: 20 minutes
Pre -requisites
Device with user certificate provisioned (Windows, iOS or Deploy User Certificates
Android) from Enterprise PKI
Azure AD domain federated with ADFS Azure AD Connect and federation

Active Directory Certificate Services Overview
For iOS devices have Microsoft Authenticator app installed Get started with the Microsoft Authenticator app
Steps
STEP RESOURCES
Enable "Certificate Authentication" on ADFS Configure Authentication Policies: To configure primary

authentication globally in Windows Server 2012 R2
Optional: Enable Certificate Authentication in Azure AD for Get started with certificate-based authentication in Azure
Exchange Active Sync clients Active Directory
Navigate to Access Panel and authenticate using User https://myapps.microsoft.com

Certificate
Considerations
To learn more about caveats of this deployment visit: ADFS: Certificate Authentication with Azure AD & Office
365
NOTE
Possession of user certificate should be guarded. Either by managing devices or with PIN in case of smart cards.
Playbook Steps
1. Introduction
2. Ingredients
Theme
Environment
Target Users
3. Implementation
4. Building Blocks
Catalog of Actors
Branding
Azure AD service limits and restrictions
This article contains the usage constraints and other service limits for the Azure Active Directory (Azure AD) service.
If you’re looking for the full set of Microsoft Azure service limits, see Azure Subscription and Service Limits, Quotas,
and Constraints.
Here are the usage constraints and other service limits for the Azure Active Directory service.
CATEGORY LIMITS
Directories A single user can only be associated with a maximum of 20

Azure Active Directory directories.
Examples of possible combinations:
A single user creates 20 directories.
A single user is added to 20 directories as a member.
A single user creates 10 directories and later is added
by others to 10 different directories.
Objects A maximum of 500,000 objects can be created in a

single directory by users of the Free edition of Azure
Active Directory.
A non-admin user can create no more than 250
objects.
Schema extensions String type extensions can have maximum of 256

characters.
Binary type extensions are limited to 256 bytes.
100 extension values (across ALL types and ALL
applications) can be written to any single object.
Only “User”, “Group”, “TenantDetail”, “Device”,
“Application” and “ServicePrincipal” entities can be
extended with “String” type or “Binary” type single-
valued attributes.
Schema extensions are available only in Graph API-
version 1.21-preview. The application must be granted
write access to register an extension.
Applications A maximum of 100 users can be owners of a single

application.
CATEGORY LIMITS
Groups A maximum of 100 users can be owners of a single

group.
Any number of objects can be members of a single
group in Azure Active Directory.
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory is limited to 15K members,
using Azure Active Directory Directory Synchronization
(DirSync).
The number of members in a group you can
synchronize from your on-premises Active Directory to
Azure Active Directory using Azure AD Connect is
limited to 50K members.
Access Panel There is no limit to the number of applications that can

be seen in the Access Panel per end user, for users
assigned licenses for Azure AD Premium or the
Enterprise Mobility Suite.
A maximum of 10 app tiles (examples: Box, Salesforce,
or Dropbox) can be seen in the Access Panel for each
end user for users assigned licenses for Free or Azure
AD Basic editions of Azure Active Directory. This limit
does not apply to Administrator accounts.
Reports A maximum of 1,000 rows can be viewed or downloaded in

any report. Any additional data is truncated.
Administrative units An object can be a member of no more than 30 administrative

units.
What's next
Sign up for Azure as an organization
How Azure subscriptions are associated with Azure AD
Active Directory
IMPORTANT
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. This is a great
time to upgrade to Azure AD Connect from Windows Azure Active Directory Sync (DirSync) or Azure AD Sync as these
tools are now deprecated are no longer supported as of April 13, 2017.

Integrating your on-premises directories with Azure AD makes your users more productive by providing a
common identity for accessing both cloud and on-premises resources. Users and organizations can take
advantage of the following:
Azure Active Directory Connect is made up of three primary components: the synchronization services, the
optional Active Directory Federation Services component, and the monitoring component named Azure AD
Connect Health.
responsible for making sure identity information for your on-premises users and groups is matching the
cloud.
AD FS - Federation is an optional part of Azure AD Connect and can be used to configure a hybrid
environment using an on-premises AD FS infrastructure. This can be used by organizations to address
complex deployments, such as domain join SSO, enforcement of AD sign-in policy, and smart card or 3rd
party MFA.

SOLUTION SCENARIO
Connect.
Express settings If you have a single forest AD then this is the

recommended option to use.
synchronization.
writeback.
running.
SOLUTION SCENARIO
preference.
TOPIC LINK

You also want to prepare for operational concerns. You might want to have a stand-by server so you easily can
fall over if there is a disaster. If you plan to make frequent configuration changes, you should plan for a staging
mode server.
TOPIC LINK

Azure AD Connect comes with several features you can optionally turn on or are enabled by default. Some
features might sometimes require more configuration in certain scenarios and topologies.
attributes.
the same password on-premises and in the cloud but only manage it in one location. Since it uses your on-
premises Active Directory as the authority, you can also use your own password policy.
Device writeback will allow a device registered in Azure AD to be written back to on-premises Active Directory so
it can be used for conditional access.
organization size.
TOPIC LINK
Password synchronization Azure AD Connect sync: Implement password

synchronization

topologies. But there are always situations where the default configuration does not work and must be adjusted.
It is supported to make changes as documented in this section and linked topics.
The default configuration assumes there might be more than one forest in the configuration. In those topologies
a user object might be represented as a contact in another forest. The user might also have a linked mailbox in
The configuration model in sync is called declarative provisioning. The advanced attribute flows are using
functions to express attribute transformations. You can see and examine the entire configuration using tools
which comes with Azure AD Connect. If you need to make configuration changes, make sure you follow the best
practices so it is easier to adopt new releases.
TOPIC LINK
configuration
TOPIC LINK


Azure AD Connect provides several features that simplify federating with Azure AD using AD FS and managing
your federation trust. Azure AD Connect supports AD FS on Windows Server 2012R2 or later.
Update SSL certificate of AD FS farm even if you are not using Azure AD Connect to manage your federation
trust.
ADFS can be configured to support multiple domains. For example you might have multiple top domains you
need to use for federation.
if your ADFS server has not been configured to automatically update certificates from Azure AD or if you use a
non-ADFS solution, then you will be notified when you have to update certificates.
TOPIC LINK

Connect

TOPIC LINK

TOPIC LINK
Monitor your on-premises identity infrastructure and
synchronization services in the cloud
Azure Active Directory (Azure AD) Connect Health helps you monitor and gain insights into your on-premises
identity infrastructure and the synchronization services. It enables you to maintain a reliable connection to Office
365 and Microsoft Online Services by providing monitoring capabilities for your key identity components such
as Active Directory Federation Services (AD FS) servers, Azure AD Connect servers (also known as Sync Engine),
Active Directory domain controllers, etc. It also makes the key data points about these components easily
accessible so that you can get usage and other important insights to make informed decisions.
The information is presented in the Azure AD Connect Health portal. In the Azure AD Connect Health portal, you
can view alerts, performance monitoring, usage analytics, and other information. Azure AD Connect Health
enables the single lens of health for your key identity components in one place.
As the features in Azure AD Connect Health increase, the portal provides a single dashboard through the lens of
identity. You get an even more robust, healthy, and integrated environment for your users to increase their
ability to get things done.
Why use Azure AD Connect Health?

When you integrate your on-premises directories with Azure AD, your users are more productive because there's
a common identity to access both cloud and on-premises resources. However, this integration creates the
challenge of ensuring that this environment is healthy so that users can reliably access resources both on
premises and in the cloud from any device. Azure AD Connect Health helps you monitor and gain insights into
your on-premises identity infrastructure that is used to access Office 365 or other Azure AD applications. It is as
simple as installing an agent on each of your on-premises identity servers.
Azure AD Connect Health for AD FS

Azure AD Connect Health for AD FS supports AD FS 2.0 on Windows Server 2008 R2, Windows Server 2012, and
Windows Server 2012 R2. It also supports monitoring the AD FS proxy or web application proxy servers that
provide authentication support for extranet access. With an easy and low-cost installation of the Health Agent,
Azure AD Connect Health for AD FS provides the following set of key capabilities:
Monitoring with alerts to know when AD FS and AD FS proxy servers are not healthy
Email notifications for critical alerts
Trends in performance data, which are useful for capacity planning of AD FS
Usage analytics for AD FS sign-ins with pivots (apps, users, network location etc.), which are useful to
understand how AD FS is getting utilized
Reports for AD FS such as top 50 users who have bad username/password attempts and their last IP address
Read more here about Using Azure AD Connect Health with AD FS
The following video provides an overview of Azure AD Connect Health for AD FS.
>
Azure AD Connect Health for sync

Azure AD Connect Health for sync monitors and provides information about the syncs that occur between your
on-premises Active Directory and Azure AD. Azure AD Connect Health for sync provides the following set of key
capabilities:
Monitoring with alerts to know when an Azure AD Connect server, also known as the Sync Engine, is not
healthy
Email notifications for critical alerts
Sync operational insights, which include latency charts for sync operations and trends in different operations
such as adds, updates, deletes
Quick glance information about sync properties and last successful export to Azure AD
Reports about object-level sync errors (does not require Azure AD Premium)
Read more here about Using Azure AD Connect Health for sync
The following video provides an overview of Azure AD Connect Health for sync.
Azure AD Connect Health for AD DS
Azure AD Connect Health for Active Directory Domain Services (AD DS) provides monitoring for domain
controllers that are installed on Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and
Windows Server 2016. The Health Agent installation enables you to monitor your on-premises AD DS
environment from the cloud. Azure AD Connect Health for AD DS provides the following set of key capabilities:
Monitoring alerts to detect when domain controllers are unhealthy and email notifications for critical alerts
The Domain Controllers dashboard, which provides a quick view of the health and operational status of your
domain controllers
The Replication Status dashboard that has the latest replication information and links to troubleshooting
guides when errors are detected
Quick anywhere access to performance data graphs of popular performance counters, which are necessary
for troubleshooting and monitoring purposes
Read more here about Using Azure AD Connect Health with AD DS
The following video provides an overview of Azure AD Connect Health for AD DS.
Get started with Azure AD Connect Health

To get started with Azure AD Connect Health, use the following steps:
1. Get Azure AD Premium or start a trial.
2. Download and install Azure AD Connect Health Agents on your identity servers.
3. View the Azure AD Connect Health dashboard at https://aka.ms/aadconnecthealth.
NOTE
Remember that before you see data in your Azure AD Connect Health dashboard, you need to install the Azure AD
Connect Health Agents on your targeted servers.
Download and install Azure AD Connect Health Agent

Make sure that you satisfy the requirements for Azure AD Connect Health.
Get started using Azure AD Connect Health for AD FS
Download Azure AD Connect Health Agent for AD FS.
See the installation instructions.
Get started using Azure AD Connect Health for sync
Download and install the latest version of Azure AD Connect. The Health Agent for sync will be
installed as part of the Azure AD Connect installation (version 1.0.9125.0 or higher).
Get started using Azure AD Connect Health for AD DS
Download Azure AD Connect Health Agent for AD DS.
See the installation instructions.
Azure AD Connect Health portal

The Azure AD Connect Health portal shows views of alerts, performance monitoring, and usage analytics. The
https://aka.ms/aadconnecthealth URL takes you to the main blade of Azure AD Connect Health. You can think of
a blade as a window. On The main blade, you see Quick Start, services within Azure AD Connect Health, and
additional configuration options. See the following screenshot and brief explanations that follow the screenshot.
After you deploy the agents, the health service automatically identifies the services that Azure AD Connect Health
is monitoring.
NOTE
For licensing information, see the Azure AD Connect FAQ or the Azure AD Pricing page.
Quick Start: When you select this option, the Quick Start blade opens. You can download the Azure AD
Connect Health Agent by selecting Get Tools. You can also access documentation and provide feedback.
Active Directory Federation Services: This option shows all the AD FS services that Azure AD Connect
Health is currently monitoring. When you select an instance, the blade that opens shows information about
that service instance. This information includes an overview, properties, alerts, monitoring, and usage
analytics. Read more about the capabilities at Using Azure AD Connect Health with AD FS.
Azure Active Directory Connect (sync): This option shows your Azure AD Connect servers that Azure AD
Connect Health is currently monitoring. When you select the entry, the blade that opens shows information
about your Azure AD Connect servers. Read more about the capabilities at Using Azure AD Connect Health for
sync.
Active Directory Domain Services: This option shows all the AD DS forests that Azure AD Connect Health is
currently monitoring. When you select a forest, the blade that opens shows information about that forest. This
information includes an overview of essential information, the Domain Controllers dashboard, the Replication
Status dashboard, alerts, and monitoring. Read more about the capabilities at Using Azure AD Connect Health
with AD DS.
Configure: This section includes options to turn the following on or off:
Auto-update to automatically update the Azure AD Connect Health agent to the latest version: You will
be automatically updated to the latest versions of the Azure AD Connect Health Agent when they
become available. This is enabled by default.
Allow Microsoft access to your Azure AD directory’s health data for troubleshooting purposes only: If
this is enabled, Microsoft can see the same data that you see. This information can help with
troubleshooting and assistance with issues. This is disabled by default.
Related links
Azure AD Connect Health Agent installation
Azure AD Connect Health operations
Using Azure AD Connect Health with AD FS
Using Azure AD Connect Health for sync
Using Azure AD Connect Health with AD DS
Azure AD Connect Health FAQ
Azure AD Connect Health version history
Integrating with Azure Active Directory
NOTE
This article is part of the Azure Active Directory developer's guide.
Azure Active Directory provides organizations with enterprise-grade identity management for cloud applications.
Azure AD integration gives your users a streamlined sign-in experience, and helps your application conform to IT
policy.
How To Integrate
There are several ways for your application to integrate with Azure AD. Take advantage of as many or as few of
these scenarios as is appropriate for your application.
Support Azure AD as a Way to Sign In to Your Application
Reduce sign in friction and reduce support costs. By using Azure AD to sign in to your application, your users
won't have one more name and password to remember. As a developer, you'll have one less password to store and
protect. Not having to handle forgotten password resets may be a significant savings alone. Azure AD powers sign
in for some of the world's most popular cloud applications, including Office 365 and Microsoft Azure. With
hundreds of millions users from millions of organizations, chances are your user is already signed in to Azure AD.
Learn more about adding support for Azure AD sign in.
Simplify sign up for your application. During sign up for your application, Azure AD can send essential
information about a user so that you can pre-fill your sign up form or eliminate it completely. Users can sign up for
your application using their Azure AD account via a familiar consent experience similar to those found in social
media and mobile applications. Any user can sign up and sign in to an application that is integrated with Azure AD
without requiring IT involvement. Learn more about signing-up your application for Azure AD Account login.
Browse for Users, Manage User Provisioning, and Control Access to Your Application
Browse for users in the directory. Use the Graph API to help users search and browse for other people in their
organization when inviting others or granting access, instead of requiring them to type email addresses. Users can
browse using a familiar address book style interface, including viewing the details of the organizational hierarchy.
Learn more about the Graph API.
Re-use Active Directory groups and distribution lists your customer is already managing. Azure AD
contains the groups that your customer is already using for email distribution and managing access. Using the
Graph API, re-use these groups instead of requiring your customer to create and manage a separate set of groups
in your application. Group information can also be sent to your application in sign in tokens. Learn more about the
Graph API.
Use Azure AD to control who has access to your application. Administrators and application owners in Azure
AD can assign access to applications to specific users and groups. Using the Graph API, you can read this list and
use it to control provisioning and de-provisioning of resources and access within your application.
Use Azure AD for Roles Based Access Control. Administrators and application owners can assign users and
groups to roles that you define when you register your application in Azure AD. Role information is sent to your
application in sign in tokens and can also be read using the Graph API. Learn more about using Azure AD for
authorization.
Get Access to User's Profile, Calendar, Email, Contacts, Files, and More
Azure AD is the authorization server for Office 365 and other Microsoft business services. If you support
Azure AD for sign in to your application or support linking your current user accounts to Azure AD user accounts
using OAuth 2.0, you can request read and write access to a user's profile, calendar, email, contacts, files, and other
information. You can seamlessly write events to user's calendar, and read or write files to their OneDrive. Learn
more about accessing the Office 365 APIs.
Promote Your Application in the Azure and Office 365 Marketplaces
Promote your application to the millions of organizations who are already using Azure AD. Users who
search and browse these marketplaces are already using one or more cloud services, making them qualified cloud
service customers. Learn more about promoting your application in the Azure Marketplace.
When users sign up for your application, it will appear in their Azure AD access panel and Office 365 app
launcher. Users will be able to quickly and easily return to your application later, improving user engagement.
Learn more about the Azure AD access panel.
Secure Device -to -Service and Service -to -Service Communication
Using Azure AD for identity management of services and devices reduces the code you need to write and
enables IT to manage access. Services and devices can get tokens from Azure AD using OAuth and use those
tokens to access web APIs. Using Azure AD you can avoid writing complex authentication code. Since the identities
of the services and devices are stored in Azure AD, IT can manage keys and revocation in one place instead of
having to do this separately in your application.
Benefits of Integration
Integration with Azure AD comes with benefits that do not require you to write additional code.
Integration with Enterprise Identity Management
Help your application comply with IT policies. Organizations integrate their enterprise identity management
systems with Azure AD, so when a person leaves an organization, they will automatically lose access to your
application without IT needing to take extra steps. IT can manage who can access your application and determine
what access policies are required - for example multi-factor authentication - reducing your need to write code to
comply with complex corporate policies. Azure AD provides administrators with a detailed audit log of who signed
in to your application so IT can track usage.
Azure AD extends Active Directory to the cloud so that your application can integrate with AD. Many
organizations around the world use Active Directory as their principal sign-in and identity management system,
and require their applications to work with AD. Integrating with Azure AD integrates your app with Active Directory.
Advanced Security Features
Multi-factor authentication. Azure AD provides native multi-factor authentication. IT administrators can require
multi-factor authentication to access your application, so that you do not have to code this support yourself. Learn
more about Multi-Factor Authentication.
Anomalous sign in detection. Azure AD processes more than a billion sign-ins a day, while using machine
learning algorithms to detect suspicious activity and notify IT administrators of possible problems. By supporting
Azure AD sign-in, your application gets the benefit of this protection. Learn more about viewing Azure Active
Directory access report.
Conditional access. In addition to multi-factor authentication, administrators can require specific conditions be
met before users can sign-in to your application. Conditions that can be set include the IP address range of client
devices, membership in specified groups, and the state of the device being used for access. Learn more about Azure
Active Directory conditional access.
Easy Development
Industry standard protocols. Microsoft is committed to supporting industry standards. Azure AD supports the
SAML 2.0, OpenID Connect 1.0, OAuth 2.0, and WS-Federation 1.2 authentication protocols. The Graph API is OData
4.0 compliant. If your application already supports the SAML 2.0 or OpenID Connect 1.0 protocols for federated
sign in, adding support for Azure AD can be straightforward. Learn more about Azure AD supported authentication
protocols.
Open source libraries. Microsoft provides fully supported open source libraries for popular languages and
platforms to speed development. The source code is licensed under Apache 2.0, and you are free to fork and
contribute back to the projects. Learn more about Azure AD authentication libraries.
Worldwide Presence and High Availability
Azure AD is deployed in datacenters around the world and is managed and monitored around the clock.
Azure AD is the identity management system for Microsoft Azure and Office 365 and is deployed in 28 datacenters
around the world. Directory data is guaranteed to be replicated to at least three datacenters. Global load balancers
ensure users access the closest copy of Azure AD containing their data, and automatically re-route requests to other
datacenters if a problem is detected.
Next Steps
Get started writing code.
Sign Users In Using Azure AD
Securing privileged access in Azure AD
Securing privileged access is a critical first step to help protect business assets in a modern organization. Privileged
accounts are accounts that administer and manage IT systems. Cyber-attackers target these accounts to gain access
to an organization’s data and systems. To secure privileged access, you should isolate the accounts and systems
from the risk of being exposed to a malicious user.
More users are starting to get privileged access through cloud services. This can include global administrators of
Office365, Azure subscription administrators, and users who have administrative access in VMs or on SaaS apps.
Microsoft recommends you follow this roadmap on Securing Privileged Access.
For customers using Azure Active Directory, Office 365, or other Microsoft services and applications, these
principles apply whether user accounts are managed and authenticated by Active Directory or in Azure Active
Directory. The following sections provide more information on Azure AD features to support securing privileged
access.

To increase the security of administrator authentication, you should require two-step verification before granting
privileges. Two-step verification is a method of verifying who you are that requires the use of more than just a
Azure Multi-Factor Authentication (MFA) is Microsoft's two-step verification solution, which helps safeguard access
to data and applications while meeting user demand for a simple sign-in process. It delivers strong authentication
via a range of easy verification options including:
phone calls
text messages
mobile app notifications
mobile app verification codes
third-party OATH tokens
For an overview of how Azure Multi-Factor Authentication works see the following video:
For more information, see MFA for Office 365 and MFA for Azure.
Time-bound privileges
Some organizations may find that they have too many users in highly privileged roles. A user might have been
added to the role for a particular activity, like to sign up for a service, but didn't use those privileges frequently
afterward.
To lower the exposure time of privileges and increase your visibility into their use, limit users to only taking on
their privileges "just in time" (JIT), or assign these roles for a shortened duration with confidence the privileges will
be revoked automatically. For Azure Active Directory, Azure Resources (Preview) and Microsoft Online Services,
you can use Azure AD Privileged Identity Management (PIM).
Attack detection
Azure Active Directory Identity Protection provides a consolidated view into risk events and potential vulnerabilities
affecting your organization’s identities. Based on risk events, Identity Protection calculates a user risk level for each
user, enabling you to configure risk-based policies to automatically protect the identities of your organization.
These policies, along with other conditional access controls provided by Azure Active Directory and EMS, can
automatically block the user or offer suggestions that include password resets and multi-factor authentication
enforcement.
Conditional access
With conditional access control, Azure Active Directory checks the specific conditions you choose when
authenticating a user, before allowing access to an application. Once those conditions are met, the user is
authenticated and allowed access to the application.
Related articles
Enable Azure Multi-Factor Authentication
Enable Azure AD Privileged Identity Management
Enable Azure AD Identity Protection
Enable conditional access controls
For more information on building a complete security roadmap, see the “Customer responsibilities and roadmap”
section of the Microsoft Cloud Security for Enterprise Architects document. For more information on engaging
Microsoft services to assist with any of these topics, contact your Microsoft representative or visit our
Cybersecurity solutions page.

What Is Azure Active Directory - PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

What Is Azure Active Directory - PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Table of Contents

How reliable is Azure AD?

Connect on-premises Active Directory with Azure AD and Office 365

Increase productivity and reduce helpdesk costs with self-service and

Manage and control access to corporate resources

Azure Active Directory Privileged Identity Management

Benefits of Azure Identity

TERM TO KNOW DESCRIPTION

Azure tenant An Azure AD tenant is representative of a single organization.

Work or school accounts Work or school accounts (issued by an admin for

Hybrid identity Hybrid identity is achieved by integrating your on-premises

The difference between Windows Server AD DS and Azure AD

Microsoft Azure identity solutions

Azure AD Domain Services

Common scenarios and recommendations

IDENTITY SCENARIO RECOMMENDATION

Where can I learn more?

Federated identity (AD FS)

Common scenarios and recommendations

Sync new user, contact, and

Set up my tenant for Office

Enable my users to sign in

Implement single sign-on

Ensure no password hashes

Enable on-premises multi-

Display password expiry

1 Password synchronization with single sign-on.

2 Pass-through authentication and single sign-on.

3 Federated single sign-on with AD FS.

Before you begin

To associate an existing subscription to your Azure AD directory

Access Azure and Azure Active Directory

Get started with Hybrid Azure AD

Q: How can I connect my on-premises directory to Azure AD?

Q: How do I set up SSO between my on-premises directory and my cloud applications?

Q: Does Azure AD provide a self-service portal for users in my organization?

Q: Does Azure AD help me manage my on-premises infrastructure?

Q: What if the application I need is not in the Azure AD marketplace?

Q: How do users sign in to applications by using Azure AD?

Q: Can I add applications I’m running on-premises?

Q: What is automated user provisioning for SaaS apps?

Q: Can I set up a secure LDAP connection with Azure AD?

New Azure AD sign-in experience

Add configuration to require the TOU to be expanded prior to accepting.

Scoped activation for eligible role assignments

New federated apps in Azure AD app gallery

NAME INTEGRATION TYPE DESCRIPTION

EFI Digital StoreFront SAML 2.0 Web 2 Print application

Vodeclic SAML 2.0 Use Azure AD to manage user access

Accredible SAML 2.0 Create, manage and deliver certificates,

FactSet SAML 2.0 Single Sign-on to FactSet's FDSWeb

MobileIron Azure AD Integration SAML 2.0 MobileIron mission is to enable modern

IMAGE WORKS SAML 2.0 Use Azure AD to manage user access,

Communifire SAML 2.0 Communifire is your modern, fully

MOBI SAML 2.0 Centralize, comprehend, and control

Reflektive SAML 2.0 Reflektive is a modern platform for

CybSafe OpenID Connect & OAuth CybSafe is a GCHQ-certified cyber

WebHR OpenID Connect & OAuth Everyone's Favorite All-in-One Social HR

Adobe Experience Manager SAML 2.0 Adobe Experience Manager (AEM), is a

Approval workflows for Azure AD directory roles

Pass-through Authentication - Skype for Business support

New approved client apps for Azure AD app-based conditional access

Terms of use support for multiple languages